Gibt Object.toString oder Object.hashCode jemals die Speicheradresse des Objekts

Question

Es wird oft behauptet, dass die Implementierung von Object.hashCode() (die Standardimplementierung für alle Objekte) die Speicheradresse des Objekts angibt. Dieser Anspruch wird oft einer Erklärung der besonderen Ausgabe von Object.to String() beigefügt.

Siehe here für ein Beispiel.

Dies ist sicherlich nicht der Fall für alle JVMs/JREs, denen ich bewusst bin. Nicht zuletzt, weil Adressen jetzt meist 64 Bit lang sind. Aber auch Müllsammler verlagern Objekte, so dass sich die Adresse ändert. Ich habe gesehen, Ansprüche können es die ersten Speicheradresse des Objekts sein. Aber da viele Objekte dann ähnliche Adressen hätten, wäre das eine schlechte Wahl für einen Hash-Code.

Gibt es jemals JVMs/JREs, für die es die (ursprüngliche) Speicheradresse des Objekts war, oder waren es jemals solche?

Ich bin mir bewusst, dass der JavaDoc für die Object Klasse schlägt vor, dass die hashCode für eine Implementierung möglicherweise die Speicheradresse sein. Aber ich vermute, dass dies eine völlig veraltete Aussage ist, die nie aktualisiert wurde.

Tatsächlich ist die aktuelle Oracle JVM verwendet nicht die Speicheradresse (aber kann so konfiguriert werden, dies zu tun):

https://stackoverflow.com/a/16105878/545127

Die Idee, dass der HashCode eine Speicheradresse ist, ist ein historischer Artefakt:

https://stackoverflow.com/a/13860488/545127

Meine Frage ist, ob (und welche) jeder weit verbreitet JVM Implemen verwendet, um die Speicheradresse als (Standard) tion.

Answer 1

Da der Standard-Hash-Code eines Objekts nicht eindeutig sein muss, ist die Rückgabe der gesamten Adresse nicht erforderlich. Eine Implementierung könnte eine Gruppe von Bits von der Adresse abgreifen - beispielsweise die Bits 3 bis 35 in einem 64-Bit-System oder ein XOR zwischen den oberen 32 Bits und den unteren 32 Bits oder einfach die unteren 32 Bits.

Aber so viele Objekte würden dann ähnliche Adressen [wegen Garbage Collection] haben, wäre das eine schlechte Wahl für einen Hash-Code.

Hash-Codes, die numerisch nahe beieinander liegen, sind in Ordnung. Selbst eine kleine Anzahl von identischen Hash-Codes würde kein Problem verursachen, da die Gleichheit verwendet wird, um alle Verbindungen zu lösen. Die Situationen, in denen die standardmäßige Hashcode-Implementierung verwendet wird, sind in der Regel begrenzt, da Objekte, die in Hash-basierten Containern als Schlüssel verwendet werden, erwartungsgemäß "gute" Implementierungen der Methode hashCode bereitstellen.

Oracle sagt, dass die Standardimplementierung ihrer JVM die interne Adresse des Objekts verwendet, was auch immer das bedeutet, um seine hashCode zu berechnen.Allerdings sind andere JVM-Implementierungen nicht zu tun, um das gleiche erforderlich:

Hier ist ein quote from Oracle's documentation:

So viel wie vernünftigerweise praktikabel ist, die hashCode Verfahren nach Klasse definiert Object zurückgibt verschiedene ganze Zahlen für verschiedene Objekte. (Dies wird in der Regel durch die Umwandlung der internen Adresse des Objekts in eine ganze Zahl implementiert, aber diese Implementierung Technik ist nicht von der Programmiersprache Java ™ erforderlich.)

Sie können die tatsächliche Implementierung des Algorithmus here finden. Suchen Sie nach get_next_hash Funktion für Details. Es scheint, dass Computing Hash basierend auf Adresse ist mit einer einfachen Konvertierung durchgeführt:

value = intptr_t(obj) ;