问题描述
由于对象的默认哈希值是对象的对象地址，因此在 32 位机器上，考虑哈希值是一个 int 值是有意义的.我的问题是在 64 位机器上，地址应该是 64 位对吗?那么 32 位 int 哈希值呢?是否会有一些向下转换(从 64 位到 32 位)?
Since default hash value of an object is the object address of the object, on 32-bit machine, it makes sense considering hash value is an int value. My question is that on 64 bit machine, address is supposed to be 64 bit right? Then what about the 32 bit int hash value? Is there going to be some down conversion(from 64bit to 32 bit)?
推荐答案
默认"值……或者更具体地说，没有指定对象的身份哈希码"是如何计算的.不在 32 位 JVM 或 64 位 JVM 上.
The "default" value ... or more specifically how an object's "identity hashcode" is calculated is NOT SPECIFIED. Not on a 32bit JVM, or a 64bit JVM.
观察到该值通常基于对象的地址，此时System.identityHashcode()方法是first调用，但这只是一个观察.当然没有指定为那个，这意味着不同的JVM可以自由地以不同的方式实现它.
It is observed that the value is typically based on the object's address at the point that the System.identityHashcode() method is first called, but that is only an observation. It is certainly not specified to be that, which means that different JVMs are free to implement it differently.
当然，它不能是 64 位 JVM 上的实际地址……因为 64 位地址不适合 32 位整数.很明显.
Certainly, it cannot be the actual address on a 64bit JVM ... since a 64 bit address won't fit into a 32 bit integer. Obviously.
然而它实际上是计算出来的，它仍然是一个事实，即身份哈希码从不是对象地址的可靠代理.如果具有身份哈希码的对象在垃圾回收周期中幸存下来，GC 将可能移动它，并且它的哈希码和地址从此不再相关.(可以保证的一件事是对象的身份哈希码不会更改.如果更改，哈希表就会损坏.)
However it is actually calculated, it remains the fact that the identity hashcode is NEVER a reliable proxy for the object's address. If an object with an identity hashcode survives a garbage collection cycle, the GC will probably have moved it, and its hashcode and address will henceforth be unrelated. (One thing that is guaranteed is that an object's identity hashcode does not change. If it did, hash tables would break.)
这篇关于64 位 JVM 上对象的默认哈希值是多少的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！