Analyse der Java-Speicherzuweisung und Recyclingstrategie

Der folgende Editor vermittelt Ihnen ein tiefgreifendes Verständnis der Java-Speicherzuweisungs- und -recyclingstrategien. Der Herausgeber findet es ziemlich gut, deshalb teile ich es jetzt mit Ihnen und gebe es als Referenz. Folgen wir dem Editor und werfen wir einen Blick darauf.

1. Einführung

Bei der im Java-Technologiesystem erwähnten automatischen Speicherverwaltung geht es letztendlich um Speicher . In Bezug auf die beiden Probleme der Zuweisung und des Recyclings habe ich bereits mit Ihnen über das Java-Recycling gesprochen. Heute werde ich mit Ihnen über die Zuweisung von Java--Objekten im Speicher sprechen. Laienhaft ausgedrückt handelt es sich bei der Speicherzuweisung von Objekten um die Zuweisung auf dem Heap. Objekte werden hauptsächlich auf Eden der neuen Generation zugewiesen (die Generierung von Objekten im Speicher wird während der Speicherbereinigung ergänzt). Wenn Sie mehr wissen möchten, können Sie auch darauf verweisen Wenn der lokale Thread-Zuweisungspuffer gestartet wird, wird er entsprechend der Thread-Priorität im TLAB zugewiesen. In einigen Fällen erfolgt die Zuordnung auch direkt in der alten Generation.

2. Klassische Zuweisungsstrategie

1. Objekte werden zuerst auf Eden zugewiesen

Im Allgemeinen werden Objekte zuerst auf Eden zugewiesen. Wenn Eden nicht genügend Speicherplatz für die Zuweisung hat, initiiert jvm einen Minor GC. Sollte die Platzzuteilung immer noch nicht ausreichen, gibt es später weitere Maßnahmen, die im Folgenden erwähnt werden.

Legen Sie den ungeraden Protokollparameter der virtuellen Maschine fest -XX:+PrintGCDetails Während der Speicherbereinigung wird das Speicherrecyclingprotokoll gedruckt, und wenn der Prozess beendet wird , werden die aktuellen Speicherbereiche ausgegeben . Verteilungssituation. Schauen wir uns zunächst ein konkretes Beispiel an. Sie müssen die JVM-Parameter -Xms20m -Xmx20m -Xmn10m festlegen. Diese drei Parameter geben an, dass die Java-Heap-Größe 20 MB beträgt und der neuen Generation nicht erweitert werden kann wird der alten Generation zugeordnet. -XX:SurvivorRatio=8 ist das Standardverhältnis von Eden und Survivor in der neuen Generation von JVM. Der Standardwert ist 8:1. Der Grund dafür ist, dass 98 % der Objekte der neuen Generation im nächsten GC recycelt werden. Daher ist es sehr gut geeignet, den Kopieralgorithmus für die Speicherbereinigung zu verwenden. Daher sind von den 10 MB Speicher in der neuen Generation 8 MB Eden. 1M ist Survivor, und der andere 1M ist ungenutzt. Der Speicherblock, der mit dem Kopieralgorithmus zusammenarbeitet, ist ebenfalls ein Survivor.

public class ReflectTest {

  private static final int _1MB = 1024*1024;
  
  public static void testAllocation(){
    byte[] allocation1 , allocation2 , allocation3 , allocation4;
    allocation1 = new byte[2 * _1MB];
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];
    allocation4 = new byte[6 * _1MB];
  }
  
  public static void main(String[] args) {
    ReflectTest.testAllocation();
  }
  
}

Die Ausgabe lautet wie folgt

Heap
 PSYoungGen   total 9216K, used 6651K [0x000000000b520000, 0x000000000bf20000, 0x000000000bf20000)
 eden space 8192K, 81% used [0x000000000b520000,0x000000000bb9ef28,0x000000000bd20000)
 from space 1024K, 0% used [0x000000000be20000,0x000000000be20000,0x000000000bf20000)
 to  space 1024K, 0% used [0x000000000bd20000,0x000000000bd20000,0x000000000be20000)
 PSOldGen    total 10240K, used 6144K [0x000000000ab20000, 0x000000000b520000, 0x000000000b520000)
 object space 10240K, 60% used [0x000000000ab20000,0x000000000b120018,0x000000000b520000)
 PSPermGen    total 21248K, used 2973K [0x0000000005720000, 0x0000000006be0000, 0x000000000ab20000)
 object space 21248K, 13% used [0x0000000005720000,0x0000000005a07498,0x0000000006be0000)

Sie können sehen, dass Eden 81 % belegt, was darauf hinweist, dass Zuweisung1, Zuweisung2 und Zuweisung3 alle auf dem Eden der neuen Generation zugewiesen sind.

2. Große Objekte werden in der alten Generation direkt zugewiesen

Große Objekte beziehen sich auf Objekte, für die eine große Menge an kontinuierlichem Speicherplatz erforderlich ist Store, ähnlich der Art von sehr langen Strings und Arrays. Große Objekte sind keine gute Sache für die Speicherverteilung der virtuellen Maschine, wenn sie auf viele große Objekte stoßen, die nur eine Runde lang überleben. Solche Probleme sollten beim Schreiben von Code vermieden werden. Der Parameter -XX:PretenureSizeThreshold wird in der virtuellen Maschine bereitgestellt. Objekte, die größer als dieser Wert sind, werden direkt der alten Generation zugewiesen. Der Zweck besteht darin, eine große Menge an Speicherkopien zwischen dem Eden-Bereich und dem Survivor-Bereich zu vermeiden bereits erwähnt Der Recycling-Algorithmus und der Kopieralgorithmus wurden bereits erwähnt, daher werde ich nicht auf Details eingehen.

public class ReflectTestBig {

  private static final int _1MB = 1024*1024;
  
  public static void testAllocation(){
    byte[] allocation2 , allocation3 , allocation4;
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];
    allocation4 = new byte[6 * _1MB];
  }
  
  public static void main(String[] args) {
    ReflectTestBig.testAllocation();
  }
  
}

Die Ausgabe lautet wie folgt

Heap
 PSYoungGen   total 8960K, used 4597K [0x000000000b510000, 0x000000000bf10000, 0x000000000bf10000)
 eden space 7680K, 59% used [0x000000000b510000,0x000000000b98d458,0x000000000bc90000)
 from space 1280K, 0% used [0x000000000bdd0000,0x000000000bdd0000,0x000000000bf10000)
 to  space 1280K, 0% used [0x000000000bc90000,0x000000000bc90000,0x000000000bdd0000)
 PSOldGen    total 10240K, used 6144K [0x000000000ab10000, 0x000000000b510000, 0x000000000b510000)
 object space 10240K, 60% used [0x000000000ab10000,0x000000000b110018,0x000000000b510000)
 PSPermGen    total 21248K, used 2973K [0x0000000005710000, 0x0000000006bd0000, 0x000000000ab10000)
 object space 21248K, 13% used [0x0000000005710000,0x00000000059f7460,0x0000000006bd0000)

Sie können sehen, dass Allocation4 den Satz -XX:PretenureSizeThreshold=3145728 überschritten hat und direkt der alten Generation zugewiesen ist Die Auslastung der alten Generation beträgt 60 %. Beachten Sie, dass die Einstellung -XX:PretenureSizeThreshold=3145728 nicht als -XX:PretenureSizeThreshold=3m geschrieben werden kann, da der JVM sie sonst nicht erkennt.

3. Langfristig überlebende Objekte werden in die alte Generation eintreten

Da die virtuelle Maschine die Idee der Streifensammlung zur Verwaltung übernimmt Speicher, Speicherrecycling muss identifizieren, welche Objekte in die neue Generation und welche in die alte Generation eingefügt werden sollen. Um diesen Zweck zu erreichen, definiert jvm für jedes Objekt einen Alterszähler (Age). Wenn das Objekt in Eden geboren wird, den ersten Minor GC überlebt und im Survivor gespeichert werden kann, wird es in den Survivor verschoben und das Alter des Objekts wird auf 1 gesetzt. Jedes Mal, wenn ein Objekt Minor GC verlässt, wird sein Alter um 1 erhöht. Wenn sein Alter den Schwellenwert von einem Jahr überschreitet, wird das Objekt in die alte Generation befördert. Diese Schwellenwert-JVM ist standardmäßig auf 15 eingestellt und kann durch -XX:MaxTenuringThreshold festgelegt werden.

public class JavaTest { 
 
  static int m = 1024 * 1024; 
 
  public static void main(String[] args) { 
    byte[] a1 = new byte[1 * m / 4]; 

　　　　 byte[] a2 = new byte[7 * m]; 

　　　　 byte[] a3 = new byte[3 * m]; //GC 
  } 
}

Die Ausgabe ist wie folgt

[GC [DefNew: 7767K->403K(9216K), 0.0062209 secs] 7767K->7571K(19456K), 0.0062482 secs]  
[Times: user=0.00 sys=0.00, real=0.01 secs]  
a3 ok 
Heap 
 def new generation  total 9216K, used 3639K [0x331d0000, 0x33bd0000, 0x33bd0000) 
 eden space 8192K, 39% used [0x331d0000, 0x334f9040, 0x339d0000) 
 from space 1024K, 39% used [0x33ad0000, 0x33b34de8, 0x33bd0000) 
 to  space 1024K,  0% used [0x339d0000, 0x339d0000, 0x33ad0000) 
 tenured generation  total 10240K, used 7168K [0x33bd0000, 0x345d0000, 0x345d0000) 
  the space 10240K, 70% used [0x33bd0000, 0x342d0010, 0x342d0200, 0x345d0000) 
 compacting perm gen total 12288K, used 381K [0x345d0000, 0x351d0000, 0x385d0000) 
  the space 12288K,  3% used [0x345d0000, 0x3462f548, 0x3462f600, 0x351d0000) 
  ro space 10240K, 55% used [0x385d0000, 0x38b51140, 0x38b51200, 0x38fd0000) 
  rw space 12288K, 55% used [0x38fd0000, 0x396744c8, 0x39674600, 0x39bd0000)

Sie können sehen, dass a2 einmal überlebt hat, das Alter 1 ist und die Menge -XX:MaxTenuringThreshold=1 erfüllt, also a2 ist in die alte Generation eingetreten, und a3 ist in die neue Generation eingetreten.

4. Dynamische Objektaltersbestimmung

Um sich besser an den Speicherstatus verschiedener Programme anzupassen, benötigen virtuelle Maschinen nicht immer Objekte Das Alter muss den durch -XX:MaxTenuringThreshold festgelegten Wert erreichen, um in das alte Alter heraufgestuft zu werden. Wenn die Summe der Größen aller Objekte desselben Alters im Survivor-Bereich größer als die Hälfte des Survivor-Bereichs ist, werden Objekte, deren Wenn das Alter größer oder gleich diesem Alter ist, kann das Alter direkt eingegeben werden. Es ist nicht erforderlich, den Einstellungswert in -XX:MaxTenuringThreshold zu erreichen.

5. Platzzuteilungsgarantie

Wenn eine Minor GC auftritt, erkennt die virtuelle Maschine, ob die durchschnittliche Größe jeder Heraufstufung zur alten Generation größer ist als der verbleibende Speicherplatz der alten Generation. Wenn sie größer ist, wird direkt eine vollständige GC durchgeführt. Wenn es kleiner ist als, prüfen Sie, ob die HandlerPromotionFailyre-Einstellung einen Garantiefehler zulässt. Wenn dies zulässig ist, wird nur eine geringfügige GC durchgeführt. Wenn dies nicht zulässig ist, wird auch eine vollständige GC durchgeführt. Das heißt, wenn das Eden der neuen Generation das geänderte Objekt nicht speichern kann, wird das Objekt in der alten Generation gespeichert.

3. Häufig verwendete JVM-Parametereinstellungen

1. -Xms: Anfängliche Heap-Größe, Standard (MinHeapFreeRatio-Parameter kann angepasst werden) freier Heap Speicher Wenn er weniger als 40 % beträgt, erhöht die JVM den Heap bis zum maximalen Grenzwert von -Xmx.

2.

3. -Xmn: Größe der jungen Generation (1,4 oder höher), die Größe hier ist (eden+ 2 Survivor Space).

Die gesamte Heap-Größe = Größe der jungen Generation + Größe der alten Generation + Größe der persistenten Generation.

Nach der Vergrößerung der jungen Generation wird die Größe der alten Generation reduziert. Dieser Wert hat einen größeren Einfluss auf die Systemleistung. Sun empfiehlt offiziell eine Konfiguration von 3/8 des gesamten Heaps.

4. -XX:NewSize: Legen Sie die Größe der jungen Generation fest (für 1,3/1,4).

5. -XX:MaxNewSize: Der Maximalwert der jungen Generation (für 1,3/1,4).

6. -XX:PermSize: Legen Sie den Anfangswert der persistenten Generation fest (perm gen).

7. -XX:MaxPermSize: Legen Sie die maximale Größe der persistenten Generation fest.

8. -Xss: Die Stapelgröße jedes Threads beträgt 1 MB. Sie kann entsprechend angepasst werden Abhängig von der vom Anwendungsthread benötigten Speichergröße kann die Reduzierung dieses Werts mehr Threads generieren. Das Betriebssystem hat jedoch immer noch Grenzen für die Anzahl der Threads in einem Prozess und kann nicht unbegrenzt generiert werden liegt bei etwa 3000 bis 5000.

9. -XX:NewRatio: Das Verhältnis der jungen Generation (einschließlich Eden und zwei Survivor-Gebiete) zur alten Generation (ohne die persistente Generation), -XX:NewRatio=4 bedeutet die Differenz zwischen der jungen Generation Der Verhältniswert der Generation und der alten Generation beträgt 1:4, und die junge Generation macht 1/5 des gesamten Stapels aus. Wenn Xms=Xmx und Xmn festgelegt sind, muss dieser Parameter nicht festgelegt werden.

10. -XX:SurvivorRatio: Das Größenverhältnis des Eden-Bereichs und des Survivor-Bereichs wird auf 8 eingestellt, dann beträgt das Verhältnis von zwei Survivor-Bereichen zu einem Eden-Bereich 2:8 und ein Survivor-Bereich für die gesamte junge Generation 1/10.

11. -XX:LargePageSizeInBytes: Die Größe der Speicherseite kann nicht zu groß eingestellt werden, was sich auf die Größe von Perm auswirkt.

12. -XX:+DisableExplicitGC: Deaktivieren Sie System.gc()

13. -XX:MaxTenuringThreshold: Wenn auf 0 gesetzt, werden die Objekte der jungen Generation deaktiviert Nicht durch den Survivor-Bereich gehen, sondern direkt in die alte Generation gelangen. Bei Anwendungen mit einer großen Anzahl alter Generationen kann die Effizienz verbessert werden. Wenn dieser Wert auf einen größeren Wert eingestellt wird, werden die Objekte der jungen Generation mehrmals in den Survivor-Bereich kopiert , damit mehr Objekte hinzugefügt werden können Die Überlebenszeit der jungen Generation erhöht die Wahrscheinlichkeit, in der jungen Generation recycelt zu werden. Dieser Parameter ist nur bei serieller GC wirksam.

14. -XX:PretenureSizeThreshold: Wenn das Objekt die Größe überschreitet, ist es ungültig, wenn die neue Generation Parallel Scavenge GC verwendet In der alten Generation handelt es sich um ein großes Array-Objekt, und es gibt kein externes -Referenzobjekt im Array.

15. -XX:TLABWasteTargetPercent: Der Prozentsatz von TLAB im Eden-Bereich.

4. Ergänzung

Der Unterschied zwischen Minor GC und FUll GC:

GC der neuen Generation (Minor GC): bezieht sich auf die Garbage Collection-Aktion, die in der neuen Generation auftritt. Da die meisten Java-Objekte der ersten GC-Runde nicht entgehen können, wird Minor GC häufig verwendet Die Recyclinggeschwindigkeit ist im Allgemeinen höher.

GC der alten Generation (FULL GC/Major GC): bezieht sich auf den GC, der in der alten Generation auftritt. Wenn Major GC auftritt, wird er oft von mindestens einem Minor GC begleitet (. aber nicht unbedingt, in Die Sammlungsstrategie des ParallelScavenge-Sammlers umfasst den direkten Auswahlprozess von Major GC). Die Geschwindigkeit von Major GC ist im Allgemeinen mehr als zehnmal langsamer als die von Minor GC.

Das obige ist der detaillierte Inhalt vonAnalyse der Java-Speicherzuweisung und Recyclingstrategie. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!