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.
