Java中string中hashcode_为什么String中的Java hashCode（）使用31作为乘数？

从JDK-4045622开始，Joshua Bloch描述了选择特定(新) String.hashCode() 实施的原因

下表总结了上述各种哈希函数的性能，对于三个数据集：1)Merriam-Webster的第二个国际未删节字典中的所有单词和短语(311,141个字符串，平均长度为10个字符) . 2)/ bin /，/ usr / bin /，/ usr / lib /，/ usr / ucb /和/ usr / openwin / bin / *(66,304字符串，平均长度为21个字符)中的所有字符串 . 3)昨晚运行了几个小时的网络爬虫收集的URL列表(28,372个字符串，平均49个字符) . 表中所示的性能度量是散列表中所有元素的“平均链大小”(即，与查找元素相比，密钥数量的预期值) . Webster的代码字符串URL

当前的Java Fn . 1.2509 1.2738 13.2560

P(37)[Java] 1.2508 1.2481 1.2454

P(65599)[Aho等] 1.2490 1.2510 1.2450

P(31)[K R] 1.2500 1.2488 1.2425

P(33)[Torek] 1.2500 1.2500 1.2453

Vo的Fn 1.2487 1.2471 1.2462

WAIS Fn 1.2497 1.2519 1.2452

Weinberger的Fn(MatPak)6.5169 7.2142 30.6864

Weinberger的Fn(24)1.3222 1.2791 1.9732

Weinberger的Fn(28)1.2530 1.2506 1.2439

看看这个表，很明显除了当前的Java函数和Weinberger函数的两个破坏版本之外的所有函数都提供了极好的，几乎无法区分的性能 . 我强烈推测这种性能本质上是“理论上的理想”，如果你用一个真正的随机数发生器来代替散列函数，那就是你所得到的 . 我排除了WAIS函数，因为它的规范包含随机数页面，并且它的性能并不比任何更简单的函数更好 . 其余六个功能中的任何一个看起来都是很好的选择，但我们必须选择一个 . 我想我会排除Vo的变体和Weinberger的功能，因为它们增加了复杂性，尽管很小 . 在剩下的四个中，我可能选择P(31)，因为它是在RISC机器上计算最便宜的(因为31是2的两个幂的差异) . P(33)计算起来同样便宜，但它的表现稍微差一点，而且33是复合的，这让我有点紧张 . 玩笑