Java Object.hashCode()返回的是物件記憶體地址?
基於OpenJDK 8
一直以為Java Object.hashCode()的結果就是通過物件的記憶體地址做相關運算得到的,但是無意在網上看到有相應的意見爭論,故抽時間從原始碼層面驗證了剖析了hashCode的預設計算方法。
先說結論:OpenJDK8 預設hashCode的計算方法是通過和當前執行緒有關的一個隨機數+三個確定值,運用Marsaglia's xorshift scheme隨機數演算法得到的一個隨機數。和物件記憶體地址無關。
下面通過查詢和分析OpenJDK8原始碼實現來一步步分析。
1. 查詢java.lang.Object.hashCode()原始碼
public native int hashCode();
2. 匯出Object的JNI標頭檔案
切換到Object.class檔案所在目錄,執行 javah -jni java.lang.Object,得到java_lang_Object.h檔案,檔案內容如下:
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class java_lang_Object */
#ifndef _Included_java_lang_Object
#define _Included_java_lang_Object
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: java_lang_Object
* Method: registerNatives
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_java_lang_Object_registerNatives
(JNIEnv *, jclass);
/*
* Class: java_lang_Object
* Method: getClass
* Signature: ()Ljava/lang/Class;
*/
JNIEXPORT jclass JNICALL Java_java_lang_Object_getClass
(JNIEnv *, jobject);
/*
* Class: java_lang_Object
* Method: hashCode
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_java_lang_Object_hashCode
(JNIEnv *, jobject);
/*
* Class: java_lang_Object
* Method: clone
* Signature: ()Ljava/lang/Object;
*/
JNIEXPORT jobject JNICALL Java_java_lang_Object_clone
(JNIEnv *, jobject);
/*
* Class: java_lang_Object
* Method: notify
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_java_lang_Object_notify
(JNIEnv *, jobject);
/*
* Class: java_lang_Object
* Method: notifyAll
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_java_lang_Object_notifyAll
(JNIEnv *, jobject);
/*
* Class: java_lang_Object
* Method: wait
* Signature: (J)V
*/
JNIEXPORT void JNICALL Java_java_lang_Object_wait
(JNIEnv *, jobject, jlong);
#ifdef __cplusplus
}
#endif
#endif
3 . 檢視Object的native方法實現
OpenJDK原始碼連結:http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/3462d04401ba/src/share/native/java/lang/Object.c ,檢視Object.c檔案,可以看到hashCode()的方法被註冊成由JVM_IHashCode方法指標來處理。
static JNINativeMethod methods[] = {
{"hashCode", "()I", (void *)&JVM_IHashCode},//hashcode的方法指標JVM_IHashCode
{"wait", "(J)V", (void *)&JVM_MonitorWait},
{"notify", "()V", (void *)&JVM_MonitorNotify},
{"notifyAll", "()V", (void *)&JVM_MonitorNotifyAll},
{"clone", "()Ljava/lang/Object;", (void *)&JVM_Clone},
};
而JVM_IHashCode方法指標在 openjdk\hotspot\src\share\vm\prims\jvm.cpp中定義為:
JVM_ENTRY(jint, JVM_IHashCode(JNIEnv* env, jobject handle))
JVMWrapper("JVM_IHashCode");
// as implemented in the classic virtual machine; return 0 if object is NULL
return handle == NULL ? 0 : ObjectSynchronizer::FastHashCode (THREAD, JNIHandles::resolve_non_null(handle)) ;
JVM_END
從而得知,真正計算獲得hashCode的值是ObjectSynchronizer::FastHashCode
4 . ObjectSynchronizer::fashHashCode方法的實現
openjdk\hotspot\src\share\vm\runtime\synchronizer.cpp 找到其實現方法。
intptr_t ObjectSynchronizer::FastHashCode (Thread * Self, oop obj) {
if (UseBiasedLocking) {
// NOTE: many places throughout the JVM do not expect a safepoint
// to be taken here, in particular most operations on perm gen
// objects. However, we only ever bias Java instances and all of
// the call sites of identity_hash that might revoke biases have
// been checked to make sure they can handle a safepoint. The
// added check of the bias pattern is to avoid useless calls to
// thread-local storage.
if (obj->mark()->has_bias_pattern()) {
// Box and unbox the raw reference just in case we cause a STW safepoint.
Handle hobj (Self, obj) ;
// Relaxing assertion for bug 6320749.
assert (Universe::verify_in_progress() ||
!SafepointSynchronize::is_at_safepoint(),
"biases should not be seen by VM thread here");
BiasedLocking::revoke_and_rebias(hobj, false, JavaThread::current());
obj = hobj() ;
assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
}
}
// hashCode() is a heap mutator ...
// Relaxing assertion for bug 6320749.
assert (Universe::verify_in_progress() ||
!SafepointSynchronize::is_at_safepoint(), "invariant") ;
assert (Universe::verify_in_progress() ||
Self->is_Java_thread() , "invariant") ;
assert (Universe::verify_in_progress() ||
((JavaThread *)Self)->thread_state() != _thread_blocked, "invariant") ;
ObjectMonitor* monitor = NULL;
markOop temp, test;
intptr_t hash;
markOop mark = ReadStableMark (obj);
// object should remain ineligible for biased locking
assert (!mark->has_bias_pattern(), "invariant") ;
if (mark->is_neutral()) {
hash = mark->hash(); // this is a normal header
if (hash) { // if it has hash, just return it
return hash;
}
hash = get_next_hash(Self, obj); // allocate a new hash code
temp = mark->copy_set_hash(hash); // merge the hash code into header
// use (machine word version) atomic operation to install the hash
test = (markOop) Atomic::cmpxchg_ptr(temp, obj->mark_addr(), mark);
if (test == mark) {
return hash;
}
// If atomic operation failed, we must inflate the header
// into heavy weight monitor. We could add more code here
// for fast path, but it does not worth the complexity.
} else if (mark->has_monitor()) {
monitor = mark->monitor();
temp = monitor->header();
assert (temp->is_neutral(), "invariant") ;
hash = temp->hash();
if (hash) {
return hash;
}
// Skip to the following code to reduce code size
} else if (Self->is_lock_owned((address)mark->locker())) {
temp = mark->displaced_mark_helper(); // this is a lightweight monitor owned
assert (temp->is_neutral(), "invariant") ;
hash = temp->hash(); // by current thread, check if the displaced
if (hash) { // header contains hash code
return hash;
}
// WARNING:
// The displaced header is strictly immutable.
// It can NOT be changed in ANY cases. So we have
// to inflate the header into heavyweight monitor
// even the current thread owns the lock. The reason
// is the BasicLock (stack slot) will be asynchronously
// read by other threads during the inflate() function.
// Any change to stack may not propagate to other threads
// correctly.
}
// Inflate the monitor to set hash code
monitor = ObjectSynchronizer::inflate(Self, obj);
// Load displaced header and check it has hash code
mark = monitor->header();
assert (mark->is_neutral(), "invariant") ;
hash = mark->hash();
if (hash == 0) {
hash = get_next_hash(Self, obj);
temp = mark->copy_set_hash(hash); // merge hash code into header
assert (temp->is_neutral(), "invariant") ;
test = (markOop) Atomic::cmpxchg_ptr(temp, monitor, mark);
if (test != mark) {
// The only update to the header in the monitor (outside GC)
// is install the hash code. If someone add new usage of
// displaced header, please update this code
hash = test->hash();
assert (test->is_neutral(), "invariant") ;
assert (hash != 0, "Trivial unexpected object/monitor header usage.");
}
}
// We finally get the hash
return hash;
}
該方法中
// Load displaced header and check it has hash code
mark = monitor->header();
assert (mark->is_neutral(), "invariant") ;
hash = mark->hash();
if (hash == 0) {
hash = get_next_hash(Self, obj);
...
}
對hash值真正進行了計算,檢視get_next_hash方法原始碼http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/share/vm/runtime/synchronizer.cpp#l555
static inline intptr_t get_next_hash(Thread * Self, oop obj) {
intptr_t value = 0 ;
if (hashCode == 0) {
// This form uses an unguarded global Park-Miller RNG,
// so it's possible for two threads to race and generate the same RNG.
// On MP system we'll have lots of RW access to a global, so the
// mechanism induces lots of coherency traffic.
value = os::random() ;
} else
if (hashCode == 1) {
// This variation has the property of being stable (idempotent)
// between STW operations. This can be useful in some of the 1-0
// synchronization schemes.
intptr_t addrBits = cast_from_oop<intptr_t>(obj) >> 3 ;
value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
} else
if (hashCode == 2) {
value = 1 ; // for sensitivity testing
} else
if (hashCode == 3) {
value = ++GVars.hcSequence ;
} else
if (hashCode == 4) {
value = cast_from_oop<intptr_t>(obj) ;
} else {
// Marsaglia's xor-shift scheme with thread-specific state
// This is probably the best overall implementation -- we'll
// likely make this the default in future releases.
unsigned t = Self->_hashStateX ;
t ^= (t << 11) ;
Self->_hashStateX = Self->_hashStateY ;
Self->_hashStateY = Self->_hashStateZ ;
Self->_hashStateZ = Self->_hashStateW ;
unsigned v = Self->_hashStateW ;
v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
Self->_hashStateW = v ;
value = v ;
}
value &= markOopDesc::hash_mask;
if (value == 0) value = 0xBAD ;
assert (value != markOopDesc::no_hash, "invariant") ;
TEVENT (hashCode: GENERATE) ;
return value;
}
對於OpenJDK8版本,其預設配置http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/share/vm/runtime/globals.hpp#l1127 為:
product(intx, hashCode, 5, \
"(Unstable) select hashCode generation algorithm") \
其對應的hashCode計算方案為:
// Marsaglia's xor-shift scheme with thread-specific state
// This is probably the best overall implementation -- we'll
// likely make this the default in future releases.
unsigned t = Self->_hashStateX ;
t ^= (t << 11) ;
Self->_hashStateX = Self->_hashStateY ;
Self->_hashStateY = Self->_hashStateZ ;
Self->_hashStateZ = Self->_hashStateW ;
unsigned v = Self->_hashStateW ;
v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)) ;
Self->_hashStateW = v ;
value = v ;
其中Thread->_hashStateX, Thread->_hashStateY, Thread->_hashStateZ, Thread->_hashStateW在http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/share/vm/runtime/thread.cpp#I263 有定義:
// thread-specific hashCode stream generator state - Marsaglia shift-xor form
_hashStateX = os::random() ;
_hashStateY = 842502087 ;
_hashStateZ = 0x8767 ; // (int)(3579807591LL & 0xffff) ;
_hashStateW = 273326509 ;
所以,JDK8 的預設hashCode的計算方法是通過和當前執行緒有關的一個隨機數+三個確定值,運用Marsaglia's xorshift scheme隨機數演算法得到的一個隨機數。對xorshift演算法有興趣可以參考原論文:https://www.jstatsoft.org/article/view/v008i14/xorshift.pdf 。
xorshift是由George Marsaglia發現的一類偽隨機數生成器,其通過移位和與或計算,能夠在計算機上以極快的速度生成偽隨機數序列。其演算法的基本實現如下:
unsigned long xor128(){
static unsigned long x=123456789,y=362436069,z=521288629,w=88675123;
unsigned long t;
t=(xˆ(x<<11));x=y;y=z;z=w; return( w=(wˆ(w>>19))ˆ(tˆ(t>>8)) );
這就和上面計算hashCode的OpenJDK程式碼對應了起來。
5 . 其他幾類hashCode計算方案:
- hashCode == 0
此類方案返回一個Park-Miller偽隨機數生成器生成的隨機數
OpenJdk 6 &7的預設實現。http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/5b9a416a5632/src/share/vm/runtime/globals.hpp#l1100
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/5cec449cc409/src/share/vm/runtime/globals.hpp#l1128
if (hashCode == 0) {
// This form uses an unguarded global Park-Miller RNG,
// so it's possible for two threads to race and generate the same RNG.
// On MP system we'll have lots of RW access to a global, so the
// mechanism induces lots of coherency traffic.
value = os::random() ;
}
- hashCode == 1
此類方案將物件的記憶體地址,做移位運算後與一個隨機數進行異或得到結果
if (hashCode == 1) {
// This variation has the property of being stable (idempotent)
// between STW operations. This can be useful in some of the 1-0
// synchronization schemes.
intptr_t addrBits = cast_from_oop<intptr_t>(obj) >> 3 ;
value = addrBits ^ (addrBits >> 5) ^ GVars.stwRandom ;
}
- hashCode == 2
此類方案返回固定的1
if (hashCode == 2) {
value = 1 ; // for sensitivity testing
}
- hashCode == 3
此類方案返回一個自增序列的當前值
if (hashCode == 3) {
value = ++GVars.hcSequence ;
}
- hashCode == 4
此類方案返回當前物件的記憶體地址
if (hashCode == 4) {
value = cast_from_oop<intptr_t>(obj) ;
}
可以通過在JVM啟動引數中新增-XX:hashCode=4,改變預設的hashCode計算方式。
參考資料:
https://srvaroa.github.io/jvm/java/openjdk/biased-locking/2017/01/30/hashCode.html
https://en.wikipedia.org/wiki/Xorshift
http://www.cnblogs.com/mengyou0304/p/4763220.html
http://stackoverflow.com/questions/2427631/how-is-hashcode-calculated-in-java
http://hllvm.group.iteye.com/group/topic/39183
相關文章
- Java物件記憶體模型Java物件記憶體模型
- Java 物件記憶體分析Java物件記憶體
- Java物件的記憶體佈局Java物件記憶體
- Java物件記憶體佈局Java物件記憶體
- JVM記憶體結構、Java記憶體模型和Java物件模型JVM記憶體Java模型物件
- 什麼是Java記憶體模型(JMM)中的主記憶體和本地記憶體?Java記憶體模型
- 淺談JVM記憶體結構 和 Java記憶體模型 和 Java物件模型JVM記憶體Java模型物件
- JAVA物件在JVM中記憶體分配Java物件JVM記憶體
- Java記憶體模型FAQ(一) 什麼是記憶體模型Java記憶體模型
- 什麼是Java記憶體模型?Java記憶體模型
- 什麼是Java記憶體模型Java記憶體模型
- 乞丐是如何節約Java記憶體的Java記憶體
- Java的記憶體 -JVM 記憶體管理Java記憶體JVM
- 一個Java物件到底佔多大記憶體?Java物件記憶體
- 物件記憶體圖物件記憶體
- Java中物件並不是都在堆上分配記憶體的。Java物件記憶體
- 物件的記憶體佈局物件記憶體
- Java常見知識點彙總(⑱)——Jvm記憶體結構、Java記憶體模型、Java物件模型的區別JavaJVM記憶體模型物件
- 一個Java物件到底佔用多大記憶體?Java物件記憶體
- 圖文詳解Java物件記憶體佈局Java物件記憶體
- Java物件記憶體分配原理及原始碼分析Java物件記憶體原始碼
- Java記憶體模型是什麼,為什麼要有Java記憶體模型,Java記憶體模型解決了什麼問題?Java記憶體模型
- hashCode竟然不是根據物件記憶體地址生成的?還對記憶體洩漏與偏向鎖有影響?物件記憶體
- JVM -- 物件的記憶體佈局JVM物件記憶體
- 物件的建立與記憶體分配物件記憶體
- .NET物件的記憶體佈局物件記憶體
- Java記憶體模型FAQ(九)在新的Java記憶體模型中,final欄位是如何工作的Java記憶體模型
- 認識各種記憶體地址記憶體
- 動態分配記憶體地址(.NET)記憶體
- Java的記憶體模型Java記憶體模型
- 記憶體管理篇——線性地址的管理記憶體
- 指標:存放記憶體地址的變數指標記憶體變數
- Java虛擬機器2:Java記憶體區域及物件Java虛擬機記憶體物件
- project中的堆疊記憶體,記憶體地址引用,gc相關問題Project記憶體GC
- java棧記憶體和堆記憶體的詮釋Java記憶體
- JVM中java例項物件在記憶體中的佈局JVMJava物件記憶體
- java本地連線遠端Hbase可是返回zookeeper的地址是localhostJavalocalhost
- Java記憶體區域和記憶體模型Java記憶體模型