在(大多数)老式处理器上，乘以31可能相对便宜。例如，在ARM上，它只有一条指令:

RSB       r1, r0, r0, ASL #5    ; r1 := - r0 + (r0<<5)

大多数其他处理器都需要单独的移位和减法指令。然而，如果你的乘数很慢，这仍然是一种胜利。现代处理器往往具有快速乘法器，所以只要32在正确的一边，就没有太大区别。

这不是一个很好的哈希算法，但它已经足够好了，比1.0代码更好(比1.0规范好得多!)。

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

在(大多数)老式处理器上，乘以31可能相对便宜。例如，在ARM上，它只有一条指令:

RSB       r1, r0, r0, ASL #5    ; r1 := - r0 + (r0<<5)

大多数其他处理器都需要单独的移位和减法指令。然而，如果你的乘数很慢，这仍然是一种胜利。现代处理器往往具有快速乘法器，所以只要32在正确的一边，就没有太大区别。

这不是一个很好的哈希算法，但它已经足够好了，比1.0代码更好(比1.0规范好得多!)。

在最新版本的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然后减去自己，因此需要廉价的资源。

根据Joshua Bloch的《Effective Java》(这本书再怎么推荐都不为过，多亏了stackoverflow上不断的提及，我才买了这本书):

选择值31是因为它是一个奇质数。如果它是偶数并且乘法溢出，信息就会丢失，因为乘2相当于移位。使用质数的优势不太明显，但它是传统的。31的一个很好的属性是乘法可以被移位和减法代替，以获得更好的性能:31 * i == (i << 5) - i。现代虚拟机自动进行这种优化。

(摘自第3章第9项:重写equals时总是重写hashcode，第48页)

Java字符串hashCode()和31

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

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