跳到主要内容Java 8 ConcurrentHashMap 源码深度剖析 | 极客日志Javajava算法
Java 8 ConcurrentHashMap 源码深度剖析
深入剖析 Java 8 中 ConcurrentHashMap 的源码实现。针对 HashMap 在多线程下的线程安全问题，ConcurrentHashMap 放弃了 JDK 5 的分段锁，采用 CAS 结合 synchronized 进行细粒度锁控制。核心数据结构为 Node 数组加链表和红黑树，支持多线程并发扩容和读写。通过 volatile 保证可见性，CounterCell 减少计数竞争，TreeBin 管理红黑树并发。相比 Hashtable 和同步包装器，其在高并发场景下性能更优，是 Java 并发编程的首选 Map 实现。
接口猎人6 浏览 1. 引言：并发环境下的 HashMap 困境
HashMap 是 Java 中最常用的键值对容器，它在单线程环境下表现出色，但在多线程并发读写时却会引发严重问题。Java 官方文档明确指出，HashMap 不是线程安全的。多个线程同时写入，甚至一个线程写入而另一个线程读取，都可能导致数据不一致、死循环（JDK 7 的头插法导致的环形链表）、甚至直接抛出 ConcurrentModificationException。
为了在并发场景下使用 Map，早期的开发者通常采用两种方案：
- Hashtable：使用
synchronized 修饰所有公有方法，相当于给整个哈希表加上了一把大锁。虽然线程安全，但并发性能极差，所有线程串行访问。
- Collections.synchronizedMap：将传入的 Map 包装起来，同样使用 mutex 锁住所有操作，本质与 Hashtable 相同。
这两种方案在低并发下尚可接受，但在高并发场景下会成为系统的性能瓶颈。于是，Java 并发大师 Doug Lea 专门为并发环境设计了 ConcurrentHashMap，从 JDK 1.5 开始引入，并随着 JDK 版本迭代不断优化。JDK 8 中的 ConcurrentHashMap 是一次颠覆性的重写，放弃了分段锁，采用了更加精细的并发控制，其吞吐量远超 Hashtable，甚至在某些场景下优于 JDK 7 的版本。
本文将基于 OpenJDK 8 的源码，深入剖析 ConcurrentHashMap 的设计思想、数据结构、核心操作以及并发控制机制。通过阅读本文，你将理解为何 ConcurrentHashMap 是并发环境下的首选，以及它是如何做到高效且线程安全的。
2. ConcurrentHashMap 的前世今生
2.1 Java 5 分段锁设计
JDK 5 首次引入 ConcurrentHashMap，其核心思想是锁分段。内部维护一个 Segment 数组，每个 Segment 继承自 ReentrantLock，可以看作是一个小型的 HashMap。默认支持 16 个 Segment，因此最多允许 16 个线程并发写入（前提是写入的键分布在不同的 Segment 中）。读操作基本不需要加锁，因为 Segment 内部使用了 volatile 保证可见性。
这种设计在 JDK 5/6 时代已经相当优秀，并发度由 Segment 数量决定，空间上需要额外维护 Segment 对象。
2.2 Java 7 的优化
JDK 7 的 ConcurrentHashMap 延续了分段锁的思想，但对内部实现做了优化，例如引入了 HashEntry 的 volatile 变量，以及一些细小的改进。不过整体架构未变，依然存在以下问题：
- 即使并发度可以设置，但一旦初始化后无法动态调整 Segment 数量。
- 内存占用较高，每个 Segment 都有独立的锁，且 HashEntry 对象较多。
- 某些操作（如 size()）需要先尝试无锁累加，失败则锁住所有 Segment，代价较大。
2.3 Java 8 的革命性重构
JDK 8 的 ConcurrentHashMap 完全抛弃了 Segment 分段锁，转而使用一种更加精细的并发控制策略：
- 数据结构：采用 Node 数组 + 链表 + 红黑树，与 HashMap 1.8 结构一致。
- 并发控制：使用 CAS（Compare-And-Swap）操作和
synchronized 关键字。当操作一个桶（bucket）时，仅对该桶的头节点加锁，而不是锁住整个 Segment。
- 扩容：支持多线程并发扩容，将一个大任务拆分成多个小任务分配给不同线程。
- 计数：采用 CounterCell 机制，减少计数冲突。
这些改进使得 ConcurrentHashMap 在保持线程安全的同时，极大地提升了并发性能。下面我们将从数据结构开始，一步步剖析 JDK 8 ConcurrentHashMap 的实现细节。
3. 数据结构总览
3.1 Node 类与派生
ConcurrentHashMap 的存储单元是 Node 类，它继承了 Map.Entry<K,V>，并且其 val 和 next 字段都使用了 volatile 修饰，保证可见性。
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;
}
为了支持红黑树，ConcurrentHashMap 定义了 TreeNode 和 TreeBin：
TreeNode 继承自 Node，增加了树相关的指针（parent, left, right, prev）。TreeBin 并不存储实际的键值对，而是作为树的容器，持有根节点，并且负责加锁和解锁。它内部还维护了读写锁机制，用于协调树的并发操作。
此外，还有一个特殊的 ForwardingNode，在扩容时出现，它的 hash 值为 MOVED（-1），指向 nextTable，表示当前桶已经被迁移，遇到该节点的线程应协助迁移。
3.2 核心成员变量解析
ConcurrentHashMap 的核心成员变量如下：
transient volatile Node<K,V>[] table;
private transient volatile Node<K,V>[] nextTable;
private transient volatile long baseCount;
private transient volatile int sizeCtl;
private transient volatile int transferIndex;
private transient volatile CounterCell[] counterCells;
3.3 重要的控制标记：sizeCtl
sizeCtl 是 ConcurrentHashMap 中一个非常关键的 volatile 变量，它用于控制多种状态：
- 负数：代表正在进行初始化或扩容
-1：正在初始化-N：高 16 位存储扩容戳（resizeStamp），低 16 位表示参与扩容的线程数 + 1（例如，若有 2 个线程参与，则低 16 位为 3）
- 正数：
- 如果 table 未初始化，表示初始化容量大小
- 如果 table 已初始化，表示下一次触发扩容的阈值（
table.length * 0.75，类似负载因子）
了解这些成员变量后，我们才能深入理解后续的并发操作。
4. 初始化与懒加载
与 HashMap 类似，ConcurrentHashMap 也采用了懒加载策略，构造时并不会立即创建 table 数组，只有在首次插入元素时才进行初始化。
public ConcurrentHashMap(int initialCapacity) {
if (initialCapacity < 0) throw new IllegalArgumentException();
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ? MAXIMUM_CAPACITY : tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
this.sizeCtl = cap;
}
这里计算了一个容量 cap，赋值给 sizeCtl。注意，此时的 sizeCtl 是一个正数，表示下次初始化时的容量。
当第一次调用 put 时，会进入 initTable() 方法：
private final Node<K,V>[] initTable() {
Node<K,V>[] tab;
int sc;
while ((tab = table) == null || tab.length == 0) {
if ((sc = sizeCtl) < 0) Thread.yield();
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
if ((tab = table) == null || tab.length == 0) {
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = tab = nt;
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
核心逻辑：通过 CAS 竞争将 sizeCtl 设为 -1，成功则进行初始化，失败则让出 CPU 等待。这里保证了多线程环境下只有一个线程执行初始化。
5. put 方法的并发插入艺术
put 方法是 ConcurrentHashMap 中最复杂的操作之一，它需要处理各种并发场景：桶为空、桶不为空、正在扩容、树化等。我们一步步分析。
5.1 计算 hash 与寻址
public V put(K key, V value) {
return putVal(key, value, false);
}
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<K,V>(hash, key, value, null))) break;
}
}
}
tabAt 和 casTabAt 是封装了 Unsafe 的 volatile 读写和 CAS 操作，保证对数组元素的原子访问。
5.2 首次插入的空桶竞争
当定位到的桶为空时，直接使用 CAS 将新 Node 放入该位置。CAS 成功则插入完成，失败说明有其他线程同时插入同一个桶，则进入下一次循环重试。
5.3 正在扩容时的协助机制
如果桶不为空，则检查该桶第一个节点的 hash 值。如果 fh = f.hash 等于 MOVED（-1），说明当前桶正处于扩容迁移中，当前线程需要调用 helpTransfer 帮助迁移：
else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f);
这是 ConcurrentHashMap 支持多线程扩容的关键，每个遇到 ForwardingNode 的线程都会加入扩容大军，加速迁移。
5.4 桶内冲突的处理：链表与红黑树
如果桶既不为空也不处于迁移状态，则说明发生了 hash 冲突，需要向链表或红黑树中插入新节点。此时采用 synchronized 对桶的第一个节点 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<K,V>(hash, key, value, null);
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) treeifyBin(tab, i);
if (oldVal != null) return oldVal;
break;
}
}
- 加锁后需要再次检查头节点是否被改变（
tabAt(tab, i) == f），因为可能在加锁前其他线程已经修改了该桶。
- 链表节点 hash 值都是正数（大于 0），
TreeBin 的 hash 是 TREEBIN（-2），所以可以根据 hash 判断是链表还是树。
- 插入完成后，如果链表长度超过
TREEIFY_THRESHOLD（8），会调用 treeifyBin 尝试将链表转为红黑树。注意，treeifyBin 内部还会检查数组长度是否小于 MIN_TREEIFY_CAPACITY（64），如果小于，则会优先进行扩容，而不是树化。这是为了避免数组过小导致频繁树化。
5.5 树化阈值与链表退化
树化并不是一蹴而就的。treeifyBin 方法会先检查 table 长度，若小于 64，则尝试扩容，将数组扩大一倍，并重新散列元素，这样可能降低冲突。只有数组长度足够且链表长度超过 8 时，才会真正将链表转换为红黑树。
相反，当红黑树中的节点数减少到 UNTREEIFY_THRESHOLD（6）以下时，在扩容或删除操作中会将其退化为链表，以节省空间。
6. get 方法的无锁读
get 操作全程无锁，利用 volatile 的可见性保证读取到最新数据。这是 ConcurrentHashMap 读性能极高的原因。
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)
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;
}
- 根据 hash 定位到桶。
- 如果第一个节点就是要找的 key，直接返回 value。
- 如果第一个节点的 hash 小于 0，说明是
TreeBin 或 ForwardingNode，调用对应的 find 方法在树中查找或转发到 nextTable 查找。
- 否则，遍历链表查找。
由于 Node 的 val 和 next 都是 volatile 的，所以读线程能立即看到其他线程的写入。即使正在扩容，find 方法也会帮助在 nextTable 中查找，保证读操作不受扩容影响。
7. 扩容：多线程协同的艺术
扩容（resize）是 ConcurrentHashMap 中最复杂、最精彩的机制。它支持多线程并发迁移数据，将任务拆分成多个小任务分配给各个线程，从而加速扩容。
7.1 触发扩容的场景
- 添加元素后，如果元素个数（
size()）超过 sizeCtl 阈值，会调用 addCount 方法，并在其中判断是否需要扩容。
- 链表转树前，如果数组长度小于 64，会先尝试扩容（
tryPresize），而不是树化。
扩容的入口是 transfer 方法，它接收一个 tab（原数组）和 nextTab（新数组，首次扩容时创建）。
7.2 transfer 方法核心流程
transfer 方法非常长，但可以归纳为以下几个步骤：
- 计算每个线程应负责迁移的桶范围（步长 stride），默认是 16。步长计算公式：
stride = (NCPU > 1) ? (n >>> 3) / NCPU : n，且至少为 MIN_TRANSFER_STRIDE（16）。
- 初始化 nextTab（如果传入的 nextTab 为 null），大小为原数组的两倍。
- 设置
transferIndex 为原数组长度，表示下一个要迁移的桶索引（从后往前分配）。
- 进入循环，每个线程通过 CAS 抢占一段区间（例如从 transferIndex - stride 到 transferIndex - 1），然后迁移这段区间内的所有桶。
- 迁移每个桶时，根据桶中节点的类型分别处理：
- 如果桶为空，则放置一个 ForwardingNode。
- 如果是链表，将链表拆分为两部分（低位链和高位链），分别放入新数组的 i 和 i+n 位置。
- 如果是 TreeBin，同样拆分为低位和高位，并根据拆分后的节点数决定是否需要退化为链表。
- 迁移完一个桶后，将原数组对应位置设置为 ForwardingNode。
- 当所有桶迁移完毕，将 nextTab 赋值给 table，更新 sizeCtl 为新阈值，结束扩容。
7.3 如何分配任务
多线程协作的关键是 transferIndex 这个 volatile 变量。它指向下一个需要迁移的桶索引（从 n-1 到 0 递减）。每个线程进入 transfer 后，通过 CAS 将 transferIndex 减去 stride，获得自己负责的区间 [nextBound, nextIndex-1]。CAS 成功后，线程便迁移这个区间内的桶。当区间内所有桶都迁移完成后，线程再次尝试 CAS 获取下一个区间，直到 transferIndex <= 0，表示没有剩余桶了。
如果还有桶未被迁移，但当前线程分配不到任务（例如其他线程已经抢占完），线程会退出扩容，让其他线程继续。这种机制实现了任务的动态分配，避免了线程之间的竞争。
7.4 多线程如何协同
- 首次触发扩容的线程会创建 nextTab，然后开始迁移第一个区间。
- 后续其他线程在 put 操作中遇到 ForwardingNode 时，会调用
helpTransfer 方法加入扩容。helpTransfer 会检查 sizeCtl 中的扩容戳，确认当前正在进行的是同一批扩容，然后调用 transfer。
- 每个线程在迁移完自己负责的区间后，会再次尝试领取新区间，直到所有桶迁移完毕。
- 扩容结束后，最后一个退出扩容的线程负责将 nextTab 赋给 table，并重置 sizeCtl。
由于 sizeCtl 低 16 位记录了参与扩容的线程数（+1），当线程退出时，会通过 CAS 减少该计数。如果计数减少到初始值（即只有扩容发起者），则说明所有桶迁移完毕，可以结束扩容。
7.5 扩容时的读操作
- 如果读到的桶是 ForwardingNode，则会调用
ForwardingNode.find 方法，该方法在 nextTable 中继续查找。
- 如果读到的桶尚未迁移，直接读取原数组。
- 读操作不加锁，因此可能读到尚未迁移完成的数据，但由于迁移操作是先将链表复制到 nextTable，然后再在原数组设置 ForwardingNode，且设置 ForwardingNode 是通过 CAS 进行的，所以要么读到旧的节点，要么读到 ForwardingNode 并转发到新表，不会读到中间状态。
8. size 方法与计数
在并发环境中统计元素个数是一项挑战，因为需要保证一致性且不阻塞。ConcurrentHashMap 的 size() 方法返回的是一个近似值，不保证精确实时。
8.1 CounterCell 机制
为了避免多线程竞争同一个计数器，ConcurrentHashMap 借鉴了 LongAdder 的思想，采用 CounterCell 数组进行分段计数。每个 CounterCell 是一个简单的 volatile long 值，加上一个伪共享填充（通过 @sun.misc.Contended 避免 false sharing）。
@sun.misc.Contended
static final class CounterCell {
volatile long value;
CounterCell(long x) { value = x; }
}
8.2 累加与 baseCount
当没有竞争时，直接使用 CAS 更新 baseCount。如果 CAS 失败，则进入 fullAddCount，根据当前线程哈希选择对应的 CounterCell 进行累加，如果 CounterCell 为空则创建新 Cell，必要时还会扩容 CounterCell 数组。
8.3 近似计数的实现
size() 方法通过累加 baseCount 和所有 CounterCell 的值得到一个总数，然后返回。由于在累加过程中可能有其他线程修改计数，所以结果只是近似值。mappingCount() 方法返回 long 类型，更适用于可能超过 int 范围的情况。
这种分段计数大大减少了多线程下的竞争，提升了并发写入的性能。
9. 红黑树在 ConcurrentHashMap 中的实现
9.1 为何引入红黑树
当链表过长时，查找效率会从 O(1) 退化为 O(n)。红黑树作为平衡二叉搜索树，能够保证在最坏情况下 O(log n) 的查找性能。因此，当链表长度超过 8 且数组长度大于 64 时，ConcurrentHashMap 会将链表转换为红黑树。
9.2 TreeBin 与 TreeNode
TreeNode 继承自 Node，增加了 parent、left、right、prev 指针，用于构建红黑树。TreeBin 是树的容器，它持有根节点，并且内部维护了一个简单的读写锁机制，用于控制树的并发访问。TreeBin 的 hash 固定为 TREEBIN（-2）。
TreeBin 的读写锁并不是用 AQS 实现的，而是通过一个 volatile int waiter 和 synchronized 块实现的简化版：
- 写线程在修改树结构时需要加锁（通过 synchronized 锁定 TreeBin 实例）。
- 读线程不需要加锁，但如果检测到有写线程正在修改（通过
waiter 标志），则会帮助写线程完成部分操作后再读。
这种设计保证了树的并发安全，同时读操作不会阻塞写操作。
9.3 树化条件与过程
树化发生在 putVal 中当链表长度超过 8 时，调用 treeifyBin。该方法会检查 table 长度是否小于 64，若是则尝试扩容；否则，将指定桶的链表转换为红黑树：
private final void treeifyBin(Node<K,V>[] tab, int index) {
Node<K,V> b;
int n, sc;
if (tab != null) {
if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
tryPresize(n << 1);
else if ((b = tabAt(tab, index)) != null && b.hash >= 0) {
synchronized (b) {
if (tabAt(tab, index) == b) {
TreeNode<K,V> hd = null, tl = null;
for (Node<K,V> e = b; e != null; e = e.next) {
TreeNode<K,V> p = new TreeNode<K,V>(e.hash, e.key, e.val, null, null);
if ((p.prev = tl) == null) hd = p;
else tl.next = p;
tl = p;
}
setTabAt(tab, index, new TreeBin<K,V>(hd));
}
}
}
}
}
树化过程在锁住桶的头节点后进行，遍历链表，创建 TreeNode，最后用 TreeBin 包装根节点并放入桶中。
9.4 树上的并发操作
对红黑树的插入、删除、查找都需要考虑并发。TreeBin 提供以下关键方法：
find：查找节点。读操作，先尝试读锁，如果检测到写锁被占用，则可能遍历链表（TreeBin 内部保留了双向链表结构，方便无锁读）。putTreeVal：插入节点。写操作，使用 synchronized 锁定整个 TreeBin。removeTreeNode：删除节点，同样需要加锁。
由于树结构的修改需要全局锁，但读操作尽可能无锁，保证了在大多数情况下读操作的高性能。
10. 并发控制机制深度解析
ConcurrentHashMap 的线程安全不是通过单一的锁机制实现的，而是多种并发技术的综合运用：volatile、CAS、synchronized、Unsafe 等。
10.1 volatile 的内存语义
volatile 保证变量的可见性和有序性（禁止指令重排）。在 ConcurrentHashMap 中，table、nextTable、sizeCtl、baseCount 等关键变量都是 volatile 的。Node 的 val 和 next 也是 volatile，确保读线程能够看到写线程的最新修改。
10.2 CAS 的应用场景
CAS（Compare-And-Swap）是一种轻量级的原子操作，在 ConcurrentHashMap 中大量使用：
- 初始化 table 时，CAS 将 sizeCtl 从正数改为 -1。
- 插入空桶时，CAS 将 Node 放入数组。
- 扩容时，CAS 更新 transferIndex 分配任务。
- 更新 sizeCtl 的线程计数。
- 更新 baseCount 和 counterCells。
CAS 避免了重量级锁的开销，但在高竞争下可能多次自旋，不过由于通常冲突较小，整体性能依然很好。
10.3 synchronized 与细粒度锁
尽管 JDK 8 对 synchronized 进行了优化（偏向锁、轻量级锁），但在 ConcurrentHashMap 中，synchronized 仍然被用作锁住桶的头节点，保证对该桶内链表/树的独占访问。这种锁的粒度很细，仅锁定单个桶，因此多个线程操作不同桶时可以完全并发。
使用 synchronized 而不是 ReentrantLock 的原因：
- synchronized 在 JDK 8 中性能已经很好，甚至在某些场景下优于 ReentrantLock。
- 减少内存占用，不需要额外的锁对象。
- 与 CAS 配合，代码更简洁。
10.4 写屏障与可见性
volatile 变量的写操作会触发写屏障（StoreLoad Barrier），确保该线程对共享变量的修改立即刷新到主内存，并使其他线程的缓存行失效。ConcurrentHashMap 充分利用这一特性，例如在插入节点后，通过 setTabAt（内部使用 Unsafe.putObjectVolatile）将新节点放入数组，保证其他线程立即可见。
11. 与 Hashtable、同步包装器的对比
为了直观感受 ConcurrentHashMap 的性能优势，我们对比三种线程安全 Map 的实现：
- Hashtable：所有方法使用 synchronized 修饰，锁住整个 Hashtable 实例。并发度极低，任何时刻只有一个线程能读写。
- Collections.synchronizedMap：包装模式，使用 mutex 锁，同样锁住整个 Map。
- ConcurrentHashMap（JDK 8）：使用 CAS + synchronized 锁桶，并发度与桶数量成正比，且读操作基本无锁。
- 读操作：ConcurrentHashMap 无锁，吞吐量接近 HashMap；Hashtable 和同步包装器需要获取锁，性能下降。
- 写操作：ConcurrentHashMap 允许不同桶的写并发，Hashtable 和同步包装器串行写。
- 扩容：ConcurrentHashMap 支持多线程并发扩容，减少扩容暂停时间；其他两种扩容时完全锁住，无法访问。
因此，在并发场景下，ConcurrentHashMap 是唯一的选择。
12. 使用示例与最佳实践
12.1 基本用法
ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
map.put("key", 1);
map.putIfAbsent("key", 2);
Integer val = map.get("key");
map.forEach((k, v) -> System.out.println(k + ": " + v));
12.2 复合操作
由于 ConcurrentHashMap 是线程安全的，但复合操作（如'先检查后插入'）仍需要加锁，或者使用提供的原子方法：
if (!map.containsKey(key)) {
map.put(key, value);
}
map.putIfAbsent(key, value);
map.computeIfAbsent(key, k -> expensiveComputation(k));
ConcurrentHashMap 提供了丰富的原子性方法：compute、computeIfAbsent、computeIfPresent、merge 等，它们内部实现了原子的更新逻辑。
12.3 遍历
ConcurrentHashMap 的迭代器是弱一致性的，不会抛出 ConcurrentModificationException，且在迭代过程中可能反映或不反映某些修改。遍历时可以对原 map 进行修改，但不保证实时性。
13. 性能调优建议
- 初始容量：如果预估元素数量，可以在构造时指定初始容量，避免频繁扩容。例如
new ConcurrentHashMap<>(expectedSize)。
- 并发级别：JDK 8 中已没有并发级别参数，但可以通过桶的数量间接影响并发度。通常默认的 16 桶已经足够，但对于极高并发场景，适当增大桶数（通过初始容量）可以减少桶内冲突。
- 避免使用
size() 频繁调用：size() 需要累加 CounterCell，开销较大。如果是实时统计，可以考虑维护一个单独的计数器。
- 选择合适的数据结构：如果 key 是枚举类型或可预知，可使用 EnumMap 或普通 HashMap 加外部同步，但维护成本高。
14. Java 8 之后的演进
在 JDK 9+ 中，ConcurrentHashMap 又进行了一些优化，例如：
- JDK 9 引入
KeySetView 等视图类，改进了一些内部方法。
- JDK 11/17 对红黑树实现做了微调，修复了一些边界 bug。
- JDK 16 中可能引入了 C 语言重写的某些部分（如 Vector API），但对核心逻辑影响不大。
总体而言，JDK 8 的 ConcurrentHashMap 奠定了现代并发哈希表的基础，后续版本保持兼容并持续优化。
15. 总结
ConcurrentHashMap 是 Java 并发容器中的瑰宝，它充分体现了 Doug Lea 大师的并发编程智慧。从 JDK 5 的分段锁到 JDK 8 的 CAS + synchronized，设计思想始终围绕'降低锁竞争、提高并发度'。通过本文的源码分析，我们深入理解了：
- 数据结构：Node 数组 + 链表 + 红黑树。
- 并发控制：volatile 保证可见性，CAS 实现无锁更新，synchronized 锁定单个桶。
- 扩容机制：多线程协同迁移，利用 ForwardingNode 指导读写。
- 计数：分段计数（CounterCell）减少竞争。
- 红黑树：TreeBin 封装树操作并提供读写协调。
微信扫一扫，关注极客日志
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
相关免费在线工具
- Keycode 信息
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
- Escape 与 Native 编解码
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
- JavaScript / HTML 格式化
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
- JavaScript 压缩与混淆
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
- 加密/解密文本
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
- Base64 字符串编码/解码
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
