Eine eingehende Analyse der Speicherverwaltung in Java Virtual Machines

Dieser Artikel bietet Ihnen eine ausführliche Analyse der Speicherverwaltung in Java Virtual Machines. Ich hoffe, dass er für Freunde hilfreich ist.

Laufzeitspeicher umfasst:

1. Methodenbereich

2. Virtual Machine Stack (VM Stack)

3. Native Method Stack (Native Method Stack) Heap)

4. Programmzähler registrieren

Programmzähler

5. ist ein Vergleich. Der geringe Speicherplatz kann als Zeilennummernindikator für den vom aktuellen Thread ausgeführten Bytecode angesehen werden. (Der Bytecode-Interpreter funktioniert, indem er den Wert dieses Zählers ändert, um die Bytecode-Anweisungen auszuwählen, die ausgeführt werden müssen.)

Da das Multithreading der Java Virtual Machine durch abwechselndes Wechseln von Threads und Zuweisen von Prozessorausführungszeit implementiert wird, führt ein Prozessor zu jedem Zeitpunkt nur Anweisungen in einem Thread aus. Um nach dem Threadwechsel zur korrekten Ausführungsposition zurückzukehren, muss daher jeder Thread über einen unabhängigen Programmzähler verfügen. Die Zähler zwischen den einzelnen Threads beeinflussen sich nicht gegenseitig und werden unabhängig voneinander gespeichert „der Erinnerung.

Wenn der Thread eine Java-Methode ausführt, zeichnet dieser Zähler die Adresse der ausgeführten Bytecode-Anweisung der virtuellen Maschine auf. Wenn es sich um eine native Methode handelt, ist der Zählerwert leer.

Java Virtual Machine Stack

Der Java Virtual Machine Stack ist ebenfalls Thread-privat und hat denselben Lebenszyklus wie der Thread.

Der Stapel der virtuellen Maschine stellt das Speichermodell der Ausführung dar: Wenn jede Methode ausgeführt wird, wird ein Stapelrahmen erstellt, um lokale Variablentabellen, Operandenstapel, dynamische Links, Methodenausgänge und andere Informationen zu speichern. Der Prozess vom Aufruf bis zum Abschluss der Ausführung jeder Methode entspricht dem Prozess, bei dem ein Stapelrahmen in den Stapel geschoben und aus dem Stapel in der virtuellen Maschine herausgeholt wird.

Der Stapel bezieht sich im Allgemeinen auf den Stapel der virtuellen Maschine oder den Teil der lokalen Variablentabelle des Stapels der virtuellen Maschine.

Die lokale Variablentabelle speichert verschiedene grundlegende Datentypen, die zur Kompilierungszeit bekannt sind, Objektreferenzen und returnAddress-Typen (die auf die Adresse einer Bytecode-Anweisung zeigen).

Unter diesen belegen Daten vom Typ „Long“ und „Double“ zwei lokale Variablenräume (Slots), während andere Datentypen nur einen belegen.

Der von der lokalen Variablentabelle benötigte Speicherplatz wird zur Kompilierzeit zugewiesen. Bei der Eingabe einer Methode wird die Menge an lokalem Skalarraum, den die Methode im Frame zuweisen muss, vollständig bestimmt und ändert sich während der Kompilierung nicht Ausführung der Methode. Die Größe der lokalen Variablentabelle.

Die Spezifikation der virtuellen Maschine legt zwei Ausnahmebedingungen für diesen Bereich fest: Wenn die vom Thread angeforderte Stapeltiefe größer ist als die von der virtuellen Maschine zulässige Tiefe, wird eine StackOverflowError-Ausnahme ausgelöst, wenn der Stapel der virtuellen Maschine dies kann dynamisch erweitert werden, wenn die Erweiterung Wenn nicht genügend Speicher beantragt werden kann, wird eine OutOfMemoryError-Ausnahme ausgelöst.

Lokaler Methodenstapel

Die Rolle des virtuellen Maschinenstapels ist sehr ähnlich. Der lokale Methodenstapel bedient die von der virtuellen Maschine verwendeten nativen Methoden. Es gibt keine verbindlichen Regeln zu Sprache, Verwendung und Datenstrukturen in nativen Methoden.

Java-Heap

Für die meisten Anwendungen ist der Heap der größte Speicherbereich, der von der virtuellen Maschine verwaltet wird.

Der Heap ist ein von allen Threads gemeinsam genutzter Speicherbereich und wird beim Start der virtuellen Maschine erstellt. Der einzige Zweck dieses Speicherbereichs besteht darin, Objektinstanzen zu speichern, und fast allen Objektinstanzen wird hier Speicher zugewiesen (alle Objektinstanzen und Arrays).

Der Java-Heap ist der Hauptbereich, der vom Garbage Collector verwaltet wird. Da moderne Collectors grundsätzlich die Striped-Collection-Methode verwenden, kann der Java-Heap auch in neue Generation und alte Generation unterteilt werden.

Aus Sicht der Speicherzuweisung kann der Thread-gemeinsame Java-Heap in mehrere Thread-private Zuweisungspuffer (Thread Local Allocation Buffer, TLAB) unterteilt werden.

Der Java-Heap kann physisch diskontinuierlichen Speicherplatz verarbeiten, solange er logisch kontinuierlich ist. Bei der Implementierung kann es als feste Größe oder skalierbar implementiert werden, gängige virtuelle Maschinen werden jedoch als skalierbar implementiert (-Xms, -Xmx-Steuerung).

Methodenbereich

Wie der Java-Heap handelt es sich um einen von jedem Thread gemeinsam genutzten Speicherbereich. Er wird zum Speichern von Klasseninformationen, Konstanten, statischen Variablen und Just-in-Time-Compilern verwendet Informationen, die vom Code der virtuellen Maschine geladen wurden, und andere Daten. Obwohl die Java Virtual Machine den Methodenbereich als logischen Teil des Heaps beschreibt, verfügt sie über einen Alias ​​namens Non-Heap, um ihn vom Java-Heap zu unterscheiden.

Zusätzlich dazu, dass kein zusammenhängender Speicher wie beim Java-Heap erforderlich ist und die Option einer festen Größe oder Erweiterbarkeit besteht, können Sie sich auch dafür entscheiden, keine Garbage Collection zu implementieren. Die Garbage Collection findet in diesem Bereich selten statt, existiert aber nicht dauerhaft wie die ewige Generation nach dem Betreten des Methodenbereichs. Das Speicherrecycling in diesem Bereich zielt hauptsächlich auf das Recycling der konstanten Pool- und Entladetypen ab.

Laufzeitkonstantenpool

ist Teil des Methodenbereichs. Neben der Klassenversion, Feldern, Methoden, Schnittstellen und anderen Informationen enthält die Klassendatei Informationen. Eine weitere Information ist die Konstantenpooltabelle, die für verschiedene während der Kompilierung generierte Literale und Symbolreferenzen verwendet wird. Dieser Inhalt wird nach dem Laden der Klasse im Laufzeitkonstantenpool gespeichert.

Es ist dynamisch. Nur der Inhalt des in der Klassendatei vorinstallierten Konstantenpools kann während der Laufzeit in den Pool eingefügt werden Developers. ist die intern() der String-Klasse.

Erstellung von Objekten

Wenn die virtuelle Maschine eine neue Anweisung erhält, prüft sie zunächst, ob die Parameter dieser Anweisung im gefunden werden können Konstantenpool. Ein symbolischer Verweis auf eine Klasse. Er prüft, ob die durch diesen symbolischen Verweis dargestellte Klasse geladen, aufgelöst und initialisiert wurde. Wenn nicht, muss zuerst der entsprechende Klassenladevorgang durchgeführt werden.

Reservieren Sie Speicher für neue Objekte nach der Klassenladeprüfung. Die von einem Objekt benötigte Speichermenge wird vollständig bestimmt, nachdem die Klasse geladen wurde.

Nachdem die Speicherzuweisung abgeschlossen ist, wird der Speicherplatz, der der virtuellen Maschine zugewiesen werden muss, auf Null initialisiert. Wenn TLAB verwendet wird, kann diese Arbeit im Voraus ausgeführt werden, wenn TLAB zugewiesen wird.

Als nächstes nimmt die virtuelle Maschine die notwendigen Einstellungen für das Objekt vor, z. B. von welcher Klasse das Objekt eine Instanz ist, wie man die Metadateninformationen der Klasse findet, den Hash-Code des Objekts und das Alter der GC-Generierung des Objekts und andere Informationen. Diese Informationen werden im Objektheader des Objekts platziert.

Nach Abschluss des vorherigen Schritts ist die Aufgabe für die virtuelle Maschine abgeschlossen, aber aus Sicht des Java-Programms hat die Objekterstellung gerade erst begonnen und wurde noch nicht ausgeführt.

Speicherlayout von Objekten

Das Layout des Objektspeichers im Speicher kann in drei Teile unterteilt werden: Objektkopf, Instanzdaten und Ausrichtungsfüllung.

Der Objektheader der virtuellen HotSpot-Maschine besteht aus zwei Teilen:

1. Speichert die Laufzeitdaten des Objekts selbst, wie Hash, GC-Generierungsalter, Sperrstatus-Flag und Thread Haltesperre, voreingenommene Thread-ID, voreingenommener Zeitstempel usw. Die Datenlänge in virtuellen 32-Bit- und 64-Bit-Maschinen beträgt 32 Bit bzw. 64 Bit, was offiziell als „Mark Word“ bezeichnet wird.

2. Typzeiger, der der Zeiger auf die Klassenmetadaten des Objekts ist. Die virtuelle Maschine verwendet diesen Zeiger, um zu bestimmen, zu welcher Klasse das Objekt gehört. Wenn es sich bei dem Objekt um ein Java-Array handelt, muss im Objektheader ein Datenelement vorhanden sein, um die Länge des Arrays aufzuzeichnen, da die virtuelle Maschine die Größe des Java-Objekts anhand der Metadaten gewöhnlicher Java-Objekte bestimmen kann, dies jedoch nicht Bestimmen Sie die Größe des Arrays anhand der Metadaten.

Objektzugriffspositionierung (P48)

Referenzdaten auf dem Java-Programmstapel können über die folgenden zwei gängigen Methoden auf Objektinstanzen im Heap zugreifen.

Handle: Im Java-Heap wird ein Teil des Speichers zugewiesen, der als Handle verwendet wird. Die Referenz speichert die Handle-Adresse dieses Objekts. Das Handle enthält die spezifischen Eigenschaften der Objektinstanzdaten und Typdaten.

Direkter Zeiger: Beim Java-Heap-Objektlayout müssen Sie überlegen, wie Sie den Zugriff auf typdatenbezogene Informationen verhindern können.

Verwandte Empfehlungen:

Detaillierte Einführung in den von der Java Virtual Machine verwalteten Speicherlaufzeitdatenbereich

Detaillierte Erläuterung von JAVA mit Bildern und Text Wissen über virtuelle Maschinen – JVM-Speichermodell

Das obige ist der detaillierte Inhalt vonEine eingehende Analyse der Speicherverwaltung in Java Virtual Machines. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!