内存地址为HashTable中的哈希值.为什么HasTable不能使用密钥的实际内存地址作为哈希？

Question

可能这是一个基本问题或背后的基本思想.

为什么HasTable不能使用密钥的实际内存地址作为哈希？或者哈希密钥的地址并使用它？

我看到一些帖子说hashCode()密钥(对象)的默认值实际上是对象的内存地址,我认为这是不正确的.

我在一篇帖子中读到,说实际上存储桶地址是hash % number of existing buckets？这也不正确.

有人可以澄清吗？

Answer 1

如果一个类没有覆盖hashCode(),并且只是继承了默认实现java.lang.Object,那么在一个典型的JVM中,它hashCode()实际上或多或少是一个指向它的内部指针.(显然这不是整个故事,因为返回类型hashCode()是int,它不能容纳64位JVM;并且这些不是物理内存位置的真正指针,首先是因为操作系统处理从虚拟地址到物理的映射其次,因为即使JVM处理了这个问题,垃圾收集器也可以将一个对象从一个堆移动到另一个堆而不影响它hashCode().但是,"内部存储器地址"仍然是一个很好的第一近似值.)

大多数JDK类重写的原因hashCode()是我们总是希望hashCode()与"兼容" equals(); 也就是说,如果a.equals(b),那么我们想要a.hashCode() == b.hashCode().(当你考虑到你通常不想要时,这是有道理的 - 例如 - a 只有因为键是两个不同的实例Map<String, Object>才有两个不同的"abc"条目String.通常你希望能够通过输入来查找条目map.get("abc"),而不是需要使用键的原始实例.如果两个键相等,那么我们通常希望它们被视为相等.)

如果你真的想在你的地图指针平等,你可以使用的java.util.IdentityHashMap类.