1. Einführung
Die im Java-Technologiesystem erwähnte automatische Speicherverwaltung besteht letztendlich aus zwei Themen: Speicherzuweisung und Recycling. Ich habe bereits mit Ihnen über die relevanten Kenntnisse des Java-Recyclings gesprochen Lassen Sie uns heute über die Zuordnung 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.
Unter normalen Umständen werden Objekte zuerst auf Eden zugewiesen. Bei der Zuweisung initiiert der JVM einen Minor GC. Sollte immer noch nicht genügend Platz zur Verfügung stehen, 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, wird die aktuelle Zuordnung jedes Speicherbereichs ausgegeben. 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.
1 public class ReflectTest { 2 3 private static final int _1MB = 1024*1024; 4 5 public static void testAllocation(){ 6 byte[] allocation1 , allocation2 , allocation3 , allocation4; 7 allocation1 = new byte[2 * _1MB]; 8 allocation2 = new byte[2 * _1MB]; 9 allocation3 = new byte[2 * _1MB];10 allocation4 = new byte[6 * _1MB];11 }12 13 public static void main(String[] args) {14 ReflectTest.testAllocation();15 }16 17 }Nach dem Login kopieren
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)
Nach dem Login kopieren
Sie können sehen, dass Eden 81 % belegt, was darauf hinweist, dass Zuordnung1, Zuordnung2, und Allocation3 sind alle auf der neuen Generation Eden zugewiesen.
2. Große Objekte werden in der alten Generation direkt zugewiesen
Große Objekte beziehen sich auf Objekte, die zum Speichern viel kontinuierlichen Speicherplatz benötigen, ähnlich wie sehr lange Zeichenfolgen 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();
}
}Nach dem Login kopieren
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)
Nach dem Login kopieren
Sie können sehen, dass Zuweisung4 den Satz -XX:PretenureSizeThreshold=3145728 überschritten hat , zögern Sie nicht zuzuweisen4 Es ist direkt der alten Generation zugeordnet und 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 aufgenommen
Da die virtuelle Maschine die Idee der Streifensammlung zur Speicherverwaltung übernimmt, muss beim Speicherrecycling ermittelt werden, in welche Objekte sie eingefügt werden sollen die neue Generation. Welche Objekte in die alte Generation eingeordnet 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.
m = 1024 * 1024 [] a1 = [1 * m / 4[] a2 = [7 *[] a3 = [3 * m];
Nach dem Login kopieren
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)
Nach dem Login kopieren
Sie können sehen, dass a2 einmal überlebt hat und sein Alter 1 beträgt, was die Menge -XX:MaxTenuringThreshold=1 erfüllt, sodass a2 in die alte Generation eingetreten ist und a3 in die neue Generation eingetreten ist.
4. Dynamische Bestimmung des Objektalters
Um sich besser an den Speicherstatus verschiedener Programme anzupassen, erfordert die virtuelle Maschine nicht immer, dass das Alter des Objekts den von eingestellten Wert erreichen muss -XX:MaxTenuringThreshold Um in das hohe Alter befördert zu werden, wenn die Summe der Größen aller gleichaltrigen Objekte im Survivor-Raum größer als die Hälfte des Survivor-Raums ist, Objekte, deren Alter größer oder gleich diesem ist Das Alter kann direkt in das Alter eingegeben werden, ohne den in -XX:MaxTenuringThreshold festgelegten Wert zu erreichen.
5. Speicherplatzzuweisungsgarantie
Wenn ein 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 es größer ist, fahren Sie direkt mit einem vollständigen GC fort. Wenn es kleiner ist als, prüfen Sie, ob die HandlerPromotionFailyre-Einstellung einen Garantiefehler zulässt. Wenn dies zulässig ist, wird nur eine Minor-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 Erhöhen Sie den Heap, bis die maximale Grenze von Xmx erreicht ist.
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 festgelegt, dann beträgt das Verhältnis von zwei Survivor-Bereichen zu einem Eden-Bereich 2:8 und ein Survivor-Bereich entfällt für die gesamte junge Generation.
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: System.gc() schließen
13. -XX:MaxTenuringThreshold: Wenn auf 0 gesetzt, werden die Objekte der jungen Generation nicht Durchlaufen Sie den Survivor-Bereich und geben Sie ihn direkt in die alte Generation ein. Bei Anwendungen mit einer großen Anzahl alter Generationen kann die Effizienz verbessert werden. Wenn dieser Wert auf einen größeren Wert festgelegt wird, werden die Objekte der jungen Generation mehrmals in den Survivor-Bereich kopiert. Damit mehr Objekte hinzugefügt werden können, erhöht sich die Wahrscheinlichkeit, dass die junge Generation recycelt wird. 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 das Array enthält keine externen Referenzobjekte.
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 Speicherbereinigungsaktion, die in der neuen Generation stattfindet , weil Java-Objekte Große Logarithmen können der ersten GC-Runde nicht entkommen, daher wird Minor GC häufig verwendet und die Wiederherstellungsgeschwindigkeit ist im Allgemeinen schneller.
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). (Sammelstrategie des ParallelScavenge-Kollektors) Es gibt einen direkten Auswahlprozess für 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 vonEine kurze Diskussion über Java-Speicherzuweisungs- und Recyclingstrategien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
