31被选为哈希乘数因其是奇素数，可均匀散列字段贡献，避免低位趋同与重复模式；且31×n可优化为(n
为什么用 31 而不是 2、10 或其他数字
31 不是随便挑的 magic number，它在数学特性和 JVM 实现上都有明确依据。用 2 相当于左移，低位全补 0，大量对象的 hash 值会在低位趋同；用 10 这类合数会放大低位重复模式（比如多个字段末位都是 0、5，乘 10 后更容易撞）。而 31 是奇素数，能更均匀地“搅散”各字段的哈希贡献。
更重要的是，31 == (1 ，JVM 可以将 <code>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() 根本没机会被调用。
