学习笔记08——ConcurrentHashMap实现原理及源码解析

1. 概述

为什么需要ConcurrentHashMap？

• 解决HashMap线程不安全问题：多线程put可能导致死循环（JDK7）、数据覆盖（JDK8）

• 优化HashTable性能：通过细粒度锁替代全局锁，提高并发度

对比表

特性	HashMap	HashTable	ConcurrentHashMap
线程安全	否	是	是
锁粒度	无锁	全局锁	分段锁/CAS+synchronized
并发性能	高	极低	高
Null键/值	允许	不允许	不允许

JDK版本差异

• JDK7：基于Segment分段锁（默认16段）

• JDK8+：数组+链表+红黑树，使用CAS + synchronized锁头节点

---

2. 线程安全实现机制

JDK8的锁优化

final V putVal(K key, V value, boolean onlyIfAbsent) {// ...for (Node<K,V>[] tab = table;;) {Node<K,V> f; int n, i, fh;if (tab == null || (n = tab.length) == 0)tab = initTable();else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {// CAS插入新节点（无锁）if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))break;}else if ((fh = f.hash) == MOVED)tab = helpTransfer(tab, f);else {synchronized (f) { // 锁住链表头节点// 处理链表/红黑树插入}}}// ...
}

• CAS：用于无竞争情况下的快速插入（如空桶）

• synchronized锁头节点：仅锁定当前哈希桶，不影响其他桶操作

---

3. 核心数据结构

Node节点结构

static class Node<K,V> implements Map.Entry<K,V> {final int hash;final K key;volatile V val;volatile Node<K,V> next;// ...
}

• volatile修饰：保证可见性，确保读线程能立即看到更新

• 红黑树节点：TreeNode继承Node，用于处理长链表（阈值=8）

扩容机制

• 触发条件：元素数量超过sizeCtl

• 多线程协助：通过ForwardingNode标记正在迁移的桶，其他线程可参与迁移

---

4. 关键源码解析

以下是对 ConcurrentHashMap 核心源码的深度解读，结合 JDK8 的实现进行分析：

---

4.1核心方法源码解析

1. 初始化：initTable()

private final Node<K,V>[] initTable() {Node<K,V>[] tab; int sc;while ((tab = table) == null || tab.length == 0) {// sizeCtl < 0 表示其他线程正在初始化if ((sc = sizeCtl) < 0)Thread.yield(); // 让出 CPU，等待初始化完成else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) { // CAS 抢锁try {// 双重检查，防止重复初始化if ((tab = table) == null || tab.length == 0) {int n = (sc > 0) ? sc : DEFAULT_CAPACITY;Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];table = tab = nt;sc = n - (n >>> 2); // 计算扩容阈值（0.75n）}} finally {sizeCtl = sc; // 释放锁，设置阈值}break;}}return tab;
}

• CAS 抢锁：通过 sizeCtl 标记初始化状态（-1 表示初始化中）。

• 双重检查：避免多线程重复初始化。

• 负载因子固定为 0.75：通过 sc = n - (n >>> 2) 实现。

---

2. put 方法：putVal()

final V putVal(K key, V value, boolean onlyIfAbsent) {if (key == null || value == null) throw new NullPointerException();int hash = spread(key.hashCode()); // 计算哈希（高位参与运算）int binCount = 0;for (Node<K,V>[] tab = table;;) {Node<K,V> f; int n, i, fh;if (tab == null || (n = tab.length) == 0)tab = initTable(); // 懒初始化else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 桶为空if (casTabAt(tab, i, null, new Node<>(hash, key, value))) // CAS 插入break;} else if ((fh = f.hash) == MOVED) // 正在扩容tab = helpTransfer(tab, f); // 协助扩容else {V oldVal = null;synchronized (f) { // 锁住头节点if (tabAt(tab, i) == f) { // 再次验证头节点未变if (fh >= 0) { // 链表节点binCount = 1;for (Node<K,V> e = f;; ++binCount) {K ek;if (e.hash == hash && ((ek = e.key) == key || (ek != null && key.equals(ek)))) {oldVal = e.val;if (!onlyIfAbsent)e.val = value; // 更新值break;}Node<K,V> pred = e;if ((e = e.next) == null) {pred.next = new Node<>(hash, key, value); // 追加到链表尾部break;}}} else if (f instanceof TreeBin) { // 红黑树节点Node<K,V> p;binCount = 2;if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key, value)) != null) {oldVal = p.val;if (!onlyIfAbsent)p.val = value;}}}}if (binCount != 0) {if (binCount >= TREEIFY_THRESHOLD) // 链表长度 >=8treeifyBin(tab, i); // 可能树化if (oldVal != null)return oldVal;break;}}}addCount(1L, binCount); // 更新元素计数return null;
}

关键逻辑：

1. 哈希计算：spread() 方法通过 (h ^ (h >>> 16)) & HASH_BITS 保证哈希值为正数。

2. CAS 插入空桶：若桶为空，直接通过 casTabAt 插入新节点（无锁优化）。

3. 锁头节点处理冲突：对非空桶使用 synchronized 锁定头节点，处理链表或红黑树。

4. 树化条件：链表长度 >=8 且数组长度 >=64 时树化，否则优先扩容。

5. 并发扩容协作：若发现桶正在迁移（MOVED 标记），当前线程会协助迁移。

---

3. 扩容机制：transfer()

private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {int n = tab.length, stride;// 计算每个线程处理的桶区间（最小 16）if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)stride = MIN_TRANSFER_STRIDE;if (nextTab == null) { // 初始化新数组try {Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];nextTab = nt;} catch (Throwable ex) { sizeCtl = Integer.MAX_VALUE; return; }nextTable = nextTab;transferIndex = n; // 迁移起点为旧数组末尾}// 多线程协同迁移逻辑ForwardingNode<K,V> fwd = new ForwardingNode<>(nextTab);boolean advance = true;boolean finishing = false;for (int i = 0, bound = 0;;) {Node<K,V> f; int fh;while (advance) {int nextIndex, nextBound;if (--i >= bound || finishing)advance = false;else if ((nextIndex = transferIndex) <= 0) {i = -1;advance = false;} else if (U.compareAndSwapInt(this, TRANSFERINDEX, nextIndex,nextBound = (nextIndex > stride ? nextIndex - stride : 0))) {bound = nextBound;i = nextIndex - 1;advance = false;}}// 实际迁移逻辑（略，处理链表/树拆分到新数组）}
}

核心设计：

1. 多线程任务分配：通过 transferIndex 全局指针分配迁移区间（类似“工作窃取”）。

2. ForwardingNode 占位符：迁移中的桶会被标记为 ForwardingNode，读请求会转发到新数组。

3. 链表拆分优化：根据哈希值的高位决定节点留在旧桶还是迁移到新桶（newIndex = oldIndex + oldCap）。

---

4. 无锁读：get()

public V get(Object key) {Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;int h = spread(key.hashCode());if ((tab = table) != null && (n = tab.length) > 0 &&(e = tabAt(tab, (n - 1) & h)) != null) {if ((eh = e.hash) == h) {if ((ek = e.key) == key || (ek != null && key.equals(ek)))return e.val; // 命中头节点} else if (eh < 0) // 特殊节点（红黑树或 ForwardingNode）return (p = e.find(h, key)) != null ? p.val : null;while ((e = e.next) != null) { // 遍历链表if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek))))return e.val;}}return null;
}

无锁保障：

• tabAt() 使用 Unsafe.getObjectVolatile 保证读取最新内存值。

• 链表遍历期间依赖 volatile 修饰的 next 指针保证可见性。

• 遇到 ForwardingNode 时自动跳转到新数组查询。

---

4.2.关键优化总结

优化点	实现方式
锁粒度	仅锁单个桶的头节点（JDK8），替代 JDK7 的分段锁
CAS 无锁插入	空桶通过 casTabAt 直接插入，避免锁竞争
多线程协作扩容	通过 ForwardingNode 和 transferIndex 分配任务区间
计数优化	使用 CounterCell[] 分散竞争，避免 size() 成为性能瓶颈
红黑树退化机制	当树节点 <=6 时退化为链表，避免频繁树化开销

---

4.3源码分析的思考题

1. 为什么在链表长度超过 8 时可能选择扩容而不是直接树化？

   • 数组较短时（<64），扩容能更有效减少哈希冲突。

2. 如何保证扩容期间读操作的正确性？

   • 通过 ForwardingNode 将读请求转发到新数组，写操作会等待迁移完成。

3. size() 方法为什么不是精确值？

   • 高并发场景下精确统计代价过高，采用分片计数（CounterCell）近似值。

---

5. 并发操作分析

扩容期间读写协调

• 读操作：遇到ForwardingNode时转到新表查询

• 写操作：协助迁移当前桶后再执行插入

线程协作扩容

private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {// 每个线程处理一个区间，完成后再领取新区间
}

• 通过stride步长划分任务区间

• 使用transferIndex指针协调多线程任务分配

---

6. 总结

设计亮点

• 锁分离：降低锁竞争概率

• 乐观锁优先：CAS无锁化尝试

• 粒度细化：从分段锁到桶级别锁

• 无锁读：volatile变量保证可见性

7.面试回答模板

面试官：请说一下ConcurrentHashMap的实现原理。 回答：

ConcurrentHashMap在JDK1.8中采用了数组+链表/红黑树的结构，通过CAS和synchronized实现高并发。

1. 写操作：如果桶为空，用CAS插入头节点；否则锁住头节点处理链表或红黑树。

2. 读操作：完全无锁，依赖volatile保证可见性。

3. 扩容：多线程协作迁移数据，通过ForwardingNode标记已处理的桶。

4. 线程安全：锁粒度细化到单个桶，结合CAS减少竞争。 对比HashTable，它的并发性能更高，且支持更高的并发度。

---

8.源码分析技巧

1. 关注核心方法：putVal、get、transfer（扩容）、helpTransfer。

2. 调试参数：通过-XX:+PrintConcurrentLocks观察锁竞争情况。

3. 结合JMM：分析volatile变量（如table、sizeCtl）的内存可见性保证。

9.常见面试题

以下是关于 Java ConcurrentHashMap 的常见面试题及其详细解答，涵盖底层实现、线程安全机制、性能优化等核心内容：

---

1. ConcurrentHashMap 如何实现线程安全？

回答要点：

• JDK7 的分段锁（Segment）： 将整个哈希表分成多个段（默认 16 段），每个段独立加锁，不同段的操作可以并发执行。

  • 优点：降低锁粒度，减少竞争。

  • 缺点：内存占用较高（每个段独立维护数组），并发度受段数限制。

• JDK8 的 CAS + synchronized 锁优化：

  • CAS 无锁插入：当桶为空时，直接通过 CAS 插入新节点，避免加锁。

  • synchronized 锁头节点：当桶非空时，仅锁住链表或红黑树的头节点，锁粒度细化到单个桶。

  • 扩容协作：多线程可以协同迁移数据，减少扩容时间。

---

2. ConcurrentHashMap 与 HashMap、HashTable 的区别？

特性	HashMap	HashTable	ConcurrentHashMap
线程安全	非线程安全	全局锁（方法级同步）	CAS + 细粒度锁（桶级别）
Null 键/值	允许	禁止	禁止
性能	高（无锁）	极低（全局锁）	高（并发优化）
迭代器一致性	快速失败	快速失败	弱一致性
实现机制	数组+链表+红黑树	数组+链表	数组+链表+红黑树（JDK8+）

---

3. JDK7 和 JDK8 的 ConcurrentHashMap 实现差异？

• JDK7：

  • 基于 分段锁（Segment），每个段类似一个独立的哈希表。

  • 默认 16 段，并发度固定，无法动态扩展。

  • 内存占用较高（每个段维护独立的数组）。

• JDK8：

  • 抛弃分段锁，采用 CAS + synchronized 锁头节点，锁粒度细化到单个桶。

  • 引入 红黑树，当链表长度 >=8 且数组长度 >=64 时树化，提升查询效率。

  • 内存利用率更高（共享一个数组），并发度动态扩展。

  • 支持 多线程协作扩容，迁移效率更高。

---

4. ConcurrentHashMap 的 put 方法流程？

1. 计算哈希：spread(key.hashCode())（保证哈希值为正数）。

2. 懒初始化：若数组为空，调用 initTable() 初始化。

3. 定位桶：(n-1) & hash 计算桶下标。

4. CAS 插入空桶：若桶为空，直接通过 CAS 插入新节点。

5. 处理哈希冲突：

   • 若桶正在迁移（ForwardingNode），当前线程协助迁移。

   • 非空桶锁住头节点，处理链表或红黑树的插入/更新。

6. 树化检查：链表长度 >=8 时可能触发树化。

7. 更新计数：调用 addCount() 更新元素总数（基于 CounterCell[] 分片计数）。

---

5. ConcurrentHashMap 的 size() 方法为什么不是完全精确的？

• 分片计数优化： 使用 CounterCell[] 数组分散计数更新，避免多线程竞争同一变量。

  • 当无竞争时，直接更新 baseCount。

  • 当检测到竞争时，使用 CounterCell 分片统计，最终结果为 baseCount + ∑CounterCell[i]。

• 设计权衡： 高并发场景下，精确统计需要全局锁，性能代价过高。size() 返回的是一个近似值，但实际开发中足够使用。

---

6. 如何保证 get() 操作的无锁和高性能？

• volatile 变量： 桶数组和节点的 val、next 字段用 volatile 修饰，保证可见性。

• 无锁读设计：

  • tabAt() 使用 Unsafe.getObjectVolatile 直接读取内存最新值。

  • 遍历链表或红黑树时不加锁，依赖 volatile 保证数据可见性。

• 扩容期间的读操作： 遇到 ForwardingNode 时，自动跳转到新数组查询数据。

---

7. ConcurrentHashMap 的扩容机制如何实现？

核心步骤：

1. 触发条件：元素数量超过 sizeCtl（扩容阈值 = 0.75 * 数组长度）。

2. 多线程协作：

   • 首个线程创建新数组（长度翻倍），并分配迁移任务区间。

   • 其他线程通过 transferIndex 领取迁移任务（步长 stride）。

3. 迁移逻辑：

   • 将旧数组的桶拆分为高低位链表，高位链表迁移到 旧下标 + 旧容量 的位置。

   • 迁移完成的桶用 ForwardingNode 占位，表示已处理。

4. 读写协调：

   • 读操作：遇到 ForwardingNode 时跳转到新数组查询。

   • 写操作：先协助迁移当前桶，再执行插入。

---

8. 链表何时会转为红黑树？何时会退化为链表？

• 树化条件：

  • 链表长度 >=8（TREEIFY_THRESHOLD）。

  • 数组长度 >=64（MIN_TREEIFY_CAPACITY），否则优先扩容。

• 退化条件：

  • 红黑树节点数 <=6（UNTREEIFY_THRESHOLD）时退化为链表。

• 设计目的： 平衡查询效率和空间占用，避免极端情况下的性能问题。

---

9. ConcurrentHashMap 为什么不允许 Null 键或 Null 值？

• 歧义性问题： get(key) 返回 null 时，无法区分是键不存在还是键对应的值为 null。

• 线程安全风险： 若允许 null，可能因并发操作导致隐式的 NullPointerException（如 containsKey(key) 和 get(key) 之间的竞争）。

• 设计一致性： ConcurrentHashMap 的设计目标是为并发场景提供明确的语义，禁止 null 可减少不确定性。

---

10. ConcurrentHashMap 的迭代器是强一致性还是弱一致性？

• 弱一致性： 迭代器在遍历时不会锁定整个哈希表，可能反映部分已完成的更新操作。

  • 迭代过程中可能看到新增、删除或修改的键值对，但不保证完全一致。

  • 设计目的是避免迭代期间阻塞其他线程，提升并发性能。

• 对比其他集合： HashMap 的迭代器是快速失败的（fail-fast），而 ConcurrentHashMap 的迭代器是安全的（fail-safe）。

---

11. 为什么 JDK8 改用 synchronized 而不是 ReentrantLock？

• 锁粒度细化： synchronized 在 JDK6 后进行了大量优化（如偏向锁、轻量级锁），性能与 ReentrantLock 接近。

• 内存消耗： ReentrantLock 需要额外维护 AQS 队列，内存开销更大。

• 代码简洁性： synchronized 语法更简洁，无需手动释放锁，减少编码错误。

---

12. ConcurrentHashMap 是否完全线程安全？

• 基本操作线程安全： put、get、remove 等单操作是原子的，线程安全。

• 组合操作非原子：

  if (!map.containsKey(key)) map.put(key, value); // 非原子操作

  此类组合操作需使用 putIfAbsent() 或外部同步。

• 迭代器弱一致性： 迭代期间可能看到其他线程的修改，但不会抛出 ConcurrentModificationException。

---

13. 如何理解 sizeCtl 字段的作用？

sizeCtl 是一个控制状态变量，具体含义：

• >0：表示下一次扩容的阈值（0.75 * 当前容量）。

• =0：默认初始状态。

• =-1：表示哈希表正在初始化。

• <-1：表示正在扩容，高 16 位表示扩容标识戳，低 16 位表示参与扩容的线程数 +1。

---

14. ConcurrentHashMap 的应用场景？

• 高并发缓存：如缓存用户会话信息、商品库存等。

• 实时统计：如多线程计数（需结合 addCount() 机制）。

• 替代 HashTable：所有需要线程安全哈希表的场景，性能更优。

• 分布式计算：如 MapReduce 任务中的局部结果聚合。

---

15. 如何设计一个线程安全的哈希表？

• 锁粒度优化： 从全局锁 → 分段锁 → 桶级别锁，逐步减少竞争。

• 无锁化尝试： 优先使用 CAS 处理无竞争场景（如空桶插入）。

• 并发扩容协作： 允许多线程协同迁移数据，提升扩容效率。

• 数据结构优化： 引入红黑树平衡查询效率，动态退化避免空间浪费。