java - Enum.hashCode() 背后的原因是什么？

Question

Enum 类中的方法 hashCode() 是 final 的，定义为 super.hashCode()，表示它根据实例地址返回一个数字，是程序员 POV 的随机数。

定义它，例如因为 ordinal() ^ getClass().getName().hashCode() 在不同的 JVM 中是确定性的。它甚至会更好一点，因为最低有效位会“尽可能多地改变”，例如，对于包含多达 16 个元素和大小为 16 的 HashMap 的枚举，肯定不会发生冲突(当然，使用 EnumMap 更好，但有时不可能，例如没有 ConcurrentEnumMap)。按照目前的定义，你没有这样的保证，是吗？

答案总结

使用 Object.hashCode() 与上面类似的更好的 hashCode 进行比较，如下所示:

• 优点
  • 简单
• 对比
  • 速度
  • 更多冲突(对于任何大小的 HashMap)
  • 不确定性，它会传播到其他对象，使它们无法用于
    • 确定性模拟
    • ETag 计算
    • 寻找错误取决于例如在 HashSet 迭代顺序上

我个人更喜欢更好的 hashCode，但恕我直言，没有理由很重要，也许除了速度。

更新

我对速度很好奇，写了一个benchmark令人惊讶results .对于每个类的单个字段的价格，您可以获得几乎快四倍的确定性哈希码。在每个字段中存储哈希码会更快，尽管可以忽略不计。

标准哈希码没有快多少的解释是它不能是对象的地址，因为对象被 GC 移动。

更新 2

有些奇怪的东西going on具有一般的 hashCode 性能。当我理解它们时，还有一个悬而未决的问题，为什么 System.identityHashCode(从对象头读取)比访问普通对象字段慢得多。

Answer 1

The only reason for using Object's hashCode() and for making it final I can imagine, is to make me ask this question.

首先，您不应该依赖这种机制在 JVM 之间共享对象。这根本不是受支持的用例。当您序列化/反序列化时，您应该依靠自己的比较机制或仅将结果与您自己的 JVM 中的对象“比较”。

让枚举 hashCode 实现为 Objects 哈希码(基于身份)的原因是，在一个 JVM 中，只有一个每个枚举对象。这足以确保这样的实现有意义且正确。

你可能会这样争论 “嘿，String 和原语的包装器(Long、Integer、...)都有明确的、确定性的 hashCode 规范!为什么没有'枚举有吗？”，嗯，首先，你可以有几个不同的字符串引用代表同一个字符串，这意味着使用 super.hashCode 将是一个错误，所以这些类必然需要自己的 hashCode 实现。对于这些核心类，让它们具有明确定义的确定性 hashCode 是有意义的。

Why did they choose to solve it like this?

好吧，看看the requirements of the hashCode implementation .主要关注的是确保每个对象都应该返回一个 distinct 哈希码(除非它等于另一个对象)。基于身份的方法非常有效并保证了这一点，而您的建议却没有。这个要求显然比任何关于放宽序列化等的“便利奖励”都要强。