一、HashMap 扩容核心流程
HashMap 底层是「数组 + 链表 / 红黑树」结构，当元素数量达到阈值时，会触发扩容 ------ 本质是创建更大的数组，并将旧数组中的所有元素迁移到新数组，以保证查询效率。
1. 触发条件
- 通用条件（1.7/1.8 共用） ：
size > Hash表容量 * 0.75（负载因子默认 0.75） - 1.8 新增条件：链表树化判断 → 当某个链表长度 > 8，但数组长度 < 64 时，也会触发扩容（优先扩容而非树化）
2. 创建新数组
扩容时会创建一个容量为原数组 2 倍的新数组（保证容量始终是 2 的幂，便于位运算优化）：
int oldCap = oldTab.length;
int newCap = oldCap << 1; // 等价于 oldCap * 2
Node<K,V>[] newTab = (Node<K,V>[]) new Node[newCap];3. 元素迁移：核心四部曲
迁移前先明确关键规则：
- 旧下标：
index = hash & (oldCap - 1) - 新容量：
newCap = 2 * oldCap - 新下标判断：
hash & oldCap == 0→ 新下标 = 旧下标hash & oldCap == 1→ 新下标 = 旧下标 + 旧容量
迁移时按以下四步处理旧数组的每个桶：
第一步：空桶直接跳过
遍历旧数组时，若当前位置为 null，则无需处理，直接跳过。
第二步：单个节点直接计算新下标
若桶中只有一个节点，直接计算新下标并放入新数组：
newTab[e.hash & (newCap - 1)] = e;第三步：链表节点拆分迁移
若桶中是链表，按 hash & oldCap 拆分为低位链表（low）和高位链表（high）：
- 低位链表：新下标 = 旧下标
- 高位链表：新下标 = 旧下标 + 旧容量
- 采用尾插法保持原链表顺序，避免并发死循环
第四步：红黑树节点拆分迁移
若桶中是红黑树，同样按 hash & oldCap 拆分为两棵树：
- 统计每棵树的节点数：
- 节点数 ≤ 6 → 降级为链表（避免小数据量下红黑树的性能开销）
- 节点数 > 6 → 保持红黑树结构，重新调整平衡
- 低位树 → 新下标 = 旧下标
- 高位树 → 新下标 = 旧下标 + 旧容量
二、JDK 1.7 与 1.8 扩容迁移差异对比
表格
| 维度 | JDK 1.7 | JDK 1.8 |
|---|---|---|
| 插入方式 | 头插法（扩容后链表会倒置） | 尾插法（保持原链表顺序） |
| 迁移方式 | 重新计算每个节点的下标，逐个插入新容器，效率低 | 拆分链表 / 红黑树，整体迁移，效率更高 |
| 并发安全性 | 头插法可能导致环形链表，引发死循环 | 尾插法避免链表反转，无环形链表问题，更安全 |
| 红黑树支持 | 无红黑树，冲突严重时链表过长，查询效率退化 | 链表长度 ≥ 8 时转为红黑树；扩容时节点数 ≤ 6 则退化为链表 |
三、关键原理：为什么 hash & oldCap 能判断新下标？
HashMap 数组容量始终是 2 的幂（如 16 → 32）：
- 旧容量
oldCap = 16→ 二进制10000 - 新容量
newCap = 32→ 二进制100000
下标计算本质是 hash % 容量，优化为 hash & (容量 - 1)：
- 旧下标：
hash & 15（二进制01111） - 新下标：
hash & 31（二进制11111）
新下标仅比旧下标多判断最高一位二进制位 ，而 hash & oldCap 正好能判断这一位：
- 结果为 0 → 该位是 0 → 新下标 = 旧下标
- 结果为 1 → 该位是 1 → 新下标 = 旧下标 + 旧容量
示例：
- 元素 A：
hash = 5（二进制00101）→5 & 16 = 0→ 新下标 = 原下标 5 - 元素 B：
hash = 21（二进制10101）→21 & 16 = 16→ 新下标 = 5 + 16 = 21
四、面试高频考点总结
- 扩容触发条件 ：
size > 容量 * 0.75（1.7/1.8 共用）；1.8 新增「链表长度 > 8 且数组长度 < 64」时优先扩容。 - 新下标计算 ：利用
hash & oldCap快速判断，避免重复计算hash % 新容量。 - 1.7 与 1.8 核心差异：头插法 vs 尾插法、逐个迁移 vs 整体拆分、无红黑树 vs 红黑树支持。
- 并发安全问题：1.7 头插法可能导致环形链表死循环，1.8 尾插法解决此问题。
- 红黑树降级规则：扩容后树节点数 ≤ 6 时退化为链表，避免频繁树化 / 链表化切换。
