如果您想要 64 位 int，murmurhash 或从 MD5 哈希中获取 64 位的冲突会更少吗？答案

【问题标题】：Would there be less collisions from murmurhash or from taking 64 bits from an MD5 hash if you want a 64 bit int?如果您想要 64 位 int，murmurhash 或从 MD5 哈希中获取 64 位的冲突会更少吗？
【发布时间】：2019-02-17 04:17:10
【问题描述】：

查看使用接受字符串并返回 64 位有符号整数值的散列算法。

它不必在密码学上是健全的，只需提供适当的冲突率即可用作分布式存储的密钥。

我在看杂音哈希that seems to fit the bill

很好奇它的属性与采用 MD5 哈希之类的前 64 位相比如何。

【问题讨论】：

可能大致相同（即，在散列字符串的数量接近 2^32 之前，意外碰撞的概率很小）。但我实际上没有可以参考的学术论文来支持这一点，只是 AFAIK 截断的 MD5 和 Murmur 3 的分布都相当好。
Murmur 可能会更快，并且对于哈希表的目的同样有效。
java7 可以在 HashMap 中为 String 使用 Murmur 哈希码。它有 2 个 hashCode 函数，一个是文档，一个是 hashCode() 和 murmur - hash32()，它是包私有和缓存的，就像普通的 hashCode() 一样。记住那个 impl。不像常规的 hashCode() 是不稳定的

标签： java algorithm hash

【解决方案1】：

安全散列——即使是理论上“破碎”的散列，如 MD5——表现出与随机性无法区分的分布（否则它们将不安全）。因此，它们尽可能接近完美。

与所有通用哈希函数一样，murmurhash 以正确性换取速度。虽然它对大多数输入都显示出非常好的分布特征，但它也有自己的病态案例，例如 documented here，其中重复的 4 字节序列比预期更频繁地导致冲突。

简而言之：使用安全散列函数永远不会更糟，有时甚至比使用通用散列更好。但是，它也会慢很多。

【讨论】：

我不确定碰撞是否适用于带有适当种子值的 murmur3。（现在应该弃用 murmur2）
总结是死的，但是：general purpose hash functions 做 not [trade] off correctness for speed。在任何给定输入分布的均匀性（通常在函数构造/选择时未知）和速度之间存在权衡。（另外，请注意 散列函数 上下文中的specific use of perfect。）