No, no, no. All answers in this thread are wrong or at least only partially correct.
First:
Object.hashCode()
is a native method, so its implementation depends solely on the JVM. It may vary between HotSpot and other VM implementations like JRockit or IBM J9.
If you are asking:
how is hashCode()
implemented in Java?
Then the answer is: it depends on which VM you are using.
Assuming that you are using Oracle's default JVM—which is HotSpot, then I can tell you that HotSpot has six hashCode()
implementations. You can choose it using the -XX:hashCode=n
flag running JVM via command line, where n
can be:
0 – Park-Miller RNG (default)
1 – f(address, global_statement)
2 – constant 1
3 – Serial counter
4 – Object address
5 – Thread-local Xorshift
The above is copied from this post.
And if you dig a little bit around in the HotSpot source code, you may find below snippet:
if (hashCode == 0) {
value = os::random();
} else {
...
os::random()
is just the implementation of the Park-Miller Pseudo Random Generator algorithm.
That's all. There isn't any notion of memory address. Although two other implementations, 1
and 4
, use an object's memory address, the default one doesn't use it.
The notion that Object.hashCode()
is based on the object's address is largely a historic artefact - it is no longer true.
I know that inside Object#hashCode()
JavaDoc we can read:
(...) this is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java? programming language.
But it is obsolete and misleading.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…