Java字符串hashCode()和31

这是因为31有一个很好的属性——它的乘法运算可以被逐位移位取代，这比标准乘法运算快得多:

31 * i == (i << 5) - i

Bloch并没有深入研究这个问题，但我总是听到/相信这是基本的代数。哈希可以归结为乘法和模运算，这意味着如果可以的话，永远不要使用带公因式的数字。换句话说，相对素数提供了答案的均匀分布。

使用哈希的数字通常是:

你放入的数据类型的模量 (2^32或2^64) 哈希表中桶数的模数(变化。在java中，以前是质数，现在是2^n) 在混合函数中乘以或平移一个神奇的数字 输入值

实际上，您只能控制其中的几个值，因此需要多加注意。

尼尔·科菲解释了为什么在熨平偏差下使用31。

基本上，使用31可以为哈希函数提供更均匀的集位概率分布。

You can read Bloch's original reasoning under "Comments" in http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4045622. He investigated the performance of different hash functions in regards to the resulting "average chain size" in a hash table. P(31) was one of the common functions during that time which he found in K&R's book (but even Kernighan and Ritchie couldn't remember where it came from). In the end he basically had to choose one and so he took P(31) since it seemed to perform well enough. Even though P(33) was not really worse and multiplication by 33 is equally fast to calculate (just a shift by 5 and an addition), he opted for 31 since 33 is not a prime:

剩下的 第四，我可能会选择P(31)，因为它是RISC上最便宜的计算方法 机器(因为31是2的2次幂之差)P (33) 同样，计算起来很便宜，但它的性能稍微差一些，并且 33是合数，这让我有点紧张。

因此，推理并不像这里的许多答案所暗示的那样理性。但我们都善于在做出直觉决定后提出理性的理由(甚至布洛赫也可能倾向于这样)。

在最新版本的JDK中，仍然使用31。https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html hashCode ()

哈希字符串的目的是

唯一(让我们看看hashcode计算文档中的运算符^，它有助于唯一) 计算成本低

31是可以放入8位(= 1字节)寄存器的最大值，是可以放入1字节寄存器的最大素数，是奇数。

31乘以<<5然后减去自己，因此需要廉价的资源。

我不确定，但我猜他们测试了一些质数样本，发现31在一些可能的字符串样本中给出了最好的分布。