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中和内存地址是无关的,与所在线程(或者说生成的一个随机数)以及生成顺序有关

  • 18
    点赞
  • 50
    收藏
    觉得还不错? 一键收藏
  • 10
    评论
评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值