解剖HashMap的put ＜三＞ JDK1.8

完成了前两步，第三步是 "处理哈希冲突" ------ 当计算出的索引对应的数组位置（桶）已经有元素时，需要根据桶中元素的结构（链表或红黑树）进行针对性操作。第三步的核心是 "在冲突中平衡正确性与效率"：既要通过 Key 的唯一性检查保证数据准确，又要通过合理的存储方式和结构优化（链表转红黑树）避免冲突导致的性能下降，最终维持 HashMap "高效存取" 的核心优势。

前提：什么情况下会进入第三步？

经过第一步（计算哈希值）和第二步（计算索引）后，我们得到了元素要放入的桶索引index。此时会检查数组的table[index]（即桶的头节点）：

如果table[index] == null（桶为空）：直接插入新节点，无需处理冲突（跳过第三步）。
如果table[index] != null（桶不为空）：说明发生了哈希冲突（已有元素占用了该索引），进入第三步处理。

第三步的核心操作：根据桶的结构处理冲突

JDK 1.8 中，桶的结构有两种：链表（Node） 或红黑树（TreeNode），处理方式不同。

情况 1：桶中是链表（节点类型为`Node`）

当桶中的元素以链表形式存储时（默认结构，或红黑树退化后的结构），流程如下：

检查头节点是否与新 Key 相同

比较头节点的哈希值和新 Key 的哈希值，同时用equals()比较 Key 内容：
- 如果相同（哈希值相同且equals返回 true）：说明是同一个 Key，后续会更新其 value。
- 如果不同：继续遍历链表。
遍历链表，查找相同 Key

顺着链表的next指针逐个检查节点：
- 找到相同 Key 的节点：标记该节点，后续更新其 value。
- 遍历到链表尾部仍未找到：说明是新 Key，需要插入新节点。

插入新节点（尾插法）

JDK 1.8 采用尾插法（新节点放在链表末尾），而非 1.7 的头插法（避免多线程下的链表成环问题）。

java

运行

java 复制代码

// 伪代码：链表尾部插入新节点
while (当前节点的next != null) {
    移动到下一个节点;
}
当前节点的next = 新节点; // 新节点成为链表最后一个元素

检查是否需要转为红黑树

插入新节点后，链表长度会增加。此时需要判断：
- 如果链表长度 ≥ 8 ，且数组容量 ≥ 64 ：将链表转为红黑树（treeifyBin()方法），提升查询效率（从 O (n) 优化为 O (log n)）。
- 如果数组容量 < 64：不转树，而是先扩容（通过增加数组容量减少冲突）。

情况 2：桶中是红黑树（节点类型为`TreeNode`）

当链表长度≥8 且数组容量≥64 时，链表会转为红黑树（一种自平衡二叉查找树）。此时处理冲突的流程如下：

在红黑树中查找相同 Key

利用红黑树的特性（左子树节点值≤根节点，右子树节点值≥根节点），通过哈希值和equals()比较快速定位 Key：
- 找到相同 Key：标记该节点，后续更新其 value。
- 未找到：说明是新 Key，需要插入新节点。
插入新节点并维持红黑树平衡

新节点插入后，红黑树会通过变色和旋转操作（左旋、右旋）维持平衡，保证树的高度始终是 O (log n)，确保查询效率。

最后插一嘴：

三个关键目标：

1. 确保 Key 的唯一性，正确处理重复 Key

HashMap 的核心特性是 "Key 唯一"（相同 Key 会覆盖 value）。当发生哈希冲突时，必须先判断桶中是否已存在 "相同的 Key"（哈希值相同且equals()返回 true）：

若存在：更新该 Key 对应的 value（保证 Key 唯一，避免重复存储）。
若不存在：确认是新 Key，需要将其正确加入当前桶中。

2. 妥善存储新 Key，维持数据结构的完整性

当确认是新 Key 时，需根据桶的当前结构（链表或红黑树），将新节点插入到合适位置：

链表结构：采用尾插法插入尾部（避免 JDK 1.7 头插法的线程安全问题）。
红黑树结构：按照树的插入规则插入，并通过旋转 / 变色维持树的平衡。

目的是保证数据结构不被破坏，后续能正常查询和操作。

3. 优化冲突场景的性能，避免效率退化

哈希冲突不可避免，但大量冲突会导致桶中的链表过长（查询时间复杂度从 O (1) 退化为 O (n)）。因此第三步的关键目标之一是通过结构转换优化性能：

当链表长度≥8 且数组容量≥64 时，将链表转为红黑树（查询时间复杂度优化为 O (log n)）。
若数组容量不足 64，则优先通过扩容减少冲突（而非转树），因为小容量下扩容更能从根本上分散元素。