什么是64位JVM上对象的默认哈希值

Question

由于对象的默认哈希值是对象的对象地址,因此在32位机器上,考虑到哈希值是一个int值,这是有道理的.我的问题是在64位机器上,地址应该是64位对吗？那么32位int哈希值怎么样？是否会有一些下转换(从64位到32位)？

Answer 1

如何计算标识hashCode是特定于JVM的.

对于HotSpot JVM,它使用随机数生成器来初始计算身份hashCode.在第一次计算hashCode之后,它将保存在对象头中,以便后续调用identityHashCode将返回相同的值.

实际上,生成身份hashCode的算法可以通过-XX:hashCodeJVM选项进行更改.看看消息来源.有以下选项:

• -XX:hashCode=0- 全球Park-Miller RNG (默认为Java 7)
• -XX:hashCode=1 - function(obj_address,global_state)
• -XX:hashCode=2 - 常量1.所有对象都具有相同的hashCode.只是为了测试.
• -XX:hashCode=3 - 增量计数器.
• -XX:hashCode=4 - Heap中对象地址的低32位
• -XX:hashCode=5- 线程局部Marsaglia的Xor-shift RNG (自Java 8起默认)

Answer 2

我的问题是64位JVM上对象的默认哈希值是多少？它仍然是对象地址值吗？

"默认"值...或者更具体地说,如何计算对象的"身份哈希码"是未指定的.不在32位JVM或64位JVM上.

据观察,该值通常基于首次调用该System.identityHashcode()方法时对象的地址,但这只是一个观察.当然没有指定它,这意味着不同的JVM可以自由地以不同方式实现它.

当然,它不能是64位JVM上的实际地址...因为64位地址不适合32位整数.明显.

然而,它实际上是计算的,它仍然是身份哈希码永远不是对象地址的可靠代理的事实.如果具有标识哈希码的对象在垃圾收集周期中存活,则GC 可能已经移动它,并且其哈希码和地址将在此后不相关.(保证的一件事是对象的标识哈希码不会改变.如果确实如此,哈希表就会中断.)