Heim  >  Artikel  >  Java  >  Detaillierte grafische Erläuterung des JVM-Ladevorgangs einer Klasse

Detaillierte grafische Erläuterung des JVM-Ladevorgangs einer Klasse

黄舟
黄舟Original
2017-03-08 11:08:091285Durchsuche

In diesem Artikel wird hauptsächlich der Prozess des JVM-Ladens einer Klasse vorgestellt. Es hat einen sehr guten Referenzwert, schauen wir es uns mit dem Editor unten an

Klassenladeprozess

Java-Quellcode wird in Klassenbytecode, JVM Load, kompiliert Schreiben Sie die Bytecode-Klassendatei, die die Klassendaten beschreibt, in den Speicher und überprüfen, konvertieren, analysieren und initialisieren Sie die Daten, um schließlich einen Java-Typ zu bilden, der direkt von der virtuellen Maschine verwendet werden kann. Dies ist der Klassenlademechanismus der virtuellen Maschine Maschine.

Eine Klasse beginnt mit dem Laden in den Speicher der virtuellen Maschine, bis sie aus dem Speicher entladen wird. Ihr Lebenszyklus umfasst: Laden, Überprüfung, Vorbereitung, Lösung. Es gibt sieben Phasen: Initialisierung, Verwendung und Entladen. wobei die drei Teile Verifizierung, Vorbereitung und Analyse gemeinsam als Links bezeichnet werden.

Die Reihenfolge der fünf Phasen des Ladens (Ladens), Verifizierens, Vorbereitens, Initialisierens und Entladens ist festgelegt. Der Ladevorgang der Klasse muss in dieser Reihenfolge beginnen Die Analysephase ist nicht unbedingt erforderlich; sie kann in einigen Fällen nach der Initialisierung für die dynamische Bindungsfunktion zur Laufzeit beginnen (auch dynamische Bindung oder späte Bindung genannt, z. B. Überschreiben).

1. Laden:

Während der Ladephase erledigt die virtuelle Maschine hauptsächlich drei Dinge:

1 a Der vollständig qualifizierte Name einer Klasse, um den binären Bytestrom abzurufen, der diese Klasse definiert.

2. Konvertieren Sie die durch diesen Bytestream dargestellte statische Speicherstruktur in die Laufzeitdatenstruktur des Methodenbereichs.

3. Generieren Sie ein java.lang.Class-Objekt, das diese Klasse im Java-Heap als Zugriffseingang auf die Methodenbereichsdaten darstellt

Im Vergleich zu anderen Phasen des Klassenladevorgangs ist die Ladephase (vorbereitend gesprochen, die Aktion zum Erhalten des binären Bytestroms der Klasse in der Ladephase) die am besten kontrollierbare Phase während der Entwicklungsphase, weil die Ladephase Dies kann mit dem vom System bereitgestellten Klassenlader (ClassLoader) oder mit einem benutzerdefinierten Klassenlader erfolgen. Entwickler können die Erfassungsmethode des Bytestreams steuern, indem sie ihren eigenen Klassenlader definieren.

Nach Abschluss der Ladephase wird der binäre Bytestrom außerhalb der virtuellen Maschine im Methodenbereich gemäß dem von der virtuellen Maschine benötigten Format gespeichert. Das Datenspeicherformat im Methodenbereich wird durch die virtuelle Maschine definiert Maschinenimplementierung. Die virtuelle Maschine. Die spezifische Datenstruktur dieses Bereichs ist nicht angegeben. Anschließend wird ein Objekt der Klasse java.lang.Class im Java-Heap instanziiert. Dieses Objekt dient dem Programm als externe Schnittstelle für den Zugriff auf diese Datentypen im Methodenbereich.

2. Überprüfung:

Der Zweck der Überprüfungsphase besteht darin, sicherzustellen, dass die im Bytestrom der Klassendatei enthaltenen Informationen den JVM-Spezifikationen entsprechen und werden der JVM keinen Schaden zufügen. Wenn die Überprüfung fehlschlägt, wird eine java.lang.VerifyError-Ausnahme oder eine Ausnahme ihrer Unterklasse ausgelöst. Der Überprüfungsprozess ist in vier Phasen unterteilt

1. Überprüfung des Dateiformats: Überprüfen Sie, ob die Byte-Stream-Datei der Klassendateiformatspezifikation entspricht und von der aktuellen virtuellen Maschine korrekt verarbeitet werden kann.

2. Metadatenüberprüfung: Es handelt sich um eine semantische Analyse der durch den Bytecode beschriebenen Informationen, um sicherzustellen, dass die beschriebenen Informationen den Spezifikationen der Java-Sprache entsprechen.

3. Bytecode-Überprüfung: Sie analysiert hauptsächlich den Datenfluss und den Kontrollfluss, um sicherzustellen, dass die Methoden der überprüften Klasse die virtuelle Umgebung zur Laufzeit nicht beschädigen. Maschine.

4. Symbolreferenzüberprüfung: Die Symbolreferenzüberprüfung erfolgt, wenn die virtuelle Maschine die Symbolreferenz in eine direkte Referenz umwandelt . .

3. Vorbereitung:

Die Vorbereitungsphase weist Speicher für Variablen zu und legt die Initialisierung von Klassenvariablen fest. Zu diesem Zeitpunkt werden nur Klassenvariablen (statisch geänderte Variablen) zugewiesen, keine Klasseninstanzvariablen. Für Variablen, die nicht mehr endgültig sind, setzt die JVM sie auf „Nullwert“ anstelle des Werts ihrer Zuweisungsanweisung:

private static int size = 12

Dann in dieser Phase , Der Wert der Größe ist 0, nicht 12. Durch final geänderte Klassenvariablen werden reale Werte zugewiesen.

4. Parsen:

Die Parsing-Phase ist der Prozess des Ersetzens von Symbolreferenzen im Konstantenpool der virtuellen Maschine durch direkte Referenzen.

Symbolische Referenz: Eine symbolische Referenz ist eine Reihe von Symbolen zur Beschreibung des referenzierten Zielobjekts. Das Symbol kann jede Form eines Literals sein, solange das Ziel bei der Verwendung eindeutig lokalisiert werden kann. Symbolische Referenzen haben nichts mit dem von der virtuellen Maschine implementierten Speicherlayout zu tun und das referenzierte Zielobjekt muss nicht unbedingt in den Speicher geladen werden.

Direkte Referenz: Eine direkte Referenz kann ein Zeiger sein, der direkt auf das Zielobjekt zeigt, ein relativer Offset oder ein Handle, der das Ziel indirekt lokalisieren kann. Direkte Referenzen beziehen sich auf die Implementierung des Speicherlayouts der virtuellen Maschine. Die direkten Referenzen, die durch dieselbe Symbolreferenz auf verschiedenen Instanzen der virtuellen Maschine übersetzt werden, sind im Allgemeinen nicht gleich. Wenn eine direkte Referenz vorhanden ist, muss das Referenzziel bereits im Speicher vorhanden sein.

Die Spezifikation der virtuellen Maschine legt nicht den genauen Zeitpunkt fest, zu dem die Analysephase stattfindet. Sie erfordert nur 13 Vorgänge wie anewarry, checkcast, getfield, instanceof, invokeinterface, invokespecial, invokestatic, invokevirtual, multianewarray, new, putfield und putstatic. Vor den Bytecode-Anweisungen von Symbolreferenzen werden zuerst die von ihnen verwendeten Symbolreferenzen analysiert, sodass die Implementierung der virtuellen Maschine je nach Bedarf beurteilt, ob die Symbolreferenzen im Konstantenpool analysiert werden sollen, wenn die Klasse vom Lader geladen wird, oder ob gewartet werden soll bis eine Symbolreferenz verwendet werden soll, bevor sie aufgelöst wird.

Die Analyseaktion wird hauptsächlich für vier Arten von Symbolreferenzen durchgeführt: Klassen oder Schnittstellen, Felder, Klassenmethoden und Schnittstellenmethoden. Entspricht den vier Konstantentypen CONSTANT_Class_Info, CONSTANT_Fieldref_Info, CONSTANT_Methodef_Info und CONSTANT_InterfaceMethoder_Info im kompilierten Konstantenpool.

1. Klassen- und Schnittstellenanalyse

2. Feldanalyse

3. Klassenmethodenanalyse

4. Schnittstellenmethodenanalyse

5. Initialisierung:

Die Initialisierungsphase einer Klasse ist der letzte Schritt im Klassenladeprozess. In der Vorbereitungsphase wurde der Klassenvariablen der vom System erforderliche Anfangswert zugewiesen In der Initialisierungsphase werden Klassenvariablen und andere Ressourcen gemäß dem subjektiven Plan initialisiert, den der Programmierer durch das Programm erstellt hat, oder es kann aus einer anderen Perspektive ausgedrückt werden: Die Initialisierungsphase besteht darin, den Klassenkonstruktor

auszuführen 6. Verwendung:

Neuer Thread ---- Programmzähler ---- JVM-Stack-Ausführung (Objektreferenz) ----- Heapspeicher (direkte Referenz) ---- Methode Bereich

7 .Deinstallieren:

GC Garbage Collection


Das obige ist der detaillierte Inhalt vonDetaillierte grafische Erläuterung des JVM-Ladevorgangs einer Klasse. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn