一些主要的JVM类(例如String或List implementations)通过为与equals方法相关的每个field_n返回Σ31^ n * field_n.hashCode()来实现等于.此外,Joshua Bloch在Effective Java(第9项)中推荐了这种方法.
但是,其他类如Map.Entry implementations遵循不同的规则.例如,Map.Entry文档指出Map.Entry的哈希码应该是
(e.getKey()==null ? 0 : e.getKey().hashCode()) ^
(e.getValue()==null ? 0 : e.getValue().hashCode())
这有时在哈希表中使用是不切实际的,因为：
>具有相同键和值的所有条目的哈希码为0,
>两个条目e1和e2,以便e1.key = e2.value和e1.value = e2.key具有相同的哈希码.
为什么Java选择Map.Entry hashCode的实现规范而不是例如31 *(e.getKey()== null？0：e.getKey().hashCode())(e.getValue()== null？0：e.getValue().hashCode())？
编辑1：
为了帮助解决问题,下面是一个有用代码的示例,如果许多条目具有相同的键和值,则由于散列冲突导致结果的性能非常差.
此方法计算不同地图条目的频率(使用Guava的Multiset).
public static 最佳答案
我怀疑这是一个很好的理由 – 我认为这只是一个疏忽 – 但这不是一个严重的问题.只有当你有一个HashSet< Map.Entry< T,T>>时才会出现它.或者HashMap< Map.Entry< T,T>,V>,这是不常见的. (编辑添加：或者,正如Joachim Sauer在下面指出的那样,HashSet< Map< T,T>>或HashMap< Map< T,V> – 也不常见.)
原文链接：https://www.f2er.com/java/438056.html注意HashMap< K,V>不使用Map.Entry< K,V> .hashCode(),因为它只按键查找条目,所以它只使用K.hashCode().
