可能这是一个基本问题或背后的基本思想。
HasTable为什么不能使用Key的实际内存地址作为Hash？或者散列 key 的地址并使用它？
我看到有些帖子说key(对象)的默认hashCode()其实是对象的Memory地址，我觉得是不正确的。
我在一篇帖子中读到，桶地址实际上是hash % number of existing buckets？这也不正确。
谁能澄清一下？
最佳答案
如果一个类没有覆盖hashCode() , 并且只是继承了 java.lang.Object 的默认实现，然后在典型的 JVM 中，它的 hashCode() ，实际上或多或少是指向它的内部指针。 (显然这不是全部，因为 hashCode() 的返回类型是 int ，它不适合 64 位 JVM；而且这些不是指向物理内存位置的真正指针，首先是因为操作系统处理从虚拟地址映射到物理地址，其次是因为，即使 JVM 处理了这个问题，垃圾收集器也可以将对象从一个堆移动到另一个堆而不影响其 hashCode() 。但是，“内部内存地址”仍然是一个很好的第一个近似值。)
大多数 JDK 类覆盖 hashCode() 的原因是我们总是想要hashCode()与equals()“兼容” ;也就是说，如果 a.equals(b) , 那么我们要 a.hashCode() == b.hashCode() . (当你考虑到你通常不希望 - 例如 - Map<String, Object> 有两个不同的 "abc" 条目时，这是有道理的，因为键是两个不同的 String 实例。通常你想要能够通过键入 map.get("abc") 来查找条目，而不需要手头有 key 的原始实例。如果两个 key 相等，那么我们通常希望将它们视为相等。)
如果你真的想要在你的 map 中指针相等，你可以使用the java.util.IdentityHashMap class .
关于java - 哈希表中的内存地址作为哈希。为什么HasTable不能使用Key的实际内存地址作为Hash？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13257553/