Detaillierte grafische und textliche Erläuterung des Wissens rund um die virtuelle JAVA-Maschine – JVM-Speichermodell

Kürzlich habe ich ein sehr klassisches Java-Buch gelesen: „In- Depth Understanding of Java Virtual Machine, Second Edition“. Ich habe es vor ein paar Jahren gelesen, war aber damals noch nicht damit vertraut, also habe ich war verwirrt und verwirrt, also habe ich aufgehört, es zu lesen. Wenn ich jetzt zurückblicke, finde ich, dass es tatsächlich gut geschrieben ist und ich viele Wissenspunkte verstehen kann. Es ist auch sehr tiefgründig und hat viel gewonnen. Später habe ich vor, eine Reihe von Artikeln basierend auf dem Inhalt dieses Buches zu schreiben, um das Wissen im Zusammenhang mit der Java Virtual Machine eingehend zu erlernen und zu überprüfen.

Nach dem Umzug letztes Wochenende wurde das Breitband zu Hause nicht repariert. Ich habe es N-mal dem Kundendienst der Telekom gemeldet und morgen früh endlich einen Termin mit einem Techniker vereinbart, um das Breitband zu migrieren Tage, an denen man länger als eine Woche ohne Internet ist. Ich war in dieser Zeit mit verschiedenen Dingen beschäftigt. Ich habe meinen Blog eine Woche lang nicht aktualisiert, bevor ich mit dem Schreiben aufhöre. ! Nutzen Sie das morgige Wochenende, um einige der Lerninhalte dieser Woche auf dem Firmencomputer aufzuzeichnen.

1. Übersicht über das JVM-Speichermodell

Das JVM-Speichermodell ist eigentlich ganz einfach:

1 Java-Heap, Java-Stack (d. h. Stapel virtueller Maschinen), lokaler Methodenstapel, Methodenbereich und Programmzähler.

2. Ob geteilt werden soll: Der Methodenbereich und der Heap-Bereich werden von Threads gemeinsam genutzt, und der Stapel der virtuellen Maschine, der lokale Methodenstapel und der Programmzähler sind Thread-privat und werden auch als Thread bezeichnet. Jeder Bereich speichert unterschiedliche Inhalte. Diese beiden Wissenspunkte müssen im Auge behalten werden, da sie die Grundlage für die Beherrschung des JVM-Speichermodells bilden.

2. Programmzähler

Der Programmzähler in der JVM ist ein kleiner Speicherbereich, aber dieser Speicherbereich ist sehr interessant. Es gibt 3 Hauptfunktionen:

1. Speicherinhalt: Für gewöhnliche Java-Methoden (d. h. Methoden, die nicht mit dem nativen Schlüsselwort geändert werden) wird die Adresse der aktuellen Anweisung während der Ausführung gespeichert . Für die native Methode ist es leer (undefiniert). Denn beim Aufrufen der lokalen Methode wurde möglicherweise die Speicheradresse der virtuellen JVM-Maschine überschritten.

2. Thread privat: Warum ist der Programmzähler privat für den Thread? Anhand des Speicherinhalts ist es leicht zu verstehen, dass bei der Ausführung mehrerer Threads nicht bekannt ist, welche Adresse der aktuelle Thread ausführt Geben Sie nach der Ausführung ein, wenn der langsame Thread nach der Ausführung zurückkommt und feststellt, dass sich seine Adresse geändert hat. Wäre das nicht chaotisch?

3. Es ist der einzige Bereich in der JVM, der keinen Speicherüberlauf (OutOfMemoryError) meldet.

3. Der Stapel der virtuellen Maschine speichert hauptsächlich Stapelrahmen, Operandenstapel und dynamische Links sowie Methodenexportinformationen . In der lokalen Variablentabelle werden einige in der Methode definierte lokale Variablen, Objektreferenzen, Parameter und Methodenrückgabeadressen usw. gespeichert. Die Größe des von der lokalen Variablentabelle belegten Speicherplatzes kann zur Kompilierzeit bestimmt werden. Wenn die Methode ausgeführt wird, ändert sich die Speicherplatzgröße der lokalen Variablentabelle nicht. Dies ist in Kombination mit dem in der lokalen Variablentabelle gespeicherten Inhalt leicht zu verstehen Variablentabelle. Der Operandenstapel kann als Laden und Entladen der Daten der aktuellen Operation verstanden werden. Bei den 64-Bit-Typen Long und Double belegt jeder Operand eine Breite von 2 Wörtern (Slot), während andere Operandentypen eine Breite von einem Wort (Slot) belegen. Beim Aufruf jeder Methode wird ein Stapelrahmen erstellt, und der Ausführungsprozess entspricht dem Vorgang, bei dem ein Stapelrahmen in den Stapel der virtuellen Maschine verschoben und aus dem Stapel herausgeholt wird. Bezüglich des Inhalts von Stack-Frames können Sie auf einen Blog eines Internetnutzers verweisen: https://blog.csdn.net/xtayfjp..., der sehr gut und detailliert ist. Hier ist ein Bild des Stapelrahmens, um es auf einen Blick zu verdeutlichen.

Es gibt zwei Situationen bezüglich eines Stapelspeicherüberlaufs der virtuellen Maschine:

1 Die vom Thread angeforderte Stapeltiefe überschreitet die von der virtuellen Maschine zulässige Tiefe. und es wird eine Fehlermeldung „StackOverflowError“ ausgegeben. Wenn wir diese Ausnahme im Code sehen, sollten wir davon ausgehen, dass möglicherweise ein Problem mit dem Stapel der virtuellen Maschine vorliegt.

2. Wenn der Stapel der virtuellen Maschine dynamisch erweitert werden kann (die meisten aktuellen JVMs können dynamisch erweitert werden, die JVM ermöglicht jedoch auch Stapel virtueller Maschinen mit fester Länge), wird dies der Fall sein, wenn während der Erweiterung nicht genügend Speicher beantragt werden kann throw Eine OutOfMemoryError-Ausnahme tritt auf.

4. Lokaler Methodenstapel

Dieser Wissenspunkt ist relativ einfach. Die Funktionen des lokalen Methodenstapels und des virtuellen Maschinenstapels sind ähnlich, sie dienen jedoch nur, wenn die JVM die native Methode aufruft und die JVM Die von nativen Methoden verwendete Sprache (wenn Java beispielsweise in der C-Sprache implementierte Funktionen aufruft, muss es native Methoden definieren, um sie zu implementieren), Verwendungsmethoden und Datenstrukturen sind nicht obligatorisch, sodass verschiedene virtuelle Maschinen implementiert werden können sie frei. Darüber hinaus kombiniert die virtuelle HotSpot-Maschine den lokalen Methodenstapel und den Stapel der virtuellen Maschine direkt in einem. Ähnlich wie der Stapel der virtuellen Maschine löst auch der lokale Methodenstapel StackOverflowError und OutOfMemoryError aus.

5. Methodenbereich

Der Methodenbereich ist ein relativ wichtiger Bereich. Die Java Virtual Machine-Spezifikation beschreibt den Methodenbereich als logischen Teil des Heaps, der jedoch dem Heap (Heap-Bereich) entspricht ), wird es auch Non-Heap (Nicht-Heap-Bereich) genannt. Hauptsächlich werden statische Variablen, Konstanten (einschließlich Laufzeitkonstanten), Informationen zum Laden von Klassen und mit Java kompilierter Code gespeichert. Dieser Teil des Raums muss nicht kontinuierlich sein. Sie können zwischen fester Größe und erweiterbarer Größe wählen. Normalerweise gibt es in diesem Teil keinen GC, da der Recyclingeffekt dieser Objekte normalerweise nicht zufriedenstellend ist Daher können Sie sich dafür entscheiden, die Garbage Collection nicht zu implementieren. Dieser Bereich wird auch als persistente Generierung bezeichnet. Wenn dieser Speicherbereich nicht ausreicht, wird auch eine OutOfMemoryError-Ausnahme gemeldet.

6. Heap-Bereich

Der Java-Heap-Bereich ist der fetteste Bereich im JVM-Speicher, da hier alle Objektinstanzen und Array-Objekte gespeichert werden. Dieser Bereich wird von Threads gemeinsam genutzt und beim Start der JVM erstellt. Denken Sie darüber nach, ob der Speicher explodieren sollte, wenn ein so großer Bereich für Threads privat ist. Gemäß der Java Virtual Machine-Spezifikation kann der Inhalt des Heap-Bereichs physisch diskontinuierlich sein, solange er logisch kontinuierlich ist. Bei der Implementierung kann er eine feste Größe haben oder erweiterbar sein. Normalerweise verwenden wir die Speicherparameter -Xms und -Xmx werden verwendet, um die Heap-Größe anzupassen. Der Java-Heap-Bereich ist nach unterschiedlichen Lebenszyklen in die neue und die alte Generation unterteilt. Die neue Generation kann in Eden- und Survivor-Bereiche unterteilt werden, und Survivor kann in Survivor1 und Survivor2 unterteilt werden. Diese beiden verwenden normalerweise nur einen von ihnen, und der andere wird verwendet, um überlebende Objekte während der GC aufzubewahren. Die meisten neuen Objekte werden im Eden-Bereich gespeichert, z. B. ein großes Array oder ein Listenobjekt. Sie können den JVM-Parameter -XX:PretenureSizeThreshold verwenden, um Objekte, die die angegebene Größe überschreiten, direkt in der alten Generation zu speichern Beachten Sie, dass Sie beim Schreiben eines Programms versuchen sollten, zu vermeiden, dass große Objekte, die leben und sterben, in die alte Generation gelangen, da die Kosten für GC in der alten Generation höher sind als in der jungen Generation. Das Standardgrößenverhältnis von Eden und Survivor beträgt 8:1:1, und der Standard-GC-Algorithmus für die neue Generation ist der Replikationsalgorithmus. Der Standard-GC-Algorithmus für die alte Generation ist Mark-Collation. Diese beiden GC-Algorithmen werden im nächsten Blog erläutert.

Wenn im Heap nicht genügend Speicher vorhanden ist, wird eine OutOfMemoryError-Ausnahme ausgelöst. Bezüglich des Speichermodells des Heap-Bereichs können Sie sich auf die folgenden Bilder beziehen:

Verwandte Artikel:

Detaillierte Übersicht über Java Virtual Machine

Detaillierte Erklärung des Funktionsprinzips der Java Virtual Machine (Bilder und Texte)

Ähnliche Videos:

Black Horse Cloud Classroom 8-tägiges ausführliches Python-Video-Tutorial

Das obige ist der detaillierte Inhalt vonDetaillierte grafische und textliche Erläuterung des Wissens rund um die virtuelle JAVA-Maschine – JVM-Speichermodell. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!