当前位置：首页 > news >正文

解剖HashMap的put ＜三＞ JDK1.8

news 2025/8/15 7:06:01

完成了前两步，第三步是 “处理哈希冲突”—— 当计算出的索引对应的数组位置（桶）已经有元素时，需要根据桶中元素的结构（链表或红黑树）进行针对性操作。第三步的核心是 “在冲突中平衡正确性与效率”：既要通过 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

运行

// 伪代码：链表尾部插入新节点
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)，确保查询效率。