JVM-Speicherverwaltung ------ Hervorragende Erklärung des GC-Algorithmus (lernen Sie in fünf Minuten den ultimativen Algorithmus kennen - Generationssammlungsalgorithmus)

Einführung

Was ist der ultimative Algorithmus?
Tatsächlich ist es der Algorithmus, der von der aktuellen JVM verwendet wird, und es ist nicht das wirkliche Nonplusultra. Vielleicht wird es ein paar Jahre später einen neuen ultimativen Algorithmus geben, und das wird es mit ziemlicher Sicherheit auch geben, denn LZ glaubt an die Fähigkeiten fortgeschrittener Menschen.
Wie geht der Generationssammlungsalgorithmus mit GC um?

Objektklassifizierung

Wie im vorherigen Kapitel erwähnt, basiert der Generationssammlungsalgorithmus auf den unterschiedlichen Eigenschaften von Objekten und verwendet geeignete Algorithmen. Es wird kein tatsächlicher neuer Algorithmus erstellt. Anstatt zu sagen, dass der Generationssammlungsalgorithmus der vierte Algorithmus ist, ist es besser zu sagen, dass es sich um eine praktische Anwendung der ersten drei Algorithmen handelt.
Besprechen wir zunächst die unterschiedlichen Eigenschaften von Objekten. Als nächstes werden LZ und alle GC-Algorithmen für diese Objekte auswählen.
Objekte im Gedächtnis können entsprechend der Länge ihres Lebenszyklus grob in drei Typen eingeteilt werden. Die folgenden Namen sind alle persönliche Namen von LZ.
1. Objekte, die jung sterben: Objekte, die geboren werden und verschwinden. Laienhaft ausgedrückt sind es Objekte, die sterben, bevor sie lange leben können.
Beispiele: lokale Variablen einer bestimmten Methode, temporäre Variablen innerhalb einer Schleife usw.
2. Unsterbliche Objekte: Diese Art von Objekten lebt im Allgemeinen länger und ist auch in einem sehr hohen Alter noch am Leben. Letztlich ist es jedoch fast sicher, dass unsterbliche Objekte früher oder später sterben, aber nur fast.
Beispiele: Cache-Objekte, Datenbankverbindungsobjekte, Singleton-Objekte (Singleton-Modus) usw.
3. Unsterbliche Objekte: Solche Objekte sind im Allgemeinen fast unsterblich, sobald sie geboren sind. Sie werden fast immer unsterblich sein.
Beispiele: Objekte im String-Pool (Fliegengewichtsmodus), geladene Klasseninformationen usw.

Der dem Objekt entsprechende Speicherbereich

Erinnern Sie sich noch an die Speicheraufteilung durch die JVM, als wir früher die Speicherverwaltung eingeführt haben?
Wir ordnen die oben genannten drei Objekte dem Speicherbereich zu, dh die vorzeitigen Objekte und die unsterblichen Objekte befinden sich im JAVA-Heap und die unsterblichen Objekte befinden sich im Methodenbereich.
Wir haben bereits im vorherigen Kapitel gesagt, dass die JVM-Spezifikation für den JAVA-Heap die Implementierung von GC erfordert. Daher ist der Tod für vorzeitige Objekte und unsterbliche Objekte fast unvermeidlich, aber nur fast unvermeidlich. Einige Objekte bleiben bis zum Ende der Anwendung erhalten. Die JVM-Spezifikation erfordert jedoch keine GC im Methodenbereich. Unter der Annahme, dass eine JVM-Implementierung GC im Methodenbereich nicht implementiert, ist das unsterbliche Objekt ein wirklich unsterbliches Objekt.
Da der Lebenszyklus unsterblicher Objekte zu lang ist, ist der Generationssammlungsalgorithmus für den JAVA-Heap konzipiert, dh für vorzeitige Objekte und alte unsterbliche Objekte.

JAVA-Heap-Objekt-Recycling (junge Objekte und alte unsterbliche Objekte)

Mit der obigen Analyse werfen wir einen Blick darauf, wie der Generationssammlungsalgorithmus mit dem JAVA-Heap-Speicher-Recycling, also vorzeitigen Objekten, umgeht Recycling von Gegenständen und unsterblichen Gegenständen.
Abgebrochene Objekte: Diese Art von Objekt kommt und geht und hat eine kurze Überlebenszeit. Erinnern Sie sich noch an die Anforderungen für die Verwendung des Replikationsalgorithmus? Das heißt, die Objektüberlebensrate darf nicht zu hoch sein, sodass sich vorzeitige Objekte am besten für die Verwendung des Replikationsalgorithmus eignen.
Kleine Frage: Was soll ich tun, wenn 50 % des Speichers verschwendet sind?
Antwort: Da die Überlebensrate vorzeitiger Objekte im Allgemeinen niedrig ist, ist es nicht erforderlich, 50 % des Speichers als freien und aktiven Bereich zu verwenden 80 % des Speichers werden verwendet, um Speicher für neu erstellte Objekte zuzuweisen. Sobald ein GC auftritt, werden 10 % des aktiven Bereichs und die anderen 80 % der verbleibenden Objekte auf 10 % des freien Bereichs übertragen. Als nächstes werden alle 90 % des vorherigen Speichers freigegeben und so weiter.
Damit Sie diesen GC-Prozess klarer sehen können, stellt LZ das folgende Diagramm zur Verfügung.

Das Bild markiert den Speicherstatus jedes der drei Bereiche in jeder Phase. Ich glaube, dass der GC-Prozess beim Betrachten des Bildes nicht schwer zu verstehen ist.
Es gibt jedoch zwei Punkte, die LZ erwähnen muss. Der erste Punkt ist, dass wir durch die Verwendung dieser Methode nur 10 % des Speichers verschwenden. Dies ist akzeptabel, da wir eine saubere Anordnung des Speichers und des GC erhalten Geschwindigkeit. Der zweite Punkt ist, dass die Prämisse dieser Strategie darin besteht, dass der von jedem überlebenden Objekt belegte Speicher diese Größe von 10 % nicht überschreiten darf. Sobald die Größe überschritten wird, werden die zusätzlichen Objekte nicht kopiert.
Um die oben genannte unerwartete Situation zu lösen, dh wenn der von überlebenden Objekten belegte Speicher zu groß ist, teilen Experten den JAVA-Heap in zwei Teile auf. Die oben genannten drei Bereiche sind der erste Teil, der als neue Generation bezeichnet wird oder junge Generation. Der verbleibende Teil, der der Aufbewahrung alter und unsterblicher Gegenstände gewidmet ist, wird als alte Generation bezeichnet.
Ist das nicht ein sehr passender Name? Werfen wir einen Blick darauf, wie man mit alten unsterblichen Objekten umgeht.
Alte unsterbliche Objekte: Die Überlebensrate dieser Art von Objekten ist sehr hoch, da die meisten von ihnen von der neuen Generation übertragen werden. Genau wie Menschen werden sie nach langer Zeit alt und unsterblich.
Wenn die folgenden beiden Situationen auftreten, wird das Objekt normalerweise vom neuen Generationsbereich in den alten Bereich übertragen.
1. Jedes Objekt in der neuen Generation wird ein bestimmtes Alter haben (das Alter ist die Anzahl der GCs, die überlebt haben. Wenn das Objekt jeden GC überlebt, wird das Alter erhöht Durch 1) wird es an die alte Generation übertragen, und der Alterswert dieser Übertragung an die alte Generation kann im Allgemeinen in der JVM festgelegt werden.
2. Wenn der Speicher, der von überlebenden Objekten in der neuen Generation belegt wird, 10 % überschreitet, werden die überschüssigen Objekte in der alten Generation platziert. Zu diesem Zeitpunkt ist die alte Generation das „Backup-Lager“ der neuen Generation.
Aufgrund der Eigenschaften des alten und unsterblichen Objekts ist die Verwendung des Replikationsalgorithmus offensichtlich nicht mehr geeignet, da seine Überlebensrate zu hoch ist. Vergessen Sie nicht, dass die alte Generation den Replikationsalgorithmus erneut verwendet wird kein Backup-Lager haben. Daher können für alte unsterbliche Objekte im Allgemeinen nur Algorithmen zum Markieren/Organisieren oder Markieren/Löschen verwendet werden.

Objektrecycling im Methodenbereich (unsterbliche Objekte)

Die beiden oben genannten Situationen haben die meisten GC-Probleme gelöst, da der JAVA-Heap im Mittelpunkt des GC steht und die oben genannten Probleme gelöst wurden wurde ebenfalls aufgenommen. Der gesamte Inhalt des Generationssammlungsalgorithmus wurde abgedeckt, und das anschließende Recycling unsterblicher Objekte ist nicht mehr Teil des Generationssammlungsalgorithmus.
Im Methodenbereich gibt es Unsterblichkeitsobjekte. In unserer häufig verwendeten virtuellen Hotspot-Maschine (JDK-Standard-JVM) wird der Methodenbereich auch liebevoll als permanente Generation bezeichnet, nicht wahr?
Tatsächlich gab es vor langer Zeit keine dauerhafte Generation. Zu diesem Zeitpunkt wurden die permanente Generation und die alte Generation zusammen gespeichert, die Instanzinformationen und Klasseninformationen von JAVA-Klassen enthielten. Später stellte sich jedoch heraus, dass das Entladen von Klasseninformationen selten vorkommt, weshalb die beiden getrennt wurden. Glücklicherweise verbessert sich dadurch die Leistung erheblich. Die permanente Generation wurde also gespalten.
Der GC in diesem Teil des Gebiets verwendet eine ähnliche Methode wie die alte Generation. Da es kein „Standby-Lager“ gibt, können beide nur Markieren/Löschen- und Markieren/Organisieren-Algorithmen verwenden.

Zeitpunkt des Recyclings

Wenn die JVM eine GC durchführt, werden die oben genannten drei Speicherbereiche nicht jedes Mal gemeinsam recycelt. Meistens bezieht sich das Recycling auf die neue Generation. Daher wird GC je nach Recyclingbereich in zwei Typen unterteilt: einen gewöhnlichen GC (Minor GC) und einen globalen GC (Major GC oder Full GC). Die Bereiche, auf die sie abzielen, sind wie folgt.
Normale GC (Minor GC): GC nur für den Bereich der neuen Generation.
Globaler GC (Haupt-GC oder vollständiger GC): GC für die alte Generation, gelegentlich begleitet von GC für die neue Generation und GC für die permanente Generation.
Da der GC-Effekt der alten Generation und der permanenten Generation relativ gering ist und die Speichernutzung der beiden langsam zunimmt, sind normalerweise mehrere gewöhnliche GCs erforderlich, um einen globalen GC auszulösen.

Fazit

Das Obige ist die detaillierte Erklärung des JVM-Speichermanagements ------ GC-Algorithmus (fünf Minuten, um Ihnen den ultimativen Algorithmus beizubringen --- Generationssammlung). Algorithmus) Inhalt, für weitere verwandte Inhalte achten Sie bitte auf die chinesische PHP-Website (m.sbmmt.com)!