Java中的String.hashCode()方法可能有问题？

过去几天，我一直在浏览 Reddit 上的一篇文章。这篇文章看得我要抓狂了。文章指出，Java 中的 String.hashCode() 方法（将任意长度的字符串对象映射成 32 位 int 值）生成的哈希值存在冲突。文章作者似乎对这个问题感到很惊讶，并声称 String.hashCode() 的算法是有问题的。用作者自己的话说：

不管使用哪一种哈希策略，冲突都是不可避免的，但其中总有相对较好的哈希也有较差的哈希。你可以认为 String 中的哈希是比较差的那种。

作者的措辞带有相当强烈的意味，并且已经证明了很多奇怪的短字符串在生成哈希时会产生冲突。（文章中提供了很多示例，例如!~ 和"_）。众所周知，32 位字符串哈希函数确实会发生很多冲突，但从经验来看，在真实的场景中，String.hashCode() 能够很好地管理哈希冲突。

那么“差”的哈希是什么样子的呢？而“好”的哈希又是什么样子的？

一点理论

32 位哈希只能占用 2^32 = 4,294,967,296 个唯一值。因为字符串中可以包含任意数量的字符，所以可能的字符串显然要比这个数字多得多。因此，根据鸽子原则，必然会存在冲突。

但冲突的可能性有多大？

著名的生日问题表明，对于 365 个可能的“哈希值”，在哈希冲突可能性达到 50％之前，必须计算出 23 个唯一哈希值。如果有 2^32 个可能的哈希值，那么在达到 50％的哈希冲突可能性之前，必须计算出大约 77,164 个唯一哈希值。根据这个近似公式：

原文链接:【 https://www.infoq.cn/article/2018/08/java-stringhashcode-plenty 】。未经作者许可，禁止转载。