2013-02-05 13 views
9

Soweit ich weiß, ein Hash-Code des Objekts normalerweise im Header-Wort des Objekts gespeichert wird, die zum Beispiel das folgende Layout in HotSpot haben:Wo wird der Hash-Code des Objekts gespeichert, wenn in HotSpot JVM das Bias-Locking aktiviert ist?

| hash code | age | 0 | 01 |

Nach dem HotSpotInternals - Synchronization mit voreingenommen Sperren aktiviert das Header-Wort Layout sieht in der folgenden Art und Weise:

| 0 |epoch| age | 0 | 01 |

Wo kommt der Hash-Code wird dann, wenn tatsächlich gespeichert benötigt, wenn voreingenommen Verriegelung aktiviert ist?

Antwort

8

Mein Verständnis ist, dass die Anfrage nach dem (Identität) Hashcode verzerrte Sperrung verhindert - wie wir nicht sowohl den Hashcode und Thread-ID im Mark-Wort speichern können. Wenn Sie nach dem Hashcode des Mutex fragen, werden Sie in den unvoreingenommenen Sperrmodus versetzt.

Dies wird durch die Unterstützung von this blog im Anschluss:

„Schließlich gibt es gegenwärtig nicht Platz in dem Markierungswort

sowohl eine Identitäts hashCode() Wert sowie die Thread-ID für die vorgespannten Verriegelungs Codierung benötigt zu unterstützen Daher können Sie eine verzerrte Sperrung auf Objektbasis vermeiden, indem Sie System.identityHashCode(o) aufrufen.Wenn das Objekt bereits voreingenommen ist, führt das Zuweisen einer Identität hashCode zu einem Widerruf, andernfalls wird die Zuweisung einer hashCode() das Objekt für eine nachfolgende Verzerrung untauglich machen Diese Eigenschaft ist natürlich ein Artefakt unserer aktuellen Implementierung. "

+0

Dies scheint der Fall zumindest in OpenJDK auf den Quellcode der Suche zu sein: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/share/vm/runtime /synchronizer.cpp#l601 –