群集中的计算机之间的Java和string.hashCode（）稳定性

Question

我已经在.NET中请求similar question了解string.GetHashCode()方法。从那时起，我已经了解到，如果我们要在不同的机器上使用哈希代码，我们不能依赖隐式实现哈希代码。因此，我假设String.hashCode()的Java实现在不同的硬件配置下也不稳定，并且可能在不同的虚拟机之间表现不同（不要忘记不同的虚拟机实现）

目前我们正在讨论一种安全地将字符串转换为通过哈希计算，但散列算法必须在群集的不同节点上保持稳定，并且要快速评估，因为使用频率很高。我的队友坚持使用原生方法，我需要一些合理的论据让他们重新考虑另一种方法。目前，我只能想到机器配置（x86和x64）与可能不同的某些机器上JVM的供应商（我们的情况几乎不适用）和字节顺序差异（取决于算法所在的机器）之间的差异跑。当然，字符编码也可能被考虑。尽管所有这些东西都出现在我的脑海中，但我不能100％肯定他们两个都有足够的理由，我很感谢你在这方面的专业知识和经验。这将帮助我建立更有力的论据来支持编写自定义哈希算法。此外，我很感谢什么不执行实施它时。

Answer 1

的String.hashCode()实施是文档中specified，所以它的保证是一致的：

在字符串对象的哈希码被使用INT算术，其中s计算为

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

[i]是字符串的第i个字符，n是字符串的长度，^表示取幂。 （空字符串的散列值为零）

所有这些操作都是针对Java平台独立实现的 - 例如，平台字节顺序无关紧要。

也就是说，得到 a String的方法可能会很棘手，如果你从文件或其他字节来源获得它。在这种情况下，只要您明确指定Charset即可。 （请记住，String都不具备的不同编码本身;编码是转换一个byte[]和String之间的规范。）

Answer 2

你可以看看sourcecode, also shown below。从我所能看到的（经过10秒钟的分析）之后，这应该在机器和架构中保持稳定。路易斯通过引用一个规范来证实这一点，如果你相信规格，那就更好了。 :-)

但是，如果不同的JRE选择以不同的方式实施并违反规范，则可能会有所不同。

public int hashCode() { 
    int h = hash; 
    if (h == 0) { 
     int off = offset; 
     char val[] = value; 
     int len = count; 

     for (int i = 0; i < len; i++) { 
      h = 31*h + val[off++]; 
     } 

     hash = h; 
    } 

    return h; 
}