为什么库更喜欢在边缘情况下重新计算不可变对象的哈希码？

Question

在番石榴代码（我认为这是高质量代码的示例之一）中，我发现了以下片段：

// If the cachedHashCode is 0, it will always be recalculated, unfortunately.
private transient int cachedHashCode;

public final int hashCode() {
   // Racy single-check.
  int code = cachedHashCode;
  if (code == 0) {
    cachedHashCode = code = element.hashCode();
  }
  return code;
}

所以“如果 cachedHashCode 为 0，它总是会被重新计算，不幸的是”。另一个例子是JDKString.hashCode：

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;

        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

它也尝试计算一次哈希码，但如果String的hashCode为0则失败（此类字符串的示例为"\0"）。

避免此类重新计算的简单解决方案是增加对计算的额外检查：

if (hash == 0) hash++;

虽然在一般情况下它会稍微减慢hashCode 的计算速度，但这个技巧可以避免在反复计算时（并且缓慢（例如对于长字符串））一次又一次地计算最坏的情况。 为什么在 guava ImmutableSet 和 JDK String 中没有使用它？

编辑

最近的 Java 7 版本添加了自定义 String.hash32 实现，其中包含对这种特殊情况的处理：

       // ensure result is not zero to avoid recalcing
       h = (0 != h) ? h : 1;

Answer 1

这样做是为了节省空间。

例如，如果String 没有使用哈希值零来表示（未缓存），那么String 类将需要一个额外的布尔标志来表示哈希值未缓存。

因此，权衡是每次重新计算哈希的概率为 40 亿分之一¹，而不是为每个字符串对象增加一个单词。

---

^{1 - 这假设人们从所有可能的 Java 字符串的域中随机选择字符串对象。真正的程序不是这样工作的……但重点是重新计算哈希码的影响不大，除非你故意为此设计应用程序。}