HashMap扩容时，会重新计算每个键的哈希值，并根据新的容量重新分配到对应的槽位中。具体步骤如下：创建新数组：创建一个容量为原容量两倍的新数组（或根据具体实现可能有不同）。重新计算哈希值：对每个键值对重新计算其哈希值。重新定位索引：根据新的数组长度，使用hash&(newCapacity-1)计算新的索引位置。迁移数据：将旧数组中的元素逐个迁移到新数组的对应位置。这一过程确保了在扩容后，

HashMap扩容时无需重新计算哈希值，巧妙利用容量恒为2的幂次方这一特性，通过一次位与运算（e.hash & oldCap）即可精准判断每个节点在新表中的归属位置——结果为0则留在原索引，非0则移至原索引加旧容量的位置，大幅降低计算开销；链表采用尾插法拆分为两个保持顺序的子链表，红黑树则按相同规则分组后依节点数量决定转链表、建新树或直接插入，整个过程确定、高效且可预测，但频繁扩容仍会显著影响性能，因此合理预设初始容量至关重要。

扩容时为什么不用重新计算 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&(newCapacity-1)计算新的索引位置。迁移数据：将旧数组中的元素逐个迁移到新数组的对应位置。这一过程确保了在扩容后，键值对能够均匀分布，减少哈希冲突，提高查询效率。》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！