Heim  >  Artikel  >  Java  >  Detaillierte Erläuterung des Problems der Erstellung übergeordneter Klassenobjekte bei der Java-Vererbung

Detaillierte Erläuterung des Problems der Erstellung übergeordneter Klassenobjekte bei der Java-Vererbung

PHP中文网
PHP中文网Original
2017-06-20 10:18:431737Durchsuche

Es stimmt, dass der Konstruktor der übergeordneten Klasse aufgerufen wird, aber das Objekt der übergeordneten Klasse wird überhaupt nicht erstellt, sondern der Konstruktor der übergeordneten Klasse wird aufgerufen, um die Eigenschaften zu initialisieren.

Es ist wirklich Unsinn zu sagen, dass der Aufruf der Konstruktormethode der übergeordneten Klasse dem Erstellen eines übergeordneten Klassenobjekts entspricht.
Die neue Anweisung öffnet Platz, der zum Speichern verschiedener Attributreferenzen von Objekten verwendet wird. Wenn Sie den Bytecode dekompilieren, werden Sie feststellen, dass es nur eine neue Anweisung gibt, also wird ein Platz geöffnet und ein Objekt darin platziert jeden Raum.
Dann ruft die Unterklasse die Eigenschaften, Methoden usw. der übergeordneten Klasse auf, die kein instanziiertes Objekt ist.
Im Bytecode verfügt die Unterklasse über einen übergeordneten Klassenindex vom Typ u2, der zum Typ CONSTANT_Class_info gehört und über die Beschreibung von CONSTANT_Class_info gefunden werden kann.
In Ihrer Methode werden die Attributnamen darauf analysiert und dann wird der tatsächliche Variableninhalt in dem von new erstellten Bereich gespeichert. . .
Das Super-Schlüsselwort greift nur auf die Daten in einem bestimmten Teil dieses Bereichs zu (d. h. dem Teil des Speichers, der für die Speicherung der Daten der übergeordneten Klasse vorgesehen ist). . . . . .

Der Standard-Hashcode und die Gleichheit (direkter Vergleich ==) sind gleich, sodass sie sich grundsätzlich im selben Bereich befindet und es kein separates übergeordnetes Klassenobjekt gibt.


Wenn eine Unterklasse zur Verwendung zwangsweise in eine übergeordnete Klasse konvertiert werden kann, liegt das daran, dass die Java Virtual Machine über die Konzepte des statischen Typs (Aussehenstyp) und des tatsächlichen Typs verfügt.
Zum Beispiel Object t=new Point(2,3);
Dann gehört Object zum statischen Typ (Erscheinungsbildtyp) und Point zum tatsächlichen Typ.
Sowohl der statische Typ als auch der tatsächliche Typ können sich im Programm ändern. Der Unterschied besteht darin, dass die Änderung des statischen Typs nur bei der Verwendung erfolgt, während sich der statische Typ der Variablen selbst nicht ändert und der endgültige statische Typ währenddessen bekannt ist Kompilierung. ;Das Änderungsergebnis des tatsächlichen Variablentyps kann nur während der Laufzeit ermittelt werden. Der Compiler kennt beim Kompilieren nicht den tatsächlichen Typ der Variablen.


Speicher Java-Objekt Das Layout wird durch die Klasse bestimmt, zu der das Objekt gehört. Man kann auch sagen, dass beim Laden einer Klasse in die virtuelle Maschine das Layout der von dieser Klasse erstellten Objekte bereits festgelegt wurde.

Speicherlayout von Java-Objekten in Hotspot:
Jedes Java-Objekt besteht aus einem Objektkopf und einem Objektkörper im Speicher.

Der Objektheader speichert die Metainformationen des Objekts, einschließlich der Referenz auf das Klassenobjekt, zu dem das Objekt gehört, sowie einige Informationen über den Hashcode und den Monitor.
Der Objektkörper speichert hauptsächlich die Instanzfelder des Java-Objekts selbst und die von der übergeordneten Klasse geerbten Instanzfelder, und das interne Layout erfüllt die folgenden Regeln:
Regel 1: Jedes Objekt wird mit einer Granularität von 8 verarbeitet Bytes ausgerichtet.
Regel 2: Instanzfelder werden nach der folgenden Priorität angeordnet: Ganzzahl- und Gleitkommatypen sowie kurze Ganzzahltypen und schließlich Referenztypen. Diese Instanzfelder sind entsprechend ihrer jeweiligen Einheiten ausgerichtet.
Regel 3: Instanzfelder in verschiedenen Klassenvererbungsbeziehungen können nicht gemischt werden. Zuerst werden die Instanzfelder in der übergeordneten Klasse gemäß Regel 2 verarbeitet, gefolgt von den Instanzfeldern der Unterklasse.
Regel 4: Wenn der Abstand zwischen dem letzten Mitglied der Elternklasse und dem ersten Mitglied der Unterklasse weniger als 4 Bytes beträgt, muss er auf die Grundeinheit von 4 Bytes erweitert werden.
Regel 5: Wenn das erste Instanzfeld der Unterklasse eine doppelte Genauigkeit oder eine lange Ganzzahl ist und die übergeordnete Klasse keine 8 Bytes verbraucht hat, bricht die JVM Regel 2 gemäß Ganzzahl (int), kurzer Ganzzahl ( kurz), Bytetyp (Byte), Referenztyp (Referenz) Reihenfolge, füllen Sie den nicht ausgefüllten Raum.

Das Obige sind die Regeln für das Speicherlayout von Java-Objekten.

Als nächstes sprechen wir über die Instanziierungsmethode von Java-Objekten, die die übliche -Methode ist.
Wenn wir ein neues Objekt erstellen, hat die JVM tatsächlich den gesamten Platz des Objekts zugewiesen und das Instanzdomänenlayout des gesamten Objekts bestimmt.
Die Instanziierungsmethode besteht darin, den Wert des Objektinstanzfelds auf den entsprechenden Raum zu setzen.

Die-Methode beginnt mit dem Aufruf der -Methode der übergeordneten Klasse und endet mit einer eigenen Konstruktormethode. Die Positionsbeziehung zwischen der Deklaration des Instanzfelds und dem Instanzinitialisierungsanweisungsblock wirkt sich auf die Bytecode-Reihenfolge der vom Compiler generierten

Lassen Sie uns dies anhand eines Beispiels veranschaulichen:
class Parent {
private short six;
private int age;
}

class Sub extension Parent{
private String name;
private int age;
private float price;
}

Das Speicherlayout des aktuellen Sub-Objekts ist wie folgt:
super stellt das sogenannte Parent dar Klassenspeicherplatz Was bedeutet das?
Ich denke, der Superspeicher hier ist der Grüne!

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Problems der Erstellung übergeordneter Klassenobjekte bei der Java-Vererbung. 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