Detaillierte Erläuterung der JVM-Speicherbereichsaufteilung und des Garbage-Collection-Mechanismus
- 巴扎黑Original
- 2017-06-23 15:11:511687Durchsuche
Wenn wir Java-Code schreiben, müssen wir uns in den meisten Fällen nicht darum kümmern, ob oder wann Ihr neues Objekt freigegeben wird. Weil es in der JVM einen automatischen Garbage-Collection-Mechanismus gibt. Im vorherigen Blog haben wir unten über die Speicherverwaltungsmethoden von MRC (manuelle Referenzzählung) und ARC (automatische Referenzzählung) in Objective-C gesprochen Werde es überprüfen. Der aktuelle JVM-Speicherrecyclingmechanismus verwendet keine Referenzzählung, sondern hauptsächlich „Kopierrecycling“ und „adaptives Recycling“.
Natürlich gibt es neben den beiden oben genannten Algorithmen noch weitere Algorithmen, die im Folgenden ebenfalls vorgestellt werden. In diesem Blog werden wir zunächst kurz über die regionale Aufteilung der JVM sprechen und dann auf dieser Grundlage den Garbage-Collection-Mechanismus der JVM vorstellen.
1. Kurze Beschreibung der JVM-Speicherbereichsaufteilung
Natürlich dieser Teil ist eine kurze Diskussion. Schauen wir uns die Aufteilung des Speicherbereichs der JVM an, um den Weg für die Erweiterung des Garbage-Collection-Mechanismus zu ebnen. Natürlich gibt es im Internet viele detaillierte Informationen zur Aufteilung der JVM-Speicherbereiche, bitte googeln Sie diese selbst.
Basierend auf der Aufteilung des JVM-Speicherbereichs habe ich einfach das folgende schematische Diagramm gezeichnet. Der Bereich ist hauptsächlich in zwei große Blöcke unterteilt. Die von uns erstellten Objekte werden im Heap-Bereich zugewiesen . Der Garbage Collector recycelt hauptsächlich Speicher im Heap-Bereich. Der andere Teil ist der
Nicht-Heap-BereichDer Nicht-Heap-Bereich umfasst hauptsächlich den „Code-Cache-Bereich (Code-Cache)“, der zum Kompilieren und Speichern verwendet wird lokaler Code. Die „Eternal Generation (Perm Gen)“, die die eigenen statischen Daten der JVM speichert, der „Java Virtual Machine Stack (JVM Stack), der Verweise auf Methodenparameter und lokal speichert Variablen und zeichnet die Reihenfolge der Methodenaufrufe auf“ und „Lokaler Methodenstapel (Lokaler Methodenstapel)“.
Der Garbage Collector stellt hauptsächlich ungenutzte Speicherbereiche im Heap-Bereich wieder her und organisiert die entsprechenden Bereiche. Im Heap-Bereich wird es basierend auf der Überlebenszeit des Objektspeichers oder der Größe des Objekts in „
“ und „alte Generation“ unterteilt. Objekte der „jungen Generation“ sind instabilund anfällig für Müll, während Objekte der „alten Generation“ relativ stabil sind und weniger wahrscheinlich Müll erzeugen. Der Grund für die Trennung besteht darin, entsprechend den Eigenschaften der Speicherblöcke in verschiedenen Bereichen verschiedene Speicherwiederherstellungsalgorithmen anzuwenden, um die Effizienz der Speicherbereinigung im Heap-Bereich zu verbessern. Nachfolgend erfolgt eine ausführliche Einführung.
2. Einführung in gängige Speicherrecycling-Algorithmen Wir haben ein kurzes Verständnis von Schauen wir uns neben dem oben genannten
Die Aufteilung der Speicherbereiche in JVMeinige gängige Speicherrecycling-Algorithmen an. Natürlich wird der unten vorgestellte Speicherrecycling-Algorithmus nicht nur in JVM verwendet, wir werden auch die Speicherrecycling-Methode in OC überprüfen. Im Folgenden werden hauptsächlich „Referenzzählrecycling“, „Kopierrecycling“, „markiertes Sortierrecycling“ und „Generationsrecycling“ aufgeführt.
1. Referenzzählung Speicherrecycling Referenzanzahl (
Referenzanzahl) Der Speicher Der Recyclingmechanismus ist der Speicherrecyclingmechanismus, der derzeit in den Sprachen Objective-C und Swift verwendet wird. In früheren Blogs haben wir auch ausführlich über das Speicherrecycling mit Referenzzählung gesprochen. Solange eine Referenz vorhanden ist, wird der Referenzzähler um 1 erhöht. Wenn der Referenzzähler 0 erreicht, wird der Speicherblock zurückgefordert. Natürlich kann diese Speicherbereinigungsmethode problemlos einen „Referenzzyklus“ bilden. Zirkelverweise im Referenzzähler von
Objective-C verursachen Speicherlecks. Variablen können als schwache oder starke Typen deklariert werden. Das heißt, wir können die Referenz als „Starke Referenz“ oder „Schwache Referenz“ definieren. Wenn „Starker Referenzzyklus“ erscheint, können wir eine der Referenzen auf schwacher Typ setzen. Dann wird dieser starke Referenzzyklus unterbrochen und es tritt kein „Speicherverlust“ auf. Problem. Weitere und detailliertere Informationen zum Thema „Reference Counted Memory Recycling“ finden Sie in den zuvor veröffentlichten verwandten Blogs zu OC-Inhalten. Um besser zu verstehen, wie die Referenzzählung funktioniert, habe ich einfach das Bild unten gezeichnet. Die drei Referenzen a, b und c im Stapel links verweisen auf verschiedene Bereichsblöcke im Heap. Wenn in einem Speicherbereichsblock im Heap ein starker Verweis auf diesen Bereich vorhanden ist, wird dessen RetainCount um 1 erhöht. Wenn schwach auf verweist, wird retainCount nicht um 1 erhöht. Schauen wir uns zunächst den ersten Speicherbereich an, auf den a verweist. Da in diesem Speicherblock nur a stark referenziert wird, gilt retainCount=1 Die Erinnerung wird es verstehen, recycelt zu werden. In diesem Fall tritt kein Speicherverlust auf. Werfen wir einen Blick auf den Speicherbereich 2, auf den b zeigt. Sowohl b als auch Speicherblock 3 haben starke Verweise auf Speicherblock 2, also ist 2 retainCount=2. Speicherblock 2 hat auch einen starken Verweis auf Speicherblock 3, daher ist bei 3 der RetainCount = 1. Daher gibt es in dem Speicherbereich, auf den b zeigt, einen „starken Referenzzyklus“, denn wenn b nicht mehr auf diesen Speicherbereich zeigt, wird rc=2 zu rc=1. Da RetainCount nicht Null ist, werden diese beiden Speicherbereiche nicht freigegeben, und 2 wird nicht freigegeben, sodass die drei Speicherbereiche natürlich nicht freigegeben werden, dieser Speicherbereich jedoch nicht erneut verwendet wird, was zu „Speicherverlust". Wenn diese beiden Speicherbereiche besonders groß sind, können wir uns vorstellen, dass die Folgen gravierend sein werden. starken Referenzzyklus“, da eine der Referenzketten eine schwache Referenz ist. Wenn c nicht mehr auf den vierten Speicherblock verweist, ändert sich rc von 1 auf Null, und der Blockbereich wird sofort freigegeben. Nachdem Speicherblock 4 freigegeben wurde, ändert sich der RC von Speicherblock 5 von 1 auf 0, und Speicherblock 5 wird ebenfalls freigegeben. In diesem Fall treten keine Speicherlecks auf. In Objective-C wird diese Methode zum Recycling von Speicher verwendet. Natürlich gibt es in OC neben „starker Referenz“ und „schwacher Referenz“ auch einen automatischen Freigabepool. Mit anderen Worten, die Autorealease-Typreferenz wird nicht sofort freigegeben, wenn retainCount = 0, sondern erst freigegeben, wenn sie aus dem automatischen Freigabepool kommt. Ich werde hier nicht näher darauf eingehen. 2. Kopierspeicherrecycling zyklische Referenzen“ verursachte Speicherleckproblem zu lösen, werden die Konzepte „starke Referenz“ und „schwache Referenz“ eingeführt im OC. Als nächstes werden wir uns den Kopierspeicher-Recyclingmechanismus ansehen. Bei diesem Mechanismus besteht kein Grund zur Sorge über das Problem der „zyklischen Referenzen“. Einfach ausgedrückt ist der Kern des kopiebasierten Recyclings das „Kopieren“, aber die Voraussetzung ist das bedingte Kopieren. Bei der Garbage Collection werden die „lebenden Objekte“ in einen anderen leeren Heap-Bereich kopiert und anschließend der vorherige Bereich gemeinsam geleert. „Live-Objekte“ beziehen sich auf Objekte, die auf dem „Stapel“ entlang der Referenzkette des Objekts erreichbar sind. Natürlich muss nach dem Kopieren des Live-Objekts in den neuen „Heap-Bereich“ auch der Verweis auf den Stack-Bereich geändert werden. Nicht-Heap-Bereich , d. h. die Referenzen der Blöcke 2 und 3 sind beide Referenzen aus dem Heap-Bereich, also Objekte, die recycelt werden müssen . Aus diesem Beispiel können wir ersehen, dass die Effizienz der „Kopieren“-Garbage Collection immer noch relativ hoch ist, wenn viel Speichermüll vorhanden ist, da relativ wenige kopierte Objekte vorhanden sind und der alte Heap-Speicherplatz direkt bereinigt werden kann beim Ausräumen. Wenn jedoch relativ wenig Müll vorhanden ist, kopiert diese Methode eine große Anzahl lebender Objekte und die Effizienz ist immer noch relativ gering. Diese Methode teilt auch den Heap-Speicherplatz in zwei Hälften. Mit anderen Worten, die Hälfte davon ist immer frei und die Auslastung des Heap-Speicherplatzes ist nicht hoch. 3. Markierungskomprimierungs-Wiederherstellungsalgorithmus Aus dem Obigen Beim Garbage-Collection-Prozess „Kopieren “ wissen wir, dass die Effizienz bei viel Müll relativ hoch ist, bei wenig Müll jedoch die Effizienz der Arbeitsmethode relativ gering ist. Als nächstes werden wir einen anderen Markierungskomprimierungs-Recycling-Algorithmus vorstellen. Dieser Algorithmus ist effizienter, wenn weniger Müll vorhanden ist, aber wenn mehr Müll vorhanden ist, ist die Effizienz nicht hoch >“ bildet eine Ergänzung. Im Folgenden stellen wir den Markierungskomprimierungs-Recycling-Algorithmus vor. Markierung – Der erste Schritt der Komprimierung ist die Markierung, die die Markierung der „ “ im Heap-Bereich erfordert. Wir haben im obigen Inhalt bereits darüber gesprochen, was ein „lebendes Objekt“ ist, daher gehen wir hier nicht auf Details ein. Anhand der Eigenschaften von „lebenden Objekten“ können wir erkennen, dass es sich bei den folgenden lebenden Objekten um die Speicherbereiche 1 und 3 handelt, also markieren wir sie. . Der Algorithmus, der die Recyclingmethoden „Kopieren“ und „Markieren-Komprimieren“ integriert, ist der „Generations“- Garbage-Collection-Mechanismus, der im Folgenden ausführlich vorgestellt wird. 4. Generationsbasierte Müllabfuhr “ bedeutet die Einteilung von Objekten in verschiedene Generationen basierend auf ihrer Anfälligkeit für Müllerzeugung oder der Größe des Objekts, die in „junge Generation“, „alte Generation“ und „permanente Generation“ unterteilt werden können. Die „permanente Generation“ ist nicht im Haufen, deshalb werden wir nicht noch einmal darüber diskutieren. Basierend auf den Merkmalen der generationsübergreifenden Speicherbereinigung wird das folgende vereinfachte Diagramm gezeichnet. Im Halde sind die Bereiche hauptsächlich in „Junge Generation“ und „Alte Generation“ unterteilt. Die Erstellung des Speichers von Objekten in der „jungen Generation“ dauert nicht lange, er wird relativ schnell aktualisiert und ist anfällig für „Speichermüll“. Daher ist die Recyclingmethode „Kopieren“ für die Speicherbereinigung in der „jungen Generation“ erforderlich effizienter. Die „junge Generation“ kann in zwei Bereiche unterteilt werden, einer ist . Eden Space speichert hauptsächlich Objekte, die zum ersten Mal erstellt wurden, während Survivor Sprace die „lebenden Objekte“ speichert, die aus Eden Space überlebt haben. Der Survivor Sprace (Überlebensbereich) ist in zwei Blöcke unterteilt: Form und To, die zum Kopieren von Objekten zueinander zur Müllbereinigung verwendet werden. Die „alte Generation“ speichert einige „große Objekte“ und „Objekte“, die den überlebt haben. Im Allgemeinen sind die Objekte in der „alten Generation“ relativ stabil und generieren weniger In diesem Fall ist es effizienter, die Recyclingmethode „Markierung“ zu verwenden. „Generational Garbage Collection“ teilt und erobert hauptsächlich, indem es verschiedene Objekte nach ihren Merkmalen klassifiziert und geeignete Garbage Collection-Lösungen basierend auf den Merkmalen der Klassifizierung auswählt. 3. Das spezifische Arbeitsprinzip der generationsübergreifenden Müllabfuhr Natürlich kann die spezifische Garbage Collection von JVM je nach Threads in „Serielle Garbage Collection“, die einen einzelnen Thread zum Recycling verwendet, und „Parallele Garbage Collection“ unterteilt werden ". Je nach Aussetzungsstatus des Programms kann es in „Exklusives Recycling“ und „Gleichzeitiges Recycling“ unterteilt werden. Natürlich haben wir schon oft darüber gesprochen. „Parallel“ und „Parallelität“ sind definitiv nicht die gleichen Konzepte und dürfen nicht verwechselt werden. In diesem Blog wird nicht näher auf die oben genannten Methoden eingegangen. Wenn Sie interessiert sind, googeln Sie sie bitte. 1. Vor der Müllabfuhr Generationen-Müllabfuhr“ „Aus dem Bild unten können wir ersehen, dass ein Teil des zugewiesenen Objektspeichers im Heap nicht auf dem Stapel referenziert wird. Dies sind die Objekte, die recycelt werden müssen. Wir können sehen, dass der Haufen unten als Ganzes in „junge Generation“ und „alte Generation“ unterteilt ist und die junge Generation in drei Bereiche unterteilt werden kann: Eden Space, From und To. Was die Rolle der einzelnen Bereiche betrifft, haben wir sie bereits oben bei der Einführung der „Generations-Garbage Collection“ vorgestellt, daher werden wir sie in diesem Teil nicht im Detail vorstellen. 2. Generationsübergreifende Müllabfuhr Eden Space und From in den To-Bereich. Beim Kopieren müssen wir auch die Stapelreferenzadresse des kopierten Speichers ändern. Der Speicherplatz für „große Objekte“ im From- oder Eden-Bereich wird direkt in die „alte Generation“ kopiert. Da die Effizienz mehrerer Kopien „großer Objekte“ in den Bereichen Von und Bis relativ gering ist, fügen Sie sie direkt der „alten Generation“ hinzu, um die Recyclingeffizienz zu verbessern. 3. Das Ergebnis nach der Müllabfuhr 4. Eclipse GC-Protokollkonfiguration und -analyse Eclipse und analysieren dann diese Protokolldatensätze. Natürlich verwenden wir in diesem Blog Java8. Wenn Sie andere Versionen von Java verwenden, werden die gedruckten Protokollinformationen etwas anders sein, also beginnen wir mit diesem Teil. 1. Konfigurieren Sie die Laufeinstellungen von Eclipse Konfigurationen ausführen..., um die Laufzeitkonfiguration durchzuführen. Unten sehen Sie das Dialogfeld, das durch die obige Option geöffnet wird. Suchen Sie dann die Registerkartenleiste (x) = Argumente und fügen Sie die entsprechenden Parameter der virtuellen Maschine in VM-Argumente hinzu. Diese Parameter werden angezeigt zur Laufzeit als Projektparameter verwendet werden. Nachfolgend haben wir zwei Parameter hinzugefügt: -XX:+PrintGCTimeStamps und -XX:+PrintGCDetails. Anhand dieser beiden Parameternamen ist es nicht schwer, die den entsprechenden Parametern entsprechenden Funktionen zu erkennen. Eine besteht darin, den Zeitstempel der Garbage Collection zu drucken, und die andere darin, die Details der Garbage Collection zu drucken. Natürlich gibt es noch viele andere Parameter, z. B. die Parameter des spezifischen Algorithmus bei der Auswahl von „Garbage Collection“, die Parameter für die Auswahl von „seriell“ oder „parallel“ und einige Auswahlmöglichkeiten für „exklusiven“ oder „gleichzeitigen“ Müll . Recycelte Parameter. Ich werde hier nicht zu sehr ins Detail gehen, bitte googeln Sie es selbst. 2. Drucken und Parsen von Recyclingprotokollen Nach der Konfiguration des oben Nach den Parametern werden die entsprechenden Parameterinformationen ausgedruckt, wenn wir System.gc() verwenden, um eine erzwungene Speicherbereinigung durchzuführen. Zuerst müssen wir den Code zum Testen erstellen. Unten ist die Testklasse, die wir erstellt haben. Natürlich ist der Code in der Testklasse relativ einfach. Die Hauptsache ist, die Zeichenfolge zu erneuern, dann die Referenz auf Null zu setzen und schließlich System.gc() zum Recycling aufzurufen. Der spezifische Code lautet wie folgt: Als nächstes stellen wir den Hauptinhalt der Protokollinformationen vor unten. [PSYoungGen: 1997K->416K(38400K)] 1997K->424K(125952K), 0,0010277 Sekunden] PSYoungGen gibt an, dass die „junge Generation“ parallel recycelt wird, 1997K->416K bedeutet „vor dem Recycling->nach dem Recycling“ im entsprechenden Bereich der jungen Generation“ Größe, während (38400K) die Gesamtgröße des Heaps der „jungen Generation“ darstellt. Die 1997K->424K (125952K) Daten auf der Rückseite stellen aus der Perspektive des gesamten Heaps ein Problem dar. 1997 KB (Speicher, der vor dem Heap-Recycling verwendet wird) -> 424 KB (Speicher, der nach dem Heap-Recycling verwendet wird) (125952 KB – der gesamte Speicherplatz des Heaps). [ParOldGen: 8K->328K(87552K)] ParOldGen recycelt die „alte Generation“ parallel. Die folgenden Parameter ähneln den oben genannten Parametern für das parallele Recycling der jungen Generation, daher werde ich nicht auf Details eingehen. [Metaspace: 2669K->2669K(1056768K)] bedeutet The Recyclingsituation des „Metadatenbereichs“, des Metaspace und des „Permanent Generation“-Bereichs, bei denen es sich um Bereiche handelt, die zum Speichern statischer Daten oder Systemmethoden verwendet werden. Der Inhalt dieses Blogs endet hier Es gibt viel mehr Inhalte zur Garbage Collection in der JVM. Ich werde sie in Zukunft basierend auf der spezifischen Situation nacheinander vorstellen. Das war's für den heutigen Blog. 
Nachdem die Markierung abgeschlossen ist, beginnen wir mit der Komprimierung, komprimieren die lebenden Objekte in einen Abschnitt des „Heap-Bereichs“ und löschen dann die verbleibenden Teile. Unten ist die Komprimierung der beiden lebenden Objekte 1 und 3. Reinigen Sie nach der Komprimierung den Raum darunter. Mit anderen Worten: Im Clean-Teil können neue Objekte zugewiesen werden. 
Der Screenshot unten ist markiert, komprimiert und bereinigt. Bei der markierten komprimierten Speicherbereinigung kann der Speicherplatz im Heap-Bereich voll ausgenutzt werden. Wenn zu viel Speicher vorhanden ist und eine starke Fragmentierung vorliegt, werden mehr „lebende Objekte“ verschoben Der Wirkungsgrad ist relativ gering. Diese Methode kann in Verbindung mit „Kopieren“ verwendet werden, um basierend auf dem Müllstatus des aktuellen Heap-Bereichs auszuwählen, welche Recyclingmethode verwendet wird. Es ergänzt die Vorteile von 
package com.zeluli.gclog;public class GCLogTest {public static void main(String[] args) {
String s = new String("Value");
s = null;
System.gc();
}
}
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der JVM-Speicherbereichsaufteilung und des Garbage-Collection-Mechanismus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!