为了在HashMap, Hashtable等集合中使用我们自己的类对象作为键。，我们应该通过了解集合的内部工作来重写这两个方法(hashCode()和equals())。否则，它会导致我们意想不到的错误结果。

我正在研究解释“如果你只覆盖hashCode，那么当你调用myMap.put(first,someValue)时，它首先接受，计算它的hashCode并将其存储在给定的桶中。然后，当你调用myMap.put(first,someOtherValue)时，它应该根据Map文档将first替换为second，因为它们是相等的(根据我们的定义)。”：

我认为第二次添加myMap时应该是第二个对象比如myMap。put(second,someOtherValue)

Bah -“你必须在每个重写equals()的类中重写hashCode()。”

[出自Joshua Bloch的《Effective Java》?］

Isn't this the wrong way round? Overriding hashCode likely implies you're writing a hash-key class, but overriding equals certainly does not. There are many classes that are not used as hash-keys, but do want a logical-equality-testing method for some other reason. If you choose "equals" for it, you may then be mandated to write a hashCode implementation by overzealous application of this rule. All that achieves is adding untested code in the codebase, an evil waiting to trip someone up in the future. Also writing code you don't need is anti-agile. It's just wrong (and an ide generated one will probably be incompatible with your hand-crafted equals).

他们肯定应该在被写来用作键的对象上强制设置一个接口吗?无论如何，Object永远不应该提供默认的hashCode()和equals() imho。它可能鼓励了许多破碎的散列集合。

但无论如何，我认为“规则”是前后颠倒的。与此同时，我将继续避免使用“等号”进行相等性测试方法:-(

Java提出了一个规则

如果使用Object类的equals方法，两个对象相等，那么hashcode方法应该为这两个对象提供相同的值。

因此，如果在我们的类中重写equals()，我们也应该重写hashcode()方法来遵循此规则。 例如，equals()和hashcode()这两个方法都用于Hashtable中以键值对的形式存储值。如果我们覆盖其中一个而不是另一个，如果我们使用这样的对象作为键，哈希表可能不会像我们想要的那样工作。

为了在HashMap, Hashtable等集合中使用我们自己的类对象作为键。，我们应该通过了解集合的内部工作来重写这两个方法(hashCode()和equals())。否则，它会导致我们意想不到的错误结果。

class A {
    int i;
    // Hashing Algorithm
    if even number return 0 else return 1
    // Equals Algorithm,
    if i = this.i return true else false
}

put('key'，'value')将使用hashCode()计算哈希值来确定 桶，并使用equals()方法查找该值是否已经 出现在桶里。如果不是，它将被添加，否则它将被替换为当前值 get('key')将使用hashCode()首先找到条目(桶) equals()来查找Entry中的值

如果两者都被覆盖，

地图<A>

Map.Entry 1 --> 1,3,5,...
Map.Entry 2 --> 2,4,6,...

If =没有被覆盖

地图<A>

Map.Entry 1 --> 1,3,5,...,1,3,5,... // Duplicate values as equals not overridden
Map.Entry 2 --> 2,4,6,...,2,4,..

如果hashCode没有被覆盖

地图<A>

Map.Entry 1 --> 1
Map.Entry 2 --> 2
Map.Entry 3 --> 3
Map.Entry 4 --> 1
Map.Entry 5 --> 2
Map.Entry 6 --> 3 // Same values are Stored in different hasCodes violates Contract 1
So on...

HashCode等价契约

根据equal方法，两个相等的键应该生成相同的hashCode 生成相同hashCode的两个key不需要相等(在上面的例子中，所有偶数生成相同的hashCode)