哈希冲突过多导致链表变长、查找退化为O(n)，优化核心是减少冲突、加速冲突后查找、避免低效结构；根本措施是重写键的hashCode和equals，确保分布均匀且逻辑一致，并合理设置初始容量与负载因子。
哈希冲突过多会导致链表变长，查找退化为 O(n)，严重拖慢查询性能。优化核心是“减少冲突发生 + 加速冲突后查找 + 避免低效结构”，不是单纯调参数。
重写键的 hashCode 和 equals 方法
这是最根本的优化点。很多性能问题源于自定义对象作为 key 时 hashCode 分布不均。
- 避免只用一个字段（如 id）或常量返回 hashCode，应组合多个业务相关字段参与计算
- 确保 equals 与 hashCode 逻辑一致：若 a.equals(b) 为 true，则 a.hashCode() == b.hashCode() 必须成立
- 可借助 IDE 自动生成（如 IntelliJ 的 Alt+Insert → “hashCode and equals”），或使用 Apache Commons Lang 的 HashCodeBuilder
合理设置初始容量和负载因子
避免运行中频繁扩容，同时控制桶的平均负载。
- 预估元素总数 N，按公式 initialCapacity = (int) Math.ceil(N / 0.75) 设置初始容量（如预计存 120 个元素，设为 160）
- 不建议盲目调高负载因子（如设成 0.9），虽减少扩容次数，但显著增加冲突概率，得不偿失
- 容量必须是 2 的幂，直接传入 16、32、64 等值即可，HashMap 会自动对齐
利用红黑树加速长链查找
JDK 8+ 的树化机制只有在满足两个条件时才触发：链表长度 ≥ 8 且 数组长度 ≥ 64。冲突多但数组太小，树化不会发生。
立即学习“Java免费学习笔记（深入）”；
- 如果观察到大量桶的链表长度接近 8，说明当前容量偏小，应优先增大初始容量，而非等待树化
- 可通过 map.size() 和 map.entrySet().stream().filter(e -> e.getValue() instanceof TreeNode).count()（需反射辅助）粗略判断树化比例
- 树化后查找从 O(n) 降至 O(log n)，对单桶百级节点效果明显
检查扰动函数是否被有效利用
HashMap 的 hash() 方法会对原始 hashCode 做高/低位异或扰动，目的是让高位也影响索引计算，缓解低位重复导致的聚集。
- 若 key 的原始 hashCode 天然低位变化少（如某些 ID 生成器只递增低位），扰动作用有限，此时更依赖高质量的 hashCode 实现
- 无需手动调用 hash()，put 时已自动执行；但可验证：打印几个 key 的 key.hashCode() 和 HashMap.hash(key.hashCode())，看后者是否明显更分散
- 避免用简单数值（如 new Integer(1)）反复测试，它们的 hashCode 就是自身，扰动后变化有限
