Object.toString或Object.hashCode是否给出了对象的内存地址 [英] Does Object.toString or Object.hashCode ever give the memory address of the object

问题描述

通常声称 Object.hashCode（）（所有对象的默认实现）的实现给出了对象的内存地址。该声明通常附在Object.to String（）产生的特殊输出的解释上。

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().

参见这里的例子。

对于任何JVM / JRE，情况肯定是不我知道。尤其是因为地址通常是64位长。而且，垃圾收集器重定位对象，因此地址会发生变化。我已经看到声称它可以是对象的初始内存地址。但是，由于许多对象具有相似的地址，因此对于哈希代码来说这将是一个糟糕的选择。

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.

是否存在或曾经存在任何广泛使用的JVM / JRE，它是对象的（初始）内存地址。

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

我知道 Object class建议实现的 hashCode 可能是内存地址。但我怀疑这是一个从未更新过的严重过时的声明。

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.

实际上，当前的Oracle JVM不使用内存地址（但可以配置为这样做）：

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

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

hashCode是一个内存地址的想法是一个历史假象：

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

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

我的问题是（和哪个）任何广泛使用的JVM使用内存地址作为其（默认）实现。

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

推荐答案

由于对象的默认哈希码不需要是唯一的，返回整个地址是没有必要的。一个实现可以从地址中获取一组位 - 比如64位系统上的位3到35，或者高32位和低32位之间的XOR，或者只是低32位。

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.

在数值上彼此接近的哈希码是可以的。即使少量相同的哈希码也不会产生问题，因为使用相等来解决任何关系。使用默认哈希码实现的情况通常是有限的，因为在基于哈希的容器中用作键的对象应该提供 hashCode 方法的良好实现。

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说他们的JVM的默认实现使用对象的内部地址，无论这意味着什么，计算它的 hashCode 。但是，其他JVM实现不需要这样做：

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:

这是来自Oracle文档的引用：

尽管合理实用，但是由类 Object 定义的 hashCode 方法会返回不同的整数不同的对象。 （这通常通过将对象的内部地址转换为整数来实现，但Java™编程语言不需要此实现技术。）

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.)

你可以找到算法的实际实现这里。搜索 get_next_hash 函数以获取详细信息。似乎基于地址的计算哈希是通过简单的转换完成的：

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) ;

这篇关于Object.toString或Object.hashCode是否给出了对象的内存地址的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！