HashMap退化需据实排查：单次get/put耗时跃至毫秒级、线程卡在getNode()循环、JFR显示bucket链表长期≥8却未树化、GC频繁resize；根源多为自定义key的hashCode恒定、equals与hashCode字段不一致或key被修改，须用诊断代码验证哈希分布。
直接看运行时表现，别只盯代码有没有重写。真正出问题的不是“写了没写”，而是“写得对不对”——重点查哈希分布是否失衡、equals 和 hashCode 是否同步失效、key 是否被意外修改。
看 HashMap 实际行为是否退化
退化不是主观感觉，有明确可观测信号：
- 单次 get() 或 put() 耗时从纳秒级跳到毫秒级（用 JFR 或 Arthas 抓热点方法栈）
- 线程堆栈频繁卡在 HashMap.getNode() 的 for 循环里，说明正在遍历长链表
- JFR 中观察到某些 bucket 的链表长度长期 ≥8，但始终没转成红黑树（可能因容量不足 64，或 key 不实现 Comparable）
- GC 日志里 resize 频繁触发，扩容后很快又满，暗示负载因子被大量哈希冲突拉高
查自定义 key 类的实现逻辑
系统类（String、Integer）基本安全，问题几乎都出在业务实体类上。重点核对三件事：
-
hashCode 是否恒定？比如返回固定值
return 1;，或只依赖 boolean 字段，会导致所有实例挤进同一个桶 - 参与 equals 比较的字段，是否全部、且顺序一致地用于 hashCode？例如 equals 比了 id + name，但 hashCode 只用了 id，就会让逻辑相等的对象散列到不同位置
- key 对象是否可变？放入 HashMap 后调用了 setXXX 修改了影响 hashCode 的字段，后续 get 就找不到，还留下无法清理的“幽灵 entry”
用诊断代码验证哈希离散度
不靠猜，用真实数据说话。加一段临时统计：
立即学习“Java免费学习笔记（深入）”；
List<YourKey> keys = ...; // 当前 map 里的所有 key
int tableSize = 16; // 当前 HashMap.table.length
Map<Integer, Long> bucketDist = keys.stream()
.map(k -> k.hashCode() & (tableSize - 1))
.collect(Collectors.groupingBy(Function.identity(), Collectors.counting()));
bucketDist.forEach((bucket, count) ->
System.out.println("Bucket " + bucket + ": " + count + " entries"));
如果多数 bucket 是 0，而个别 bucket 高达 50+，说明哈希函数严重失效。
检查是否漏掉重写 hashCode
这是最常见也最容易忽略的低级错误：
- 只要重写了 equals()，就必须重写 hashCode() —— 否则 HashMap/HashSet 行为必然异常
- 典型现象：
map.put(new Person("A", 25), v)后，map.get(new Person("A", 25))返回 null - IDE 自动生成最稳妥：IntelliJ 或 Eclipse 的 “Generate → equals() and hashCode()” 会自动选中相同字段、处理 null 安全、使用 Objects.hash()
