hashCode实施策略

Question

一些主要的JVM类(如字符串或列表实现)通过为每个与equals方法相关的field_n返回Σ 31^n * field_n.hashCode()来实现等于。此外，约书亚·布洛赫在“有效Java”(第9项)中推荐了这种方法。

但是，其他类(如实现 )遵循不同的规则。例如，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具有相同的哈希代码。

为什么Map.Entry hashCode选择这个实现规范而不是31 * (e.getKey()==null ? 0 : e.getKey().hashCode()) + (e.getValue()==null ? 0 : e.getValue().hashCode())？

编辑1:

为了帮助解决这个问题，下面是一个有用代码的示例，如果许多条目具有相同的键和值，则由于哈希冲突，结果的性能非常差。

该方法计算不同地图的条目的频率(使用番石榴的多集)。

public static <K, V> Multiset<Map.Entry<K, V>> computeEntryCounts(
        Iterable<Map<K, V>> maps) {
    ImmutableMultiset.Builder<Map.Entry<K, V>> result = ImmutableMultiset.builder();
    for (Map<K, V> map : maps) {
        for (Map.Entry<K, V> entry : map.entrySet()) {
            result.add(entry);
        }
    }
    return result.build();
}

Answer 1

我怀疑是否有好的理由-我认为这只是一个疏忽-但这不是一个严重的问题。只有当您有一个HashSet<Map.Entry<T,T>>或HashMap<Map.Entry<T,T>,V>时，才会出现这种情况，而这通常不是这样做的。(编辑后添加:或者，正如Joachim Sauer在下面指出的那样，HashSet<Map<T,T>>或HashMap<Map<T,T>,V> -也不常见。)

请注意，HashMap<K,V>不使用Map.Entry<K,V>.hashCode()，因为它只通过它们的键查找条目，所以它只使用K.hashCode()。

Answer 2

我个人的猜测是，hashCode也应该很快。

因为您可以重写hashCode，所以它没有问题。当您知道更适合您的情况的算法时，请更改它。