质数31提升哈希分布均匀性

使用质数31作为哈希计算中的乘数，不仅能显著提升哈希值的分布均匀性、有效降低碰撞概率，还兼顾了计算效率——因其可被编译器优化为位移与减法组合（31×n ≡ (n

为什么用 31 而不是 2、10 或其他数字

31 不是随便挑的 magic number，它在数学特性和 JVM 实现上都有明确依据。用 2 相当于左移，低位全补 0，大量对象的 hash 值会在低位趋同；用 10 这类合数会放大低位重复模式（比如多个字段末位都是 0、5，乘 10 后更容易撞）。而 31 是奇素数，能更均匀地“搅散”各字段的哈希贡献。

更重要的是，31 == (1 ，JVM 可以将 result * 31 优化为 (result ，本质是位运算 + 减法，比普通乘法快。这不是过时的优化——现代 HotSpot 依然识别并应用该转换。

重写 hashCode 时怎么正确套用 31 的计算模式

核心公式是：result = 31 * result + fieldHash，其中 fieldHash 是字段本身的哈希值（基本类型用包装类 hashCode()，引用类型直接调用，null 统一返回 0）。

• 起始 result 不能设为 0，否则第一个字段为 null 时整轮计算归零；推荐从 1 开始
• 字段顺序必须固定，name 在前还是 age 在前，会影响最终值，但只要所有实例保持一致即可
• 数组字段不能直接用 array.hashCode()（那是内存地址），得用 Arrays.hashCode(array)
• 浮点字段（float/double）要用 Float.floatToIntBits() 或 Double.doubleToLongBits() 转成整型再参与计算

用 Objects.hash() 省事但要注意什么

Objects.hash(name, age, tags) 看似一行解决，但它底层调用的是 Arrays.hashCode(Object[])，对每个参数做非空判断并调用 hashCode()，最后仍按 31 * result + elemHash 累加。所以它和手写逻辑等价，但有两点隐含成本：

• 每次调用都新建一个临时 Object[] 数组，高频场景（如循环 put 到 HashMap）可能触发 GC
• 无法跳过某些字段（比如你只想用 id 和 status，但传了 5 个参数，多余的字段仍参与计算）
• 如果字段含数组，Objects.hash(arr) 会把整个数组对象当黑盒处理，得到的是其内存地址 hash，不是内容 hash —— 必须显式换成 Arrays.hashCode(arr)

碰撞不可能消除，只能控制在合理范围

哪怕你每个字段都用 31 搅拌十遍，只要 hashCode() 返回 int（32 位），就注定存在碰撞。Java 的 HashMap 不靠 “不碰撞” 工作，而是靠“碰撞后快速处理”：JDK 8+ 中，当桶内链表长度 ≥ 8 且 table size ≥ 64，会转为红黑树；这说明设计者默认碰撞是常态，重点是让单次查找从 O(n) 降为 O(log n)。

真正容易被忽略的是：如果你重写了 equals() 却没同步重写 hashCode()，哪怕只漏一个字段，HashSet 就可能存进两个逻辑相等的对象——因为它们被分到不同桶里，equals() 根本没机会被调用。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。