Detaillierte Erläuterung der JVM-Speicherbereichsaufteilung und des Garbage-Collection-Mechanismus

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-Bereich

Der 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 „

junge Generation

“ 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 JVM

einige 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.

Eine Situation wie eine C-Referenz führt nicht zu einem „

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

Nachdem wir über das Referenzzählrecycling gesprochen haben Wir wissen, dass die Referenzzählung leicht zu Problemen mit „zyklischen Referenzen“ führen kann. Um das durch „

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.

Unten sehen Sie ein vereinfachtes Diagramm des von uns gezeichneten Kopiertyps. Es unterteilt den Heap hauptsächlich in zwei Teile. Während der Speicherbereinigung werden lebende Objekte auf einem Heap auf einen anderen Heap kopiert. Der darunter liegende Heap-1-Bereich ist der aktuell verwendete Block, und der Heap-Bereich 2 ist der freie Bereich. Die nicht markierten Speicherblöcke im Heap-Bereich 1, also 2 und 3, sind Müllobjekte, die recycelt werden müssen. Und 1, 4 und 5 sind „lebende Objekte“, die kopiert werden müssen. Weil Block 1 über a auf dem Stapel erreichbar ist und die Blöcke 4 und 5 über c erreichbar sind. Obwohl die Blöcke 2 und 3 Referenzen haben, stammen sie nicht aus dem

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 .

　

Nachdem Sie das Live-Objekt gefunden haben, müssen Sie als Nächstes das Live-Objekt kopieren und in den Heap-2-Bereich kopieren. Natürlich sind die Speicheradressen zwischen Objekten, die in den Heap-Bereich 2 kopiert werden, fortlaufend. Wenn Sie neuen Speicherplatz zuweisen möchten, können Sie ihn direkt aus einem freien Abschnitt des Heaps zuweisen. Dies ist effizienter bei der Zuweisung von Speicherplatz. Nachdem das Objekt kopiert wurde, muss die Referenzadresse aus dem „Nicht-Heap-Bereich“ geändert werden. Wie unten gezeigt.

　

Nachdem der Kopiervorgang abgeschlossen ist, können wir den gesamten Speicherplatz im Heap-Bereich 2 direkt recyceln. Das Folgende ist das Endergebnis nach dem Kopieren und Recycling. Nachdem der untere Heap-Bereich 1 geleert wurde, können die kopierten Objekte empfangen werden. Wenn die Speicherbereinigung im Heap-Bereich 2 durchgeführt wird, werden die Live-Objekte im Heap-Bereich 2 in den Heap-Bereich 1 kopiert.

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 „

lebenden Objekte

“ 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. 　

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

„Kopieren“

. 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

" Generation

“ 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 (Eden Garden) und Survivor Sprace (Überlebensbereich)

. 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

Survivor Sprace

ü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.

Werfen wir einen Blick auf die vollständigen Schritte des spezifischen Arbeitsprinzips der „Generations-Garbage Collection“, um die Ausführungsmethode der „Generations-Garbage Collection“ intuitiv zu spüren.

1. Vor der Müllabfuhr

Das Bild unten wartet auf „

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

Das folgende Bild ist ein Vergleich der oben genannten Der Garbage-Collection-Prozess der Heap-Steuerung. Wie wir auf dem Bild oben sehen können, ist der Bereich „An“ ein leerer Bereich und kann kopierte Objekte aufnehmen. Da die „junge Generation“ dazu neigt, Speichermüll zu erzeugen, wird eine Methode zum „Kopieren“ des Speicherrecyclings übernommen. Wir kopieren die „Live-Objekte“ in den beiden Heap-Blöcken

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.

Für die Garbage Collection in der „alten Generation“ wird die „Mark-Compression“-Garbage Collection verwendet. Zunächst werden die lebenden Objekte „markiert“.

　

3. Das Ergebnis nach der Müllabfuhr

Unten ist das „ Punkte „Generieren“ spezifische Ergebnisse nach der Garbage Collection. Aus dem Diagramm unten können wir ersehen, dass die Live-Objekte in Eden Space und From in den To-Bereich kopiert werden und sich auch der Speicherplatz des Heap-Bereichs der „alten Generation“ stark verändert hat. Darüber hinaus gibt es in der „alten Generation“ mehr große Objekte, die aus dem Von-Bereich kopiert wurden. Die Einzelheiten sind wie folgt.

　

4. Eclipse GC-Protokollkonfiguration und -analyse

Oben wurde so viel gesagt, lassen Sie uns intuitiv erleben, wie Sie den Garbage-Collection-Prozess anzeigen und die Protokollinformationen der Garbage-Collection in Eclipse analysieren. Standardmäßig werden der Garbage-Collection-Prozess und das Protokolldrucken nicht angezeigt. Sie müssen relevante Konfigurationselemente in der laufenden Konfiguration hinzufügen, um das Garbage-Collection-Protokoll zu drucken. In diesem Abschnitt werfen wir einen Blick auf die Konfiguration der Garbage-Collection-Protokollierung in

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

Fügen Sie die entsprechenden Konfigurationselemente in den Laufeinstellungen von Eclipse hinzu, die erst danach gedruckt werden Entsprechende Protokollinformationen. Wählen Sie unser Projekt aus und suchen Sie dann die Option

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:

package com.zeluli.gclog;public class GCLogTest {public static void main(String[] args) {
        String s = new String("Value");
        s = null;
        System.gc();
    }
}

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.

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!