Java字符串上hashCode()的一致性

Question

Java String的hashCode值计算为(String.hashCode()):

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

是否存在以下表达式将评估为false的任何情况(例如JVM版本,供应商等)？

boolean expression = "This is a Java string".hashCode() == 586653468

更新#1:如果您声称答案是"是,有这种情况" - 那么请举一个具体的例子,说明"这是一个Java字符串".hashCode()!= 586653468.尝试具体/具体尽可能.

更新#2:我们都知道,依赖hashCode()的实现细节通常很糟糕.但是,我正在特别谈论String.hashCode() - 所以请将答案集中在String.hashCode()上.Object.hashCode()在这个问题的上下文中完全不相关.

Answer 1

我可以看到早在Java 1.2的文档.

虽然通常你不应该依赖哈希代码实现保持不变,但它现在已经记录了行为java.lang.String,因此更改它将被视为破坏现有合同.

只要有可能,你不应该依赖于保持跨版本等相同的散列码-但在我的脑海里java.lang.String完全是因为算法的特殊情况已经指定了......只要你愿意放弃与以前版本的兼容性当然,指定了算法.

Answer 2

我发现了一些关于JDK 1.0和1.1以及> = 1.2的内容:

在JDK 1.0.x和1.1.x中,长字符串的hashCode函数通过对每个第n个字符进行采样来工作.这很好地保证你会有很多字符串散列到相同的值,从而减慢Hashtable查找速度.在JDK 1.2中,该函数已得到改进,将结果乘以31,然后按顺序添加下一个字符.这有点慢,但在避免碰撞方面要好得多.资料来源:http://mindprod.com/jgloss/hashcode.html

有些不同,因为你似乎需要一个数字:如何使用CRC32或MD5而不是哈希码,你很高兴 - 没有讨论也没有后顾之忧......

Answer 3

您不应该依赖哈希码等于特定值.只是它会在同一个执行中返回一致的结果.API文档说明如下:

hashCode的一般契约是:

• 每当在执行Java应用程序期间多次在同一对象上调用它时,hashCode方法必须始终返回相同的整数,前提是不修改对象上的equals比较中使用的信息.从应用程序的一次执行到同一应用程序的另一次执行,该整数不需要保持一致.

编辑 由于String.hashCode()的javadoc指定了如何计算String的哈希码,因此任何违反此规范的行都将违反公共API规范.

Answer 4

如上所述，一般来说，您不应依赖类的哈希码保持不变。请注意，即使同一虚拟机上同一应用程序的后续运行也可能会产生不同的哈希值。AFAIK Sun JVM 的哈希函数在每次运行时计算相同的哈希值，但这并不能保证。

请注意，这不是理论上的。的哈希函数在 JDK1.2 中java.lang.String 进行了更改（旧的哈希对于 URL 或文件名等分层字符串存在问题，因为它倾向于为字符串生成相同的哈希，仅在末尾有所不同）。

java.lang.String是一种特殊情况，因为它的算法hashCode()（现在）已记录在案，因此您可以信赖它。我仍然认为这是不好的做法。如果您需要一种具有特殊、记录属性的哈希算法，只需编写一个:-)。