Java中哈希冲突主要通过链式寻址解决，HashMap采用“数组+链表/红黑树”结构，冲突时尾插链表，链表长度≥8且数组长度≥64时转红黑树，≤6时退化回链表；未采用开放寻址因其删除复杂、负载高时性能退化、null键支持困难、扩容开销大。
Java中哈希冲突主要通过链式寻址（Chaining）解决，开放寻址（Open Addressing）在标准库中未被采用，仅存在于部分自定义实现或教学场景中。
HashMap 默认用链式寻址处理冲突
Java 8 的 HashMap 底层是“数组 + 链表/红黑树”结构。当多个键的 hashCode() 经扰动与取模后映射到同一数组索引时，就发生哈希冲突。此时新节点会以链表形式挂在该桶（bucket）下：
- 初始插入都走链表尾插（Java 8 起改为尾插，避免多线程扩容死循环）
- 当链表长度 ≥ 8 且数组长度 ≥ 64 时，自动转为红黑树，提升查找效率至 O(log n)
- 若树中节点数 ≤ 6，则退化回链表
为什么 HashMap 不用开放寻址？
开放寻址要求所有元素都存于原数组内，通过探测（如线性探测、二次探测、双重哈希）找空位。但 Java 的 HashMap 没有采用它，原因包括：
- 删除操作复杂：不能简单置空，否则会截断探测序列，需设特殊标记（如
DELETED），增加逻辑负担 - 空间利用率高但性能易退化：负载因子稍高（如 >0.7）时，聚集效应明显，查找/插入变慢
- 不支持 null 键值的自然表达：开放寻址依赖空位判断，而
HashMap允许一个 null 键，链式更直观 - 扩容成本低：链式结构扩容只需重哈希+拆分链表；开放寻址扩容需全部重新探测插入，开销更大
开放寻址在 Java 中并非完全缺席
虽然 HashMap、HashSet 等核心集合不用开放寻址，但某些场景会用到类似思想：
立即学习“Java免费学习笔记（深入）”；
-
ThreadLocalMap内部使用线性探测的开放寻址（key 为弱引用，value 强引用，探测遇到 null 才停止） - 高性能库如
fastutil、trove提供基于开放寻址的原始类型 Map（如IntIntHashMap），避免装箱、节省内存 - 自定义哈希表教学或特定嵌入式场景中，可能手动实现线性/二次探测
链式 vs 开放寻址：关键对比点
选型要看场景需求：
- 内存敏感 + 原始类型多 → 开放寻址更优（无节点对象开销，缓存局部性好）
- 需支持 null 键/值、动态扩容频繁、代码可维护性优先 → 链式更稳妥
-
并发安全要求高 → 两者都要额外同步；
ConcurrentHashMap用分段锁+链表/树，非开放寻址 - 最坏情况稳定性：开放寻址最坏 O(n)，链表也是 O(n)，但红黑树兜底让链式平均表现更可控
基本上就这些。Java 标准集合坚定选择链式为主干，开放寻址是补充而非替代——理解差异，才能在需要极致性能时知道该去哪找轮子。
