hashCode碰撞本身不是错误，而是哈希机制固有现象；真正拖慢HashMap的是碰撞导致链表过长、树化失败或桶分布不均，使O(1)查找退化为O(n)，甚至引发频繁扩容和线程竞争。
hashCode 碰撞本身不是错误，而是哈希机制的固有现象；真正影响 HashMap 性能的，是碰撞后引发的链表过长、树化失败或桶分布严重不均——这会让 O(1) 查找退化为 O(n)，甚至触发频繁扩容和线程竞争。
hashCode 碰撞为什么拖慢 HashMap
HashMap 不直接用 key.hashCode() 定位桶，而是先经过扰动函数：static final int hash(Object key) { return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }
再通过 index = hash & (n - 1)（n 是数组长度，2 的幂）计算下标。这意味着：只有哈希值的低位参与桶定位。
如果多个 key 的 hashCode 低位高度重复（比如只依赖一个 short 字段、或全用常量 1），哪怕高位不同，也会挤进同一个桶。结果就是：
- 单个桶内链表持续增长，get/put 需遍历链表 → 时间从纳秒级升至毫秒级
- 链表长度 ≥8 时本该转红黑树，但若 table 容量
- 大量桶为空、少数桶塞满 → 负载因子失衡，resize 频繁触发，CPU 和内存压力陡增
自定义类重写 hashCode 的三个关键避坑点
系统类（String、Integer）已优化到位，风险集中在业务实体类。重点检查：
- 字段覆盖必须完整：equals 比较哪些字段，hashCode 就必须包含哪些字段。漏掉一个（比如只算 id 忽略 name），既违反契约，又让相等对象散列到不同桶，不等对象反而挤进同一桶
- 别用固定值或弱熵字段：return 1;、return flag ? 0 : 1;、仅用 boolean 或枚举 ordinal() —— 这些会让成百上千对象映射到同一桶
- 禁止在 key 放入后修改影响 hashCode 的字段：比如 Person p = new Person("A", 25); map.put(p, "x"); p.setAge(30); → 后续 get(p) 找不到，因为 hashCode 已变，桶位置错乱
推荐的写法与验证手段
不用手算 31 * a + b，直接用 JDK 提供的安全组合工具：
立即学习“Java免费学习笔记（深入）”；
- 普通字段：用
Objects.hash(field1, field2, field3)—— 自动判 null、适配基本类型、内部已做扰动 - 数组字段：必须用
Arrays.hashCode(arr)，不能直接 arr.hashCode() - 集合字段：用
Objects.hash(list)，它会递归调用元素的 hashCode
验证是否有效：
- 打印几个语义不同但结构相近的实例 hashCode，看数值是否明显区分（如 new Person("a", 1) 和 new Person("a", 2)）
- 用 Arthas trace HashMap.putVal 或 JFR 录制，观察各 bucket 的 Node 数量分布是否均匀（理想状态是大部分桶为 0 或 1，极少数 ≤4）
- 检查日志中是否有连续多次 resize，或线程堆栈长时间卡在 getNode 的 for 循环里
记录类（record）的天然优势
Java 14+ 的 record 自动生成 hashCode，按字段声明顺序调用各自 hashCode 并组合（类似 Objects.hash），且强制不可变。只要字段选得合理，基本无需额外干预：
- 字段顺序不同 → hashCode 不同（record A(String s, int i) 和 B(int i, String s) 不兼容）
- null 字段安全处理，但别把可变 List 塞进去 —— record 保证引用不变，不保证内容不变
- 自动满足 equals/hashCode 一致性契约，省去人工校验成本
本质上，hashCode 写得好不好，决定的是数据在哈希表里的“居住密度”。密度越均匀，查找越快；密度越集中，性能越容易崩。这不是玄学，而是可观察、可测量、可修复的具体问题。
