Does Object.toString or Object.hashCode ever give the memory address of the object

问题

It is often claimed that the implementation of Object.hashCode() (the default implementation for all objects) gives the memory address of the object. That claim is often attached to an explanation of the peculiar output produced by Object.to String().

See here for an example.

This is certainly not the case for any JVMs/JREs I am aware of. Not least because addresses are usually 64 bits long now. But also, garbage collectors relocate objects, so the address changes. I've seen claims it can be the initial memory address of the object. But as many objects would then have similar addresses, that would be a poor choice for a hash code.

Are there, or have there ever been, any widely used JVMs/JREs for which it was the (initial) memory address of the object.

I am aware that the JavaDoc for the Object class suggests that the hashCode for an implementation might be the memory address. But I suspect that is a grossly out of date statement that has never been updated.

Indeed, the current Oracle JVM does not use the memory address (but can be configured to do so):

https://stackoverflow.com/a/16105878/545127

The idea that the hashCode is a memory address is a historical artefact:

https://stackoverflow.com/a/13860488/545127

My question is whether (and which) any widely used JVM used the memory address as its (default) implementation.

回答1:

Since the default hash code of an object does not need to be unique, returning the whole address is not necessary. An implementation could grab a group of bits from the address - say, bits 3 through 35 on a 64-bit system, or a XOR between the upper 32 bits and the lower 32 bits, or simply the lower 32 bits.

But as many objects would then have similar addresses [due to garbage collection], that would be a poor choice for a hash code.

Hash codes that are numerically close to each other are OK. Even a small number of identical hash codes would not create a problem, because equality is used to resolve any ties. The situations when the default hash code implementation is used are generally limited, because objects that are used as keys in hash-based containers are expected to provide "good" implementations of hashCode method.

Oracle says that the default implementation of their JVM uses the internal address of the object, whatever that means, to compute its hashCode. However, other JVM implementations are not required to do the same:

Here is a quote from Oracle's documentation:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (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.)

You can find the actual implementation of the algorithm here. Search for get_next_hash function for details. It appears that computing hash based on address is done with a simple conversion:

value = intptr_t(obj) ;

来源：https://stackoverflow.com/questions/36236615/does-object-tostring-or-object-hashcode-ever-give-the-memory-address-of-the-obje