集合（一）：HashMap 深度剖析——从 1.7 到 1.8 的进化之路

HashMap 是 Java 集合框架中最常用的类之一。它基于哈希表实现，提供了快速的键值对存储和查找机制。然而，随着 JDK 版本的迭代，HashMap 的底层实现发生了巨大的变化，特别是在 JDK 1.8 中，为了极致的性能优化，引入了红黑树结构。

本文将带你深入底层，剖析 HashMap 的核心原理、版本差异。

---

1. 核心架构演进

HashMap 的底层结构本质上是一个哈希桶（Bucket）数组，通过哈希函数将键映射到数组的索引位置。当发生哈希冲突（即不同的键映射到了同一个索引）时，需要一种机制来存储这些冲突的元素。

JDK 1.7：数组 + 链表

在 JDK 1.7 中，HashMap 的实现相对简单。它由一个数组（Entry Array）和链表组成。当发生冲突时，新元素会被放入链表中。

• 缺点：当哈希冲突非常严重时（例如遭遇哈希攻击），所有的元素都堆积在一条链表上。此时，查找的时间复杂度会从理想的 $O(1)$ 退化为 $O(n)$，性能急剧下降。

JDK 1.8：数组 + 链表 + 红黑树

为了解决 1.7 中链表过长导致性能退化的问题，JDK 1.8 引入了红黑树。

• 机制：当链表长度超过阈值（默认为 8）且数组长度超过 64 时，链表会转换为红黑树。
• 优势：红黑树是一种自平衡二叉查找树，其查找时间复杂度为 $O(\log n)$。即使发生严重冲突，性能也能得到保障。

---

2. 插入方式：头插法 vs 尾插法

JDK 1.7：头插法 (Head Insertion)

• JDK 1.7 HashMap 底层是「数组 + 单链表」结构，当数组下标冲突时，新元素会通过头插法插入链表（新节点成为链表头，原链表挂在新节点后）。
• 扩容（resize）时，需要遍历原数组的所有链表，将元素重新计算 hash 后迁移到新数组中，迁移过程仍使用头插法——这会导致原链表的顺序被反转。
• 单线程下头插法仅会反转链表，无问题；但并发环境下，多个线程同时扩容时，线程切换会打乱链表迁移的逻辑，最终形成环形链表。

头插法的缺陷说明

我们做以下假设：

• 原 HashMap 数组长度 = 2，负载因子 = 0.75，触发扩容后新数组长度 = 4；
• 原数组下标 0 处有链表：B -> A（B 是链表头，A 是尾节点）；
• 有两个线程（线程 1、线程 2）同时对该 HashMap 执行 put 操作，触发扩容。

阶段 1：扩容前的初始状态

阶段 2：线程 1 执行扩容，处理链表到一半被挂起

线程 1 开始迁移下标 0 的链表（B->A），执行到「取出节点 B，准备将 B 插入新数组」的步骤后，CPU 时间片用完，被操作系统挂起（此时线程 1 的局部变量仍持有 B、A 的引用）：

阶段 3：线程 2 完成扩容，链表被反转

线程 2 获得 CPU 时间片，完整执行扩容逻辑：

1. 遍历原链表 B -> A，用头插法迁移到新数组；
2. 先迁移 B：新数组下标 x 指向 B；
3. 再迁移 A：头插法让 A 成为新链表头，A.next = B，最终新链表变为 A -> B（原链表顺序被反转）；
4. 线程 2 扩容完成，更新 HashMap 的数组引用为新数组。

阶段 4：线程 1 恢复执行，触发环形链表

线程 1 恢复执行，此时它的局部变量仍持有「旧的引用：p=B，q=A」，但内存中 A.next 已经被线程 2 修改为 B（不再是 null）：

1. 线程 1 继续处理节点 B：将 B 头插到新数组，此时 B.next = null（线程 1 视角）；
2. 线程 1 处理下一个节点 q=A：执行头插法，将 A 插入新数组，此时会执行 A.next = B；
3. 但线程 2 早已将 B.next = A，最终形成环形链表：A -> B -> A。

环形链表的后果

当后续对该 HashMap 执行 get 操作，访问到这个环形链表时，遍历链表的代码会无限循环（while (p != null) { p = p.next; }），导致线程无法退出，CPU 使用率直接飙升至 100%。

JDK 1.8：尾插法 (Tail Insertion)

尾插法的说明

JDK 1.8 对 HashMap 做了关键改进：

1. 链表插入从「头插法」改为「尾插法」，扩容时保持链表顺序，彻底解决了并发扩容的环形链表/死循环问题；
2. 当链表长度≥8 时转为红黑树，提升查询性能。

但 HashMap 的核心设计仍未考虑线程安全——put 操作的核心逻辑（计算桶位、判断桶位是否为空、创建节点、赋值到桶位）没有任何原子性保障和并发控制，这导致并发场景下会出现数据覆盖（丢失） 的致命问题，这是 1.8 版本最核心的线程安全缺陷。

为简化说明，我们聚焦最典型的「空桶位并发插入导致数据覆盖」场景：

• 假设 HashMap 某桶位（下标 x）初始为空；
• 两个线程（线程 1、线程 2）同时执行 put(key, value)，且两个 key 的 hash 计算后都映射到下标 x；
• JDK 1.8 HashMap put 核心简化逻辑：

  // 简化版核心逻辑
  final V putVal(int hash, K key, V value) {
      Node<K,V>[] tab; Node<K,V> p; int n, i;
      // 1. 计算桶位 i = (n-1) & hash
      if ((p = tab[i = (n - 1) & hash]) == null) {
          // 2. 桶位为空，直接新建节点插入
          tab[i] = newNode(hash, key, value, null); // 非原子操作！
      }
      // ... 后续扩容/链表/红黑树逻辑省略
  }
  

阶段 1：初始状态，桶位 x 为空

阶段 2：线程 1 执行 put，判断桶位为空后被挂起

线程 1 执行 put(key1, value1)：

1. 计算 hash 得到桶位 x；
2. 判断 tab[x] == null（成立）；
3. 准备执行 tab[x] = newNode(key1, value1)，但此时 CPU 时间片用完，被操作系统挂起（仅完成「判断桶位为空」，未完成「节点创建+赋值」）。

阶段 3：线程 2 执行 put，成功插入节点

线程 2 获得 CPU 时间片，执行 put(key2, value2)：

1. 计算 hash 同样映射到桶位 x；
2. 判断 tab[x] == null（此时线程 1 未完成赋值，仍为 null，判断成立）；
3. 完整执行 tab[x] = newNode(key2, value2)，成功将节点 2 插入桶位 x。

阶段 4：线程 1 恢复执行，覆盖线程 2 的节点

线程 1 恢复执行，它不会重新判断 tab[x] 的状态（仍沿用之前「tab[x] == null」的判断结果），直接执行 tab[x] = newNode(key1, value1)：

• 线程 1 新建节点 1 并赋值给 tab[x]，覆盖了线程 2 插入的节点 2；
• 最终桶位 x 只有线程 1 的节点 1，线程 2 插入的节点 2 完全丢失（数据覆盖）。

3. 关键算法解析

3.1 扰动函数 (Hash Perturbation)

HashMap 并不直接使用 Object 的 hashCode()，而是进行了一次“扰动”。

JDK 1.8 源码片段：

static final int hash(Object key) {
    int h;
    // 将高 16 位与低 16 位进行异或运算
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

• 目的：数组长度通常较小（如 16），计算下标时主要利用低位信息。如果哈希值的高位变化很大但低位不变，会发生大量冲突。
• 原理：通过 (h >>> 16) 将高位特征“混合”进低位，增加了随机性，显著减少了哈希冲突。

3.2 下标计算与 2 的幂次

HashMap 计算元素在数组中位置的公式并非取模 %，而是位运算：

$$Index=(n-1)\&hash$$

其中 $n$ 是数组长度。

• 前提：数组长度必须是 2 的幂次（16, 32, 64…）。
• 原因：
  1. 性能：位运算 & 比取模运算 % 快得多。
  2. 数学特性：当 $n$ 为 2 的幂次时，$(n-1)\&hash$ 等价于 $hash\%n$。
  3. 分布均匀：$(n-1)$ 的二进制形式全为 1（如 15 是 1111），这保证了 hash 值的每一位都能参与运算，最大程度利用哈希值的随机性。

---

4. 扩容机制 (Resize)

当 HashMap 中的元素个数超过 容量 * 负载因子（默认 16 * 0.75 = 12）时，就会触发扩容。

JDK 1.7 的扩容

需要重新计算每个元素在旧数组中的哈希值，然后重新取模放到新数组中（Rehash），开销巨大。

JDK 1.8 的优化

由于数组长度总是 2 的幂次扩容（变为原来的 2 倍），元素的新位置只有两种可能：

1. 原索引位置
2. 原索引 + 旧数组长度

JDK 1.8 扩容逻辑图解：

假设旧数组长度 $n=16$，扩容后 $n=32$。
判断条件是看 hash 值在新增的那个 bit 位是 0 还是 1。

• 优势：省去了重新计算 Hash 值的开销，只需要判断一位二进制即可，效率大幅提升。

---

5. 总结：JDK 1.7 vs 1.8 对比表

特性	JDK 1.7	JDK 1.8
底层结构	数组 + 链表	数组 + 链表 + 红黑树
插入方式	头插法 (并发扩容可能死循环)	尾插法 (解决死循环问题)
Hash 扰动	扰动处理更复杂 (4次位运算+5次异或)	简化 (1次位运算+1次异或)
扩容计算	全部重新 Rehash	原位置 或 原位置+旧容量 (位运算优化)
链表转树	无	链表长度 > 8 且 数组长度 > 64

扩展：为什么引入红黑树？

这是为了在极端情况下（如哈希冲突攻击或糟糕的哈希函数）提供保底性能。链表查询是 $O(n)$，红黑树是 $O(\log n)$。当数据量巨大时，这种差异是数量级的。

关于红黑树可以看这篇：https://blog.youkuaiyun.com/Tracycoder/article/details/156860281