我知道合同说：“如果两个对象是相等的，那么，他们应该返回相同的散列码”。之所以如此，是这些对象可以在相同的散列桶的地方，以提高哈希码相关的收集功能知道。话又说回来，为什么它说：“如果两个对象具有相同的散列码那些不应该永远是平等的”。我的意思是，如果它是在合同真的，我们应该说“如果两个对象是平等的，他们可能会返回相同的哈希代码，但它不是强制性”
我的意思是，如果它是在合同真的，我们应该说“如果两个对象是平等的，他们可能会返回相同的哈希代码，但它不是强制性”
不，它不应该。这是因为，当一个对象被搜索，让我们在HashMap或HashSet说，那么首先它搜索hashCode的基础上（注： - hashCode()不用于ArrayList的情况下搜索，或者LinkedList他们不hash based集合），然后如果两个对象具有相同的散列码，它移动到equals方法来比较对象本身。
现在想，如果上述声明是真实的，第一个测试本身会失败的那些对象。也就是说，如果两个相等的对象可以有不同的哈希码，然后在搜索特定的hashCode，它不会返回正确的结果，因此，测试将不再继续equals method，并宣布这些对象是unequal即使你期望他们是平等的。
现在让我们进入第二语句： -
如果两个对象具有相同的散列码那些不应该永远是平等的”
让我们这样理解： - 由于每个对象生成hashCode的类型是int的，因此您可以产生的最大2 ^ 32独特hashcodes。所以，想象一下，如果你想存储比这更多的对象会发生什么。在这种情况下，必须有用于two different objects一个科里森。所以，你就没有其他的办法，而不是同hashCodes分配给两个不同的对象。因此上述说法是有道理的。
因此，两件事情是从上面的解释很清楚： -
在下面的链接这一主题的更多细节（没有任何东西可以给比这更好的解释）： -
不。该文档是正确的，你要混淆。
例如，以下是始终hashCode()的有效实施：
public int hashCode() {
return 0;
// clearly all equal objects have the same hash code -- 0
// but it's totally okay that unequal objects also have the same hash code
}
甲HashMap可以存储每个桶的多个条目，并且该桶被选择依赖于哈希码。该HashMap发现通过使用hashcode()识别桶中，然后equals()发现水桶内的匹配键的键条目。
鉴于上述情况，应该明确的是，你可以有一点问题重复哈希码（它影响包含HashMap的性能，如果多个对象具有相同的哈希码，但一切仍然有效）
如果2个相同的散列码必须来自同一个对象，比散列就不会安全。这在技术上是可以弄清楚什么是密码是基于哈希值。这将破坏的哈希码的目的（至少在安全感。）
对于非安全散列，如果你能有充分的独特的价值做一个独特的哈希值，比你已经解决了一个悬而未决的问题的计算。
哈希函数通常
单向函数
：某些输入值（对象）可以产生相同的散列码。
它基本上是说，如果两个对象具有相同的哈希码，他们应该是平等的。然而，由于没有（完美的）哈希函数，将永远不同的散列分配给不同的对象，这是情况并非总是如此。
不同的对象可以有相同的哈希码，由于散列冲突。
但有两个对象是平等应该有相同的哈希码。