JVM-Speicherbereich

Speicherbereich

Programmzähler

Diese Funktion ähnelt dem Programmzähler im Prozessor. Sie zeichnet die Adresse des nächsten Bytecodes auf

Der Programmzähler des Prozessors bedient jedoch den Prozess und der Programmzähler in der JVM bedient den Thread

Der Programmzähler der JVM ist also privat für den Thread und der Deklarationszeitraum ist derselbe wie die des Threads. Die Programmzähler zwischen ihnen stören sich nicht

Da es die Adresse des nächsten Bytecodes aufzeichnet, bedient es nicht die native Methode in Java. Die native Methode startet direkt einen Prozess und wird durch den Programmzähler in der CPU gesteuert

Der Programmzähler ist der einzige Bereich in der JVM, der keinen OutOfmemoryError auslöst

Virtual Machine Stack

Dies ist auch dasselbe wie der Stapel in der CPU. Fast so wird beim Eingeben einer Methode ein Stapelrahmen in den Stapel geschoben. Der Stapelrahmen zeichnet die lokale Variablentabelle, den Operandenstapel, die dynamische Verknüpfung usw. auf Methodenausgang. Wenn Sie diese Methode verlassen, öffnen Sie den aktuellen Stapelrahmen

Der Stapel der virtuellen Maschine ist threadprivat, da er auf Methodendienste ausgerichtet ist

Teilweise Die Variablentabelle

Die lokale Variablentabelle zeichnet den Typ der lokalen Variablen in der Methode (z. B. int, boolean, char, ..., Referenztyp) und die Speicheradresse dieser Variablen auf

Operandenstapel

Der Operandenstapel entspricht dem allgemeinen Register in der CPU, in dem die von der logischen Operationseinheit verarbeiteten Werte gespeichert werden Werte aus diesem Bereich müssen gelesen werden (add,cmp,mov,...)

Methodenausgang

Dies zeichnet die auf nächster Schritt, der nach der Verarbeitung der aktuellen Methode ausgeführt werden soll Die Adresse der Anweisung

Nativer Methodenstapel

Der lokale Methodenstapel ähnelt tatsächlich dem Stapel der virtuellen Maschine, außer dass es native Methoden bedient und der Stapel der virtuellen Maschine nur Bytecodes bedient. Service

Heap

In diesem Bereich leben die meisten Objekte . Natürlich steht es auch im Fokus des Garbage Collectors.

Dieser Bereich ist für die Speicherung von Objektinstanzen verantwortlich, und der Speicherplatz des Objekts wird hier zugewiesen. Da sich die meisten Objekte hier befinden, handelt es sich um einen Bereich, der von allen Threads gemeinsam genutzt wird.

Der Heap ist außerdem in den Bereich der neuen Generation und den Bereich der alten Generation unterteilt. Die wichtigsten Überlebenden im Bereich der neuen Generation sind Objekte, die häufig „leben und sterben“. Sie werden häufig geboren und häufig zerstört. Dies ist ein Bereich, der von Müllsammlern ins Visier genommen wird. Das Überleben des Gebiets der alten Generation erfordert stabile Objekte, daher kommt der Müllsammler hier selten vorbei.

Die überwiegende Mehrheit der Objekte hat kurze Überlebenszeiten und lebt in der neuen Generation. Daher ist das Gebiet des Känozoikums normalerweise größer als das Gebiet der Altära.

Methodenbereich

Der Methodenbereich zeichnet die Informationen geladener Klassen auf. Zum Beispiel vollständig qualifizierte Namen (Paketname, Klassenname), Methoden, Felder, Deskriptoren, Parameter, Konstanten, statische Variablen. Dieser Bereich wird auch von allen Threads gemeinsam genutzt.

Dieses Gebiet hat auch einen Namen – das Ewige Zeitalter, was bedeutet, dass dieses Gebiet selten geräumt wird. Da der Bereinigungsbereich einer Klasse sehr klein ist und die Anforderungen zur Bestimmung, ob eine Klasse nicht mehr benötigt wird, anspruchsvoller sind, bereinigt der Garbage Collector diesen Bereich selten.

Laufzeitkonstantenpool

In diesem Bereich werden während der Kompilierung generierte Literal- und Symbolreferenzen aufgezeichnet. Es wird auch von allen Threads geteilt.

Literal

Literal enthält Zeichenfolgen, die durch doppelte Anführungszeichen „“ gekennzeichnet sind, sowie einige grundlegende Daten, die im Code fest codiert sind sind Konstanten.

In jdk1.6 ist der Laufzeitkonstantenpool Teil des Methodenbereichs. Wenn eine Konstante gefunden wird, prüfen Sie zunächst, ob die Konstante bereits im Laufzeitkonstantenpool gespeichert ist. Wenn nicht, kopieren Sie eine Kopie in den Laufzeitkonstantenpool. Jeder nachfolgende Versuch, eine Konstante mit demselben Wert zu erstellen, verweist direkt auf den Laufzeitkonstantenpool.

Ab jdk1.7 wurde der Laufzeitkonstantenpool in den Heap unterteilt. Beim ersten Vorkommen einer Konstante wird diese nicht mehr in den Laufzeitkonstantenpool kopiert, sondern es bleibt eine Referenz im Laufzeitkonstantenpool erhalten, die auf die Speicheradresse verweist, an der die Konstante zum ersten Mal erscheint.

Direkter Speicher

Dieser Bereich ist eigentlich nicht Teil der JVM, sondern gehört zu anderen Prozessen. Wenn eine native Methode aufgerufen wird, kann ein direkter Speicher generiert werden.

Direkter Speicher bezieht sich auf den in der nativen Methode verwendeten Speicherplatz. Beispielsweise verwenden NIO-Operationen native Methoden zum Lesen und Schreiben von Dateien. Zu diesem Zeitpunkt wird ein direkter Speicher generiert, der auf den Speicher (Cache) zum Lesen und Schreiben von Dateien verweist.

Beachten Sie, dass sich der direkte Speicher nicht im JVM befindet, sondern im JVM-Heap eine Referenz verwaltet wird, die auf den direkten Speicher des Speicherplatzes verweist. Dies vermeidet ein häufiges Hin- und Herkopieren von Daten aus dem Speicherbereich und dem Java-Heap bei Vorgängen ähnlich wie bei NIO.