Objektgrößenunterschied in 32-Bit- und 64-Bit-Systemen in Java

Ich bin auf eine Interviewfrage gestoßen:

Wie viel Speicherobjekt dieser Klasse braucht und warum bei Implementierung auf:

a) 32-Bit-Computer

b) 64-Bit-Computer

Ich habe die Antwort als:

Wegen zusätzlichem Speicher reserviert, der 8 Byte in 32-Bit-System und 16 Byte in 64-Bit-System zusätzlich zu der normalen Größe des Objekts ist.

Können Sie bitte eine Erklärung für diese Aussage geben?

PS .: Ich möchte auch eine Antwort teilen, die ich von einer anderen Quelle bekommen habe (kann sich nicht darauf verlassen, wollte bestätigen):

In 32 Bit PC-Objekt belegt 8 Bytes mehr als die tatsächliche Obj Größe wie von seinen Datenelementen definiert ..... und in 64 Bit PC-Objekt belegt 16 Bytes mehr als die tatsächliche Objektgröße wie von seinen Daten Mitgliedern definiert. .. nun kommt die Frage auf, warum es passiert ... der Grund dafür ist, soweit ich weiß, ::: in 32 bit pc die ersten 8 Bytes sind reserviert von JVM für die Bezugnahme auf Klassendefinitionen, Ausrichtung, Leerzeichen für Superklasse und Sub classes etc .. und für 64 bit reserviert es 16 Bytes für diese .. Es gibt eine Formel für die Berechnung, wie viel Heap-Speicherplatz von einem Objekt benötigt wird, wenn es erstellt wird und es als ..... berechnet wird. . Shallow Heap Size = [Verweis auf die Klassendefinition] + Leerzeichen für Superklassenfelder + Leerzeichen für Instanzfelder + [Ausrichtung]

Wie berechnen Sie, wie viel Speicher das Objekt "selbst" benötigt? Anscheinend gibt es eine Formel dafür:

Shallow Heap Size = [Verweis auf die Klassendefinition] + Leerzeichen für Superklassenfelder + Leerzeichen für Instanzfelder + [Ausrichtung]

Scheint nicht so hilfreich, oder? Lassen Sie uns versuchen, die Formel mit dem folgenden Beispielcode anzuwenden:

Nun, die Frage, die wir beantworten wollen, lautet: Wie viel flache Heap-Größe benötigt eine Instanz eines Y? Beginnen wir mit der Berechnung, vorausgesetzt wir befinden uns in einer 32-Bit-x86-Architektur:

Als Ausgangspunkt - Y ist eine Unterklasse von X, also enthält seine Größe "etwas" von der Superklasse. Bevor wir also die Größe von Y berechnen, untersuchen wir die flache Größe von X.

Wenn Sie in die Berechnungen von X springen, werden die ersten 8 Bytes verwendet, um auf seine Klassendefinition zu verweisen. Diese Referenz ist immer in allen Java-Objekten vorhanden und wird von JVM verwendet, um das Speicherlayout des folgenden Zustands zu definieren. Es hat auch drei Instanzvariablen - ein int, ein Integer und ein Byte. Diese Instanzvariablen erfordern einen Heap wie folgt:

ein Byte ist, was es sein soll. 1 Byte in einem Speicher. Ein int in unserer 32-Bit-Architektur benötigt 4 Bytes. ein Verweis auf den Integer benötigt ebenfalls 4 Bytes. Beachten Sie, dass wir bei der Berechnung von beibehaltenem Heap auch die Größe eines in das Integer-Objekt eingepackten Primitivs berücksichtigen sollten. Da wir hier jedoch einen flachen Heap berechnen, verwenden wir in unseren Berechnungen nur die Referenzgröße von 4 Byte. Also - ist es das? Shallow Heap von X = 8 Bytes aus dem Verweis auf die Klassendefinition + 1 Byte (das Byte) + 4 Bytes (der Int) + 4 Bytes (Verweis auf die Ganzzahl) = 17 Bytes? In der Tat - nein. Was jetzt ins Spiel kommt, nennt man Ausrichtung (auch Padding genannt). Es bedeutet, dass die JVM den Speicher in Vielfachen von 8 Bytes zuweist, also würden wir statt 17 Bytes 24 Bytes zuweisen, wenn wir eine Instanz von X erstellen würden.

Wenn du uns bis hierhin folgen könntest, gut, aber jetzt versuchen wir, die Dinge noch komplexer zu machen. Wir erstellen KEINE Instanz von X, sondern eine Instanz von Y. Was das bedeutet ist, dass wir die 8 Bytes von der Referenz auf die Klassendefinition und die Ausrichtung abziehen können. Es ist vielleicht nicht zu offensichtlich, aber - haben Sie bemerkt, dass wir bei der Berechnung der flachen Größe von X nicht berücksichtigt haben, dass es auch java.lang.Object erweitert, wie alle Klassen es tun, auch wenn Sie es nicht explizit angeben Dein Quellcode? Wir müssen die Header-Größen von Superklassen nicht berücksichtigen, weil JVM schlau genug ist, es anhand der Klassendefinitionen selbst zu überprüfen, anstatt es ständig in die Objektheader zu kopieren.

Gleiches gilt für die Ausrichtung - wenn Sie ein Objekt erstellen, richten Sie es nur einmal aus, nicht an den Grenzen der Oberklassen- / Unterklassendefinitionen. Wir können also sicher sagen, dass Sie beim Erstellen einer Unterklasse für X nur 9 Bytes von den Instanzvariablen erben.

Schließlich können wir zu der anfänglichen Aufgabe springen und anfangen, die Größe von Y zu berechnen. Wie wir gesehen haben, haben wir bereits 9 Bytes an die Superklassenfelder verloren. Mal sehen, was hinzugefügt wird, wenn wir tatsächlich eine Instanz von Y konstruieren.

Y-Header, die auf seine Klassendefinition verweisen, verbrauchen 8 Bytes. Das Gleiche wie bei früheren. Das Datum ist eine Referenz auf ein Objekt. 4 Bytes. Einfach. Die Liste ist eine Referenz auf eine Sammlung. Wieder 4 Bytes. Trivial. Zusätzlich zu den 9 Bytes der Superklasse haben wir 8 Bytes aus dem Header, 2 × 4 Bytes aus den beiden Referenzen (die Liste und das Datum). Die gesamte flache Größe für die Instanz von Y wäre 25 Bytes, die auf 32 ausgerichtet werden.