HashCode详解
HashCode详解
起初的时候我一直认为hashcode是内存地址的一个映射，但是今天仔细研究了一下hashcode，以往的认识就这样无情的被颠覆了。
起初我把对象的内存地址和hashcode一起输出，由于java是不建议用户之间操作内存的，所以一般情况下是不能够拿到对象的内存地址，但是Java留了一个后门:Unsafe，通过Unsafe类我们可以访问到对象的内存地址
public class Test {
private static Unsafe unsafe;
static {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
unsafe = (Unsafe) field.get(null);
} catch (Exception e) {
e.printStackTrace();
}
}
public static long addressOf(Object o) throws Exception {
Object[] array = new Object[]{o};
long baseOffset = unsafe.arrayBaseOffset(Object[].class);
int addressSize = unsafe.addressSize();
long objectAddress;
switch (addressSize) {
case 4:
objectAddress = unsafe.getInt(array, baseOffset);
break;
case 8:
objectAddress = unsafe.getLong(array, baseOffset);
break;
default:
throw new Error("unsupported address size: " + addressSize);
}
return (objectAddress);
}
public static void main(String[] args) throws Exception {
Test test=new Test();
System.out.println(addressOf(test));
System.out.println(System.identityHashCode(test));
Test test2=new Test();
System.out.println(addressOf(test2));
System.out.println(System.identityHashCode(test2));
Test test3=new Test();
System.out.println(addressOf(test3));
System.out.println(System.identityHashCode(test3));
}
}
我反复运行上面这段代码，结果如下
| 第一次 | 第二次 | 第三次 |
|---|---|---|
| 4028048182 1956725890 4028048279 356573597 4028048324 1735600054 |
4028048091 1956725890 4028048188 356573597 4028048233 1735600054 |
4028048190 1956725890 4028048287 356573597 4028048332 1735600054 |
我们可以看到，内存地址不一样，但是hashcode是一样的，更有意思的是hashcode好像和new对象的顺序有关。
为了验证是否hashcode是否和对象生成的顺序有关，我用一个死循环去循环生成对象，然后看出现hash冲突的位置。
public class SameClassRepetTest {
public static void main(String[] args) {
HashSet<Integer> set=new HashSet<Integer>();
int count=0;
int repetCount=0;
while (true){
count++;
int code=new SameClassRepetTest().hashCode();
if (set.contains(code)){
System.out.println("code:"+code);
System.out.println("count:"+count);
repetCount++;
System.out.println(repetCount);
if (repetCount==10){
break;
}
}
else
set.add(code);
}
}
当出现10次重复hashcode的时候程序终止，结果如下
code:2134400190
count:105825
1
code:651156501
count:111272
2
code:1867750575
count:121933
3
code:2038112324
count:145456
4
code:1164664992
count:146389
5
code:273791087
count:152369
6
code:996371445
count:180981
7
code:254720071
count:184294
8
code:1872358815
count:186922
9
code:332866311
count:206932
10
每一次运行的结果都是相同的，这就很有意思了，基本上初步就可以判断hashcode与对象生成的顺序有关
然后我生成不同的类对象去重复上述操作
public class DeffClassRepetTest {
public static void main(String[] args) {
HashSet<Integer> set = new HashSet<Integer>();
int count = 0;
int repetCount = 0;
while (true) {
count++;
int code = count%2==0?new SameClassRepetTest().hashCode():new DeffClassRepetTest().hashCode();
if (set.contains(code)) {
System.out.println("code:" + code);
System.out.println("count:" + count);
repetCount++;
System.out.println(repetCount);
if (repetCount == 10) {
break;
}
} else
set.add(code);
}
}
}
运行结果与同一个类生成对象的结果完全一致，可以断定hashcode与对象类型无关，对象的生成顺序有关。当我以为认识到真相的时候，手贱敲了段代码，结果认识又被颠覆了。
我用多个线程去执行上述操作：
public class ConcurrentTest {
public static void main(String[] args) {
AtomicInteger count =new AtomicInteger(0);
AtomicInteger repetCount=new AtomicInteger(0);
ConcurrentSkipListSet<Integer> set=new ConcurrentSkipListSet<Integer>();
new Thread(()->{
while (true) {
count.incrementAndGet();
int code = count.get()%2==0?new SameClassRepetTest().hashCode():new DeffClassRepetTest().hashCode();
if (set.contains(code)) {
System.out.println("Tread1:code:" + code);
System.out.println("Tread1:count:" + count.get());
repetCount.incrementAndGet();
System.out.println(repetCount.get());
if (repetCount.get() >= 10) {
break;
}
} else
set.add(code);
}
}).start();
new Thread(()->{
while (true) {
count.incrementAndGet();
int code = count.get()%2==0?new SameClassRepetTest().hashCode():new DeffClassRepetTest().hashCode();
if (set.contains(code)) {
System.out.println("Tread2:code:" + code);
System.out.println("Tread2:count:" + count.get());
repetCount.incrementAndGet();
System.out.println(repetCount.get());
if (repetCount.get() >= 10) {
break;
}
} else
set.add(code);
}
}).start();
}
重复运行这段代码
| 第一次 | 第二次 |
|---|---|
| Tread2:code:308698969 Tread2:count:133848 1 Tread2:code:39252308 Tread2:count:141446 2 Tread2:code:462746542 Tread2:count:144624 3 Tread1:code:699788746 Tread1:count:158743 4 Tread1:code:1745215832 Tread1:count:172682 5 Tread1:code:571947411 Tread1:count:174724 6 Tread1:code:1609797262 Tread1:count:175730 7 Tread1:code:1406244557 Tread1:count:175922 8 Tread1:code:361509194 Tread1:count:215637 9 Tread1:code:476907224 Tread1:count:217548 10 Tread2:code:1600420189 Tread2:count:222308 11 |
Tread1:code:147103475 Tread1:count:45814 1 Tread2:code:30086540 Tread2:count:61907 2 Tread2:code:222755065 Tread2:count:73802 3 Tread1:code:1370187659 Tread1:count:105263 4 Tread2:code:327698381 Tread2:count:143654 5 Tread2:code:1745215832 Tread2:count:175517 6 Tread2:code:1609797262 Tread2:count:178438 7 Tread2:code:1406244557 Tread2:count:178628 8 Tread2:code:476907224 Tread2:count:219082 9 Tread1:code:1012470049 Tread1:count:226958 10 Tread2:code:345268840 Tread2:count:245758 11 |
看起来没有任何的规律，这时我就觉得有点茫然了，没办法，于是我开始去扒源码
Object源码地址
在Object中我们可以看到hashCode实际上是调用了IHashCode
static JNINativeMethod methods[] = {
{"hashCode", "()I", (void *)&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.cpp找到了IHashCode实际调用的是FastHashCode
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
接着扒FastHashCode,FastHashCode在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") ;
//mark是对象头
if (mark->is_neutral()) {
hash = mark->hash(); // 取出hash值（实际上可以理解为缓存，有就直接返回，没有就生成一个新的）
if (hash) { // if it has hash, just return it
return hash;
}
hash = get_next_hash(Self, obj); // 这是生成hashcode的核心方法
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;
}
get_next_hash
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
//返回1
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;
}
到了这里我们基本上就知道了hashcode是怎么生成的了，实际上在jdk1.8在是用的第五种生成方式，我们可以在Linux系统下输入：java -XX:+PrintFlagsFinal -version|grep hashCode命令查看
ok,接下来我们来分析一下第5种方式，看到这个代码我的第一反应是懵逼的，那个什么_hashStateX是个什么鬼？
我们来看一下thead.cpp里面是怎样定义的：
// thread-specific hashCode stream generator state - Marsaglia shift-xor form
_hashStateX = os::random() ;
_hashStateY = 842502087 ;
_hashStateZ = 0x8767 ; // (int)(3579807591LL & 0xffff) ;
_hashStateW = 273326509 ;
在thread里面定义了一个随机数，三个常数，通过这四个数根据上述的算法来生成hashcode。
具体原理请参考论文：Xorshift RNGs
因为在上述算法在，需要得到线程里面的一个随机数作为一个初始值，上述算法在前后具有因果关系，后面的结果是根据前面的结果推算而来的，因此对于相同的线程来说，在某种意义上，对象的hashcode的生成是和顺序有关的。
为什么主函数里面的hashcode的生成一直是有序的呢？我猜测是主线程里面的——hashStateX是一个固定值（未证实）
可见hashcode在1.8中和内存地址是无关的，与所在线程（或者说生成的一个随机数）以及生成顺序有关