怎么理解HashMap在扩容时重新分配Hash槽位的重排逻辑

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《怎么理解HashMap在扩容时重新分配Hash槽位的重排逻辑》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

扩容无需重算hash值，因容量恒为2的幂次方，新索引仅取决于原hash在新增bit位的值；JDK 1.8用e.hash & oldCap快速提取该位，0则留原索引，非0则原索引+oldCap。

扩容时为什么不用重新计算 hash 值

因为容量始终是 2 的幂次方，扩容就是左移一位（比如从 16 → 32），所以 newCap - 1 比 oldCap - 1 多一个高位 bit。这意味着新索引只取决于原 hash 值在那个新增 bit 位上是 0 还是 1。

举例：旧容量 16，oldCap - 1 = 15（二进制 00001111）；新容量 32，newCap - 1 = 31（二进制 00011111）。多出来的那一位（第 5 位，从 0 开始数）就是判断依据。

所以 JDK 1.8 直接用 e.hash & oldCap 判断——这个操作等价于取那个新增 bit 位的值：

• 结果为 0 → 新索引 = 旧索引
• 结果非 0 → 新索引 = 旧索引 + oldCap

e.hash & oldCap 这个判断到底在算什么

它不是在算哈希值本身，而是在快速提取 hash 值中「与旧容量对齐的那个 bit」的值。

比如 oldCap == 16（二进制 00010000），那么 e.hash & oldCap 就是在看 e.hash 的第 4 位（从 0 开始）是不是 1：

• hash = 00000101（5）→ & 00010000 = 00000000 → 留在原位置
• hash = 00010101（21）→ & 00010000 = 00010000 → 移到 原索引 + 16

这个技巧把原本要重算 hash & (newCap - 1) 的开销，降到了一次位与操作 + 一次加法。

链表节点怎么拆成两个子链表

扩容时每个桶（oldTab[j]）上的链表不会整体搬移，而是边遍历边按 e.hash & oldCap 拆成两个新链表：

• 低位链表（loHead）：所有 (e.hash & oldCap) == 0 的节点，头尾保持原顺序，最终挂到 newTab[j]
• 高位链表（hiHead）：所有 (e.hash & oldCap) != 0 的节点，也保持原顺序，最终挂到 newTab[j + oldCap]

注意：JDK 1.8 改用尾插法，所以链表顺序和原链表一致；而 JDK 1.7 头插法会导致链表反转，在并发扩容时可能成环——这是实际踩坑高频点。

红黑树在扩容时怎么处理

红黑树节点也会被拆分，但逻辑更重一点：

• 先遍历整棵树，对每个节点执行 e.hash & oldCap 判断，分别归入低位/高位两组
• 每组节点数 ≤ 6 → 退化为链表，插入对应新桶
• 每组节点数 ≥ 8 → 构建新的红黑树，再插入对应新桶
• 如果某组只有 1 个节点，直接作为 TreeNode 插入（不建树也不转链）

这个过程没有“保留原树结构”的优化，所以红黑树越多、单桶越深，扩容耗时越明显——这也是为什么建议合理设置初始容量，避免频繁 resize。

真正容易被忽略的是：扩容后，哪怕只是单个节点，它的新位置也严格由 hash 和新容量决定；而链表/树的拆分逻辑，本质是批量复用这个判断，不是“随机打散”，也不是“均匀重排”，而是确定性的、可预测的位置偏移。

理论要掌握，实操不能落！以上关于《怎么理解HashMap在扩容时重新分配Hash槽位的重排逻辑》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！