Java和string.hashCode()在群集中的计算机之间的稳定性

Question

我也问过类似的问题为string.GetHashCode()在.NET方法.从那时起,我了解到如果我们要在不同的机器上使用它,我们就不能依赖于buit-in类型的哈希代码的隐式实现.因此,我假设Java实现String.hashCode()在不同的硬件配置中也不稳定,并且可能在VM之间表现不同(不要忘记不同的VM实现)

目前,我们正在讨论一种通过散列将字符串安全地转换为Java中的数字的方法,但是散列算法必须在群集的不同节点之间保持稳定,并且要快速评估,因为使用频率很高.我的队友坚持使用原生hashCode方法,我需要一些合理的论据让他们重新考虑另一种方法.目前,我能想到的唯一的机器配置之间(x86和x64)的JVM可能不同的厂商对某些机器(几乎适用于我们的情况下)和字节顺序不同的差异,根据不同的算法是在机器上跑.当然,也可以考虑字符编码.

虽然所有这些事情都浮现在我脑海中,但我并不是百分之百肯定他们中的任何一个都有足够的理由,我很感激你在这方面的专业知识和经验.这将有助于我建立更强大的论据,以支持编写自定义哈希算法.另外,我很欣赏有关实施时不应该做的建议.

Answer 1

的实现String.hashCode()是指定的文件中,所以它的保证是一致的:

String对象的哈希码计算为

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

使用int算术,其中s [i]是字符串的第i个字符,n是字符串的长度,^表示取幂.(空字符串的哈希值为零.)

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

也就是说,如果从文件或其他字节源获取它,获取 a的方法String可能会很棘手.在这种情况下,只要您明确指定一个,就可以了Charset.(请记住,Strings本身没有不同的编码;编码是a 和a 之间转换的规范.)byte[]String