为什么是对象的实现。equals（）不使用hashCode（）？

Question

或者“为什么Sun/Oracle的家伙每次都强迫我们重写equals（）和hashCode（）？”

每个人都知道，如果你覆盖一个对象的equals（）或hashCode（），你也必须覆盖另一个，因为这两者之间有一个约定：

请注意，每当重写hashCode方法[e.equals（）]时，通常有必要重写该方法，以维护hashCode方法的一般约定，即相等的对象必须具有相等的哈希代码。-对象的API文档。等于

为什么不在对象类中以这种方式实现：

public boolean equals(Object obj) {
    return this.hashCode() == obj.hashCode()
}

如果他们这样做了，世界其他地方就不必实施这两种方法了。只重写hashCode（）就足够了。

我想他们有充分的理由不这么做。我就是看不见，请帮我把这个弄清楚。

Answer 1

有无限多的对象具有相同的哈希代码。这意味着不能单独比较hashCde。

一个简单的例子是Long。hashCode（）：每个Long值是1L的倍数

Answer 2

约阿希姆是正确的，但还有另一个原因：效率。

计算哈希代码可能很昂贵，如果调用了equals（），但从来没有调用过hashCode（），则会产生不必要的工作。

在很多情况下都会出现这种情况；只有像Hashtable（或使用它的类）这样的类才能调用hashCode（）。

Answer 3

如果a.equals（b）返回true，那么a.hashCode（）==b.hashCode（）必须计算为true。

事实并非如此！如果有两个对象，其中a.hashCode（）==b.hashCode（）为true，但a.equals（b）为false，这是完全有效的。

事实上，这是必要的。有2³²可能的返回值为hashCode（）。在任何给定的时刻，JVM都可以容纳超过2个³²对象（如果有足够的内存，现在很有可能）。假设没有一个对象彼此相等（很容易做到，只要让它们是"s1"，"s2"，...），那么你肯定会有校验和的冲突（参见Pidgeonole原理）。

事实上，这是最简单的hashCode实现，对于每个类都是正确的（但在其他方面非常糟糕）^*：

public int hashCode() {
  return 0;
}

它神奇地满足了通用hashCode（）合同的所有要求。

^{*除了那些必须实现定义并记录了hashCode算法的类，主要示例是字符串。hashCode（）}