java - 为什么 String 的 hashCode() 不缓存 0？

Question

我注意到在 String 的 Java 6 源代码中，hashCode 只缓存 0 以外的值。以下代码段展示了性能上的差异:

public class Main{
   static void test(String s) {
      long start = System.currentTimeMillis();
      for (int i = 0; i < 10000000; i++) {
         s.hashCode();
      }
      System.out.format("Took %d ms.%n", System.currentTimeMillis() - start);
   }
   public static void main(String[] args) {
      String z = "Allocator redistricts; strict allocator redistricts strictly.";
      test(z);
      test(z.toUpperCase());
   }
}

Running this in ideone.com给出以下输出:

Took 1470 ms.
Took 58 ms.

所以我的问题是:

• 为什么 String 的 hashCode() 不缓存 0？
• Java 字符串哈希为 0 的概率是多少？
• 对于散列为 0 的字符串，避免每次重新计算散列值的性能损失的最佳方法是什么？
• 这是缓存值的最佳做法吗？ (即缓存除一个之外的所有内容？)

---

为了你的开心，这里的每一行都是一个哈希为0的字符串:

pollinating sandboxes
amusement & hemophilias
schoolworks = perversive
electrolysissweeteners.net
constitutionalunstableness.net
grinnerslaphappier.org
BLEACHINGFEMININELY.NET
WWW.BUMRACEGOERS.ORG
WWW.RACCOONPRUDENTIALS.NET
Microcomputers: the unredeemed lollipop...
Incentively, my dear, I don't tessellate a derangement.
A person who never yodelled an apology, never preened vocalizing transsexuals.

Answer 1

你什么都不担心。这是思考这个问题的一种方式。

假设您有一个应用程序，除了整年都在散列字符串之外什么都不做。假设它需要一千个字符串，全部在内存中，以循环方式对它们重复调用 hashCode()，一百万次，然后再获取一千个新字符串并再次执行。

假设字符串的哈希码为零的可能性实际上远大于 1/2^32。我确定它有点大于 1/2^32，但假设它比这更糟糕，比如 1/2^16(平方根!现在更糟糕了!) .

在这种情况下，Oracle 的工程师改进了这些字符串的哈希码的缓存方式，您比其他任何人都更能从中受益。所以你写信给他们并要求他们修复它。他们施展魔法，只要 s.hashCode() 为零，它立即返回(即使是第一次!100% 的改进!)。假设他们这样做不会降低任何其他情况下的性能。

万岁!现在您的应用...让我们看看...快了 0.0015%!

过去需要一整天的时间现在只需 23 小时 57 分 48 秒!

请记住，我们设置场景是为了让怀疑的每一个可能的好处，通常到可笑的程度。

你觉得这值得吗？

编辑: 自从几个小时前发布此消息以来，我已经让我的一个处理器疯狂地寻找具有零哈希码的两个词的短语。到目前为止，它提出了:bequirtle zorillo、chronogrammic schtoff、contusive cloisterlike、creashaksorganzine、drumwood boulderhead、electroanalytic exercisable 和 favosely nonconstructable。这是大约 2^35 种可能性中的一种，因此在完美分布的情况下，我们预计只会看到 8 种。显然，当它完成时，我们会有几倍，但不会更多。更重要的是，我现在想出了一些有趣的乐队名/专辑名!偷窃不公平!