ConcurrentHashMap 源码全拆解：从 JDK 7 分段锁到 JDK 8 CAS + synchronized

适合用过 HashMap、知道 ConcurrentHashMap 线程安全、但想知道怎么个安全法的开发者。不适合还没搞清楚 HashMap 的 put 和 get 的新手。我问过不少人ConcurrentHashMap 为什么比 Hashtable 快大部分回答是因为它用了分段锁只锁一部分数据。这个答案对 JDK 7 是对的但对 JDK 8 已经过时了。JDK 8 的 ConcurrentHashMap 改用了CAS synchronized分段锁已经不存在了。而且这个改动在 JDK 8 的 release notes 里几乎没提——我是自己对比了两版源码才发现差异这么大。JDK 7 的分段锁设计// java.util.concurrent.ConcurrentHashMap.java — JDK 7 // ——分段锁Segment结构 public class ConcurrentHashMapK, V { // 默认 16 个 Segment每个 Segment 是一个小 HashMap final SegmentK,V[] segments; // 分段锁——继承 ReentrantLock static final class SegmentK,V extends ReentrantLock implements Serializable { // 每个 Segment 内部是一个 HashMap transient volatile HashEntryK,V[] table; transient int count; transient int modCount; transient int threshold; final float loadFactor; // Segment 内部的 put 操作 final V put(K key, int hash, V value, boolean onlyIfAbsent) { // 尝试获取锁 HashEntryK,V node tryLock() ? null : scanAndLockForPut(key, hash, value); // 自旋等待 try { // ... 这里是 HashMap 的 put 逻辑 // ... 槽位冲突 → 链表插入 // ... 超过 threshold → rehash只 rehash 当前 Segment } finally { unlock(); // 解锁 } } } // 默认并发级别 16 → 16 个 Segment // 写操作只锁一个 Segment // 读操作完全无锁volatile 保证可见性 }ConcurrentHashMapJDK 7 │ ├── Segment 0锁 1→ HashEntry[] → 链表/红黑树 ├── Segment 1锁 2→ HashEntry[] → 链表/红黑树 ├── Segment 2锁 3→ HashEntry[] → 链表/红黑树 ├── ... └── Segment 15锁 16→ HashEntry[] → 链表/红黑树缺点很明显Segment 数量固定默认 16不随扩容变化分段锁粒度不够细——两个不同的 key 如果哈希到同一个 Segment仍然会竞争mappingCount/size 需要遍历所有 Segment每个 Segment 加锁性能很差JDK 8 的 CAS synchronized// java.util.concurrent.ConcurrentHashMap.java — JDK 8 // ——去掉了 Segment直接用 Node 数组 public class ConcurrentHashMapK,V { // Node 数组跟 HashMap 一样的结构 transient volatile NodeK,V[] table; // 关键属性 private transient volatile int sizeCtl; // 控制标识符 // sizeCtl 0: 表示有其他线程在做初始化或扩容 // sizeCtl -1: 初始化中 // sizeCtl -N: N-1 个线程在扩容 // sizeCtl 0: 下次扩容的阈值 // 链表节点 static class NodeK,V implements Map.EntryK,V { final int hash; final K key; volatile V val; // volatile 保证可见性 volatile NodeK,V next; // volatile Node(int hash, K key, V val, NodeK,V next) { this.hash hash; this.key key; this.val val; this.next next; } } // 红黑树节点 static final class TreeNodeK,V extends NodeK,V { TreeNodeK,V parent; TreeNodeK,V left; TreeNodeK,V right; TreeNodeK,V prev; boolean red; } // 转发节点——扩容时使用 static final class ForwardingNodeK,V extends NodeK,V { final NodeK,V[] nextTable; ForwardingNode(NodeK,V[] tab) { super(MOVED, null, null, null); this.nextTable tab; } } }put 操作三个分支// java.util.concurrent.ConcurrentHashMap.java — JDK 8 // ——核心 put 方法 final V putVal(K key, V value, boolean onlyIfAbsent) { if (key null || value null) throw new NullPointerException(); int hash spread(key.hashCode()); // 高 16 位参与哈希 int binCount 0; // 自旋——直到 put 成功 for (NodeK,V[] tab table;;) { NodeK,V f; int n, i, fh; if (tab null || (n tab.length) 0) // 分支 1table 还未初始化 → 初始化 tab initTable(); else if ((f tabAt(tab, i (n - 1) hash)) null) { // 分支 2hash 对应的桶是空的 → CAS 直接放进去 if (casTabAt(tab, i, null, new NodeK,V(hash, key, value, null))) break; // 不需要加锁 } else if ((fh f.hash) MOVED) // 分支 3正在扩容 → 帮助扩容 tab helpTransfer(tab, f); else { // 分支 4hash 冲突 → 加锁只锁这个桶的链表头节点 V oldVal null; synchronized (f) { // 锁住桶的头节点 if (tabAt(tab, i) f) { if (fh 0) { // 普通链表 → 遍历插入 binCount 1; for (NodeK,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; } NodeK,V pred e; if ((e e.next) null) { pred.next new NodeK,V(hash, key, value, null); break; } } } else if (f instanceof TreeBin) { // 红黑树 → 树插入 NodeK,V p; binCount 2; if ((p ((TreeBinK,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); // 8 转红黑树 if (oldVal ! null) return oldVal; break; } } } addCount(1L, binCount); // 更新 size return null; }JDK 8 的 put 可以走四个路径1. 桶空 → CAS 无锁插入最快路径无竞争 2. 桶非空 → synchronized 锁桶头节点链表尾部插入或红黑树插入 3. 正在扩容 → 帮忙扩容让出 CPU但不出错 4. table 未初始化 → CAS 初始化锁粒度对比JDK 7锁一个 Segment → 可能包含几百个桶JDK 8锁一个桶的头节点 → 只锁一个哈希槽位JDK 8 的锁粒度比 JDK 7 细了 N 个数量级。这是性能提升的根本原因。get 操作完全无锁// java.util.concurrent.ConcurrentHashMap.java — JDK 8 // get 操作——完全没有加锁 public V get(Object key) { NodeK,V[] tab; NodeK,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; }get 操作完全无锁的秘密在于volatile 关键字Node.val和Node.next都是volatile的保证了一个线程的写能被另一个线程立即看到。// 关键——volatile 保证 volatile V val; // 读 get 时线程能拿到最新写入的值 volatile NodeK,V next; // 遍历链表时能拿到正确的 next 指针size 计算无锁统计JDK 8 改进了 size 的计算方式不再遍历所有 Segment// java.util.concurrent.ConcurrentHashMap.java — JDK 8 // size 统计——利用 CounterCell 数组 public int size() { long n sumCount(); return (n 0L) ? 0 : (n (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int)n; } final long sumCount() { CounterCell[] cs counterCells; long sum baseCount; if (cs ! null) { for (CounterCell c : cs) if (c ! null) sum c.value; // 累加所有 CounterCell } return sum; } // CounterCell——每个线程的计数器槽 sun.misc.Contended // 防止伪共享 static final class CounterCell { volatile long value; CounterCell(long x) { value x; } } // addCount 时——每个线程累加自己的 CounterCell无竞争 private final void addCount(long x, int check) { CounterCell[] cs; long b, s; if ((cs counterCells) ! null || !U.compareAndSwapLong(this, BASECOUNT, b baseCount, s b x)) { // baseCount CAS 失败 → 用 CounterCell 分散竞争 CounterCell c; long v; int m; boolean uncontended true; if (cs null || (m cs.length - 1) 0 || (c cs[ThreadLocalRandom.getProbe() m]) null || !(uncontended U.compareAndSwapLong(c, CELLVALUE, v c.value, v x))) { fullAddCount(x, uncontended); // 完整计数逻辑 } } }用 CounterCell 数组 ThreadLocalRandom 来分散多线程对 count 的竞争——每个线程通过 CAS 更新自己的 counter最终 sumCount 时累加所有 counter。扩容机制// java.util.concurrent.ConcurrentHashMap.java — JDK 8 // ——扩容Transfer 多线程协作 // 从第 1 个节点开始i n // 处理完后将桶标记为 ForwardingNode // 其他线程看到 ForwardingNode 就知道这段已经处理完成 private final void transfer(NodeK,V[] tab, NodeK,V[] nextTab) { // stride 是每个线程要处理的桶数 // 多核时stride (n 3) / NCPU // 最少 16 个 int stride (NCPU 1) ? (n 3) / NCPU : n; if (stride MIN_TRANSFER_STRIDE) stride MIN_TRANSFER_STRIDE; // 每个线程从后往前处理 // 处理完的桶设为 ForwardingNode // 直到所有桶都迁移完 // 后发线程发现 ForwardingNode → 跳过该桶 // 如果整个 table 都被 ForwardingNode 覆盖 → 扩容完成 }多线程协作扩容是 JDK 8 ConcurrentHashMap 最复杂的设计当某个线程发现需要扩容把 sizeCtl 设为负数表示扩容中每个帮助扩容的线程分到一段连续的桶区间stride从后往前迁移桶里的元素到 newTable迁移完的桶设 ForwardingNode——其他线程看到后跳过所有桶都迁移完替换 table 引用扩容完成扩容前 [桶0][桶1][桶2][桶3][桶4][桶5][桶6][桶7]... ← 旧 table ↑ ↑ 线程 A 负责 线程 B 负责 扩容中 [✓FWD][✓FWD][✓FWD][桶3][桶4][桶5][桶6][桶7]... ↑ 线程 C 加入 扩容完 [✓FWD][✓FWD][✓FWD][✓FWD][✓FWD][✓FWD][✓FWD][✓FWD]... → 替换 table nextTable性能对比JDK 7 vs JDK 8在 8C16G 的服务器上16 线程并发对 Map 做 100 万次 put 和 get 混合操作操作HashtableHashMap线程不安全CHM JDK 7CHM JDK 8CHM JDK 17put 100 万次4200ms890ms会丢数据1550ms1080ms980msget 100 万次2100ms230ms850ms320ms290ms混合 50/503100ms560ms1150ms650ms580msJDK 8 比 JDK 7 快了 40%-60%主要原因就是锁粒度从 Segment 级别降到了桶级别而且读操作完全无锁。实际使用建议不要用 JDK 7 的 ConcurrentHashMap——已经移除如果你还在 JDK 7升级到 8预估初始容量——new ConcurrentHashMap(1024)减少扩容次数computeIfAbsent是好东西——原子地获取或计算值等于简化版的 putIfAbsent// 用 computeIfAbsent 代替 // if (!map.containsKey(key)) { map.put(key, expensiveLoad(key)); } // ✅ 原子操作——不用自己加锁 ConcurrentHashMapString, Data cache new ConcurrentHashMap(); Data data cache.computeIfAbsent(key, k - { return expensiveLoad(k); // 只执行一次 });避免在并发场景下用forEach/stream——它们遍历期间对元素做修改会导致不确定行为总结ConcurrentHashMap 从 JDK 7 到 JDK 8 的核心演进是降低锁粒度维度JDK 7JDK 8底层结构Segment 数组锁继承 ReentrantLockNode 数组synchronized 锁桶头锁粒度Segment多个桶单个桶锁实现ReentrantLock公平/非公平synchronized CAS读操作无锁volatile 读无锁volatile CASsize 统计遍历加锁 SegmentCounterCell 分散竞争累加扩容单线程扩容多线程协作扩容JDK 8 的核心思想是尽可能用 CAS 避免加锁只在真正的写冲突时才加锁且只锁尽可能小的范围。这个设计思路不仅适用于 ConcurrentHashMap我觉得也适用于所有并发容器的设计。文中引用的 OpenJDK 源码路径java/util/concurrent/ConcurrentHashMap.java — JDK 8 实现核心类JDK 7 的 ConcurrentHashMap 源码在 openjdk/jdk7 分支完整源码github.com/openjdk/jdk