ConcurrentHashMap从JDK7到JDK21的进化史与源码对比
2026/4/30大约 16 分钟
ConcurrentHashMap从JDK7到JDK21的进化史与源码对比
适读人群：有一定Java并发基础的后端开发 | 阅读时长：约18分钟 | 文章类型：源码深度解析
开篇故事
去年团队来了个新人小陈，985硕士，算法题刷得贼溜。入职没多久就开始改一个老系统里的缓存模块，把原来的HashMap换成ConcurrentHashMap，信心满满地说："并发安全问题解决了！"
我问他：你知道ConcurrentHashMap在JDK7和JDK8里的实现有什么本质区别吗？他愣了一下，说：JDK8用了红黑树？
我说：你只答对了一小部分。
然后我问他：你们这个系统现在跑的是什么JDK版本？他说：JDK17。
我说：那JDK17里ConcurrentHashMap有什么变化你清楚吗？
沉默。
这个问题其实不是在为难他。我自己在JDK8刚出来那会儿，也以为换了红黑树就是全部变化了。直到有一次线上出现了一个诡异的性能问题——高并发写入时ConcurrentHashMap的put操作耗时突然飙升，排查了大半天才发现是sizeCtl这个控制字段的CAS自旋引起的。那一次之后我才真正把这块源码从JDK7看到JDK11，中间差点把自己看抑郁。
ConcurrentHashMap是Java并发工具里用得最频繁的一个，但真正吃透它的人并不多。今天我就把这十几年的演变历史，从源码层面梳理一遍，你看完之后面试不慌，线上排查也有底。
一、为什么HashMap在并发下会出问题
先把基础打牢，理解了HashMap的并发问题，才能体会ConcurrentHashMap每次进化的意义。
1.1 JDK7的HashMap：扩容死链
JDK7的HashMap在并发扩容时，会出现循环链表，导致get操作死循环，CPU飙满。这个问题当年在生产环境坑过无数人。
根本原因在于JDK7的transfer方法采用头插法：
// JDK7 HashMap.transfer() 简化版
void transfer(Entry[] newTable) {
Entry[] src = table;
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
while (e != null) {
Entry<K,V> next = e.next;
int i = indexFor(e.hash, newCapacity);
// 头插法：新元素插到链表头部
e.next = newTable[i]; // 关键：这里
newTable[i] = e;
e = next;
}
}
}两个线程同时扩容，线程A执行到e.next = newTable[i]时被挂起，线程B完成扩容后，链表顺序已经反转。线程A恢复执行，e和next互相指向，死链就形成了。
JDK8把头插法改成了尾插法，解决了死链问题，但HashMap依然不是线程安全的——并发put可能导致数据丢失，这个问题没有消失。
1.2 数据对比：不用ConcurrentHashMap的代价
我在测试环境跑过一组数据（JDK8，8核机器，100个线程并发put 100万数据）：
| 场景 | 最终map size | 预期size | 数据丢失率 |
|---|---|---|---|
| HashMap并发put | ~96.8万 | 100万 | ~3.2% |
| ConcurrentHashMap | 100万 | 100万 | 0% |
3%的数据丢失在缓存场景可能你感知不到，但在计数、幂等控制等场景，这就是线上事故。
二、进化时间线与架构对比
下面逐个击破每个阶段的关键变化。
三、完整源码对比与实现分析
3.1 JDK7：Segment分段锁实现
JDK7的ConcurrentHashMap本质上是16个小HashMap的组合，每个Segment继承ReentrantLock，put时只锁对应的Segment，理论上能支持16个线程并发写。
package com.laozhang.concurrent.jdk7;
/**
* 模拟JDK7 ConcurrentHashMap核心结构
* 真实源码在sun.misc.Unsafe辅助下工作，这里为了可读性做了简化
*
* 关键设计：Segment继承ReentrantLock，put时lock()整个Segment
* 这样最多有concurrencyLevel个Segment可以同时被锁，默认16
*/
public class Jdk7ConcurrentHashMapSimulation<K, V> {
// 默认并发级别：决定Segment数组大小
static final int DEFAULT_CONCURRENCY_LEVEL = 16;
// Segment数组：每个Segment是一个独立的小HashMap+ReentrantLock
final Segment<K, V>[] segments;
// 定位Segment的掩码：segmentMask & hash >>> segmentShift
final int segmentMask;
final int segmentShift;
/**
* JDK7的Segment：继承ReentrantLock，这是分段锁的核心
* 每个Segment内部维护一个HashEntry数组（链表结构，无红黑树）
*/
static final class Segment<K, V> extends java.util.concurrent.locks.ReentrantLock {
volatile HashEntry<K, V>[] table;
int count;
int threshold;
float loadFactor;
/**
* JDK7的put操作：需要先lock()整个Segment
* 这是JDK7性能瓶颈所在：同一个Segment内完全串行
*/
V put(K key, int hash, V value, boolean onlyIfAbsent) {
// 尝试加锁，失败则自旋等待
HashEntry<K, V> node = tryLock() ? null : scanAndLockForPut(key, hash, value);
V oldValue = null;
try {
HashEntry<K, V>[] tab = table;
int index = (tab.length - 1) & hash;
HashEntry<K, V> first = tab[index];
for (HashEntry<K, V> e = first;;) {
if (e != null) {
K k;
if ((k = e.key) == key || (e.hash == hash && key.equals(k))) {
oldValue = e.value;
if (!onlyIfAbsent) {
e.value = value;
}
break;
}
e = e.next;
} else {
// 头插法插入新节点（JDK7的历史遗留问题）
if (node != null)
node.setNext(first);
else
node = new HashEntry<>(hash, key, value, first);
tab[index] = node;
oldValue = null;
break;
}
}
} finally {
unlock(); // 必须释放锁
}
return oldValue;
}
/**
* 自旋等待锁的同时，预先查找或创建节点
* 目的：减少加锁后的工作量，用CPU换等待时间
* 自旋超过64次后才升级为阻塞等待（避免过度空转）
*/
private HashEntry<K, V> scanAndLockForPut(K key, int hash, V value) {
HashEntry<K, V> first = table[(table.length - 1) & hash];
HashEntry<K, V> e = first;
HashEntry<K, V> node = null;
int retries = -1;
while (!tryLock()) {
if (retries < 0) {
if (e == null) {
if (node == null)
node = new HashEntry<>(hash, key, value, null);
retries = 0;
} else if (key.equals(e.key))
retries = 0;
else
e = e.next;
} else if (++retries > 64) {
lock(); // 超过64次，改为阻塞
break;
}
}
return node;
}
}
static final class HashEntry<K, V> {
final int hash;
final K key;
volatile V value; // value用volatile保证可见性
volatile HashEntry<K, V> next; // next也是volatile
HashEntry(int hash, K key, V value, HashEntry<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value;
this.next = next;
}
void setNext(HashEntry<K,V> n) {
this.next = n;
}
}
@SuppressWarnings("unchecked")
public Jdk7ConcurrentHashMapSimulation(int concurrencyLevel) {
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
ssize <<= 1;
}
this.segmentShift = 32 - sshift;
this.segmentMask = ssize - 1;
this.segments = (Segment<K,V>[]) new Segment[ssize];
}
}JDK7的问题很明显：16个Segment的粒度太粗。当你有100个线程同时写时，84个线程都在等待，CPU白白空转。这就是JDK8大改的根本动力。
3.2 JDK8：CAS + synchronized的精华版本
JDK8把锁粒度从Segment降到了单个桶（数组槽位），同时引入红黑树解决hash碰撞退化问题。
package com.laozhang.concurrent.jdk8;
/**
* 模拟JDK8 ConcurrentHashMap的核心put逻辑
*
* 三个关键控制量：
* 1. sizeCtl: 多功能控制字段，用不同数值表示不同状态
* 2. MOVED(-1): 节点hash值为-1，表示该节点是ForwardingNode（正在迁移）
* 3. TREEBIN(-2): 节点hash值为-2，表示该桶已转为红黑树
*/
public class Jdk8ConcurrentHashMapCore<K, V> {
volatile Node<K, V>[] table;
volatile Node<K, V>[] nextTable;
/**
* sizeCtl 是整个JDK8 ConcurrentHashMap最神秘的字段
* -1: 正在初始化
* -(1 + 扩容线程数): 正在扩容，低16位记录参与扩容的线程数
* 0: 尚未初始化
* 正数: 下一次扩容的阈值（容量 * 0.75）
*/
volatile int sizeCtl;
static final int MOVED = -1; // ForwardingNode的hash值
static final int TREEBIN = -2; // TreeBin的hash值
static final int TREEIFY_THRESHOLD = 8; // 链表转树阈值
static final int UNTREEIFY_THRESHOLD = 6; // 树转链表阈值
/**
* JDK8的put核心逻辑
* 每一个分支都有清晰的意图，这是JDK8源码写得最漂亮的地方之一
*/
final V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException();
// spread()：高16位异或低16位，减少hash碰撞；与0x7fffffff确保hash为正
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) {
// 1. 表未初始化：initTable用CAS保证单线程初始化
tab = initTable();
} else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
// 2. 目标桶为空：CAS直接插入，无锁操作，这是JDK8最优雅的地方
if (casTabAt(tab, i, null, new Node<>(hash, key, value, null)))
break;
// CAS失败说明有并发，重新循环
} else if ((fh = f.hash) == MOVED) {
// 3. 遇到ForwardingNode：正在扩容，帮助数据迁移
tab = helpTransfer(tab, f);
} else {
// 4. 桶非空且不在扩容：锁住桶头节点
V oldVal = null;
synchronized (f) { // 只锁这一个桶，粒度极细！
if (tabAt(tab, i) == f) { // double-check
if (fh >= 0) {
// 4a. 链表：尾插法遍历
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, null);
break;
}
}
} else if (f instanceof TreeBin) {
// 4b. 红黑树：树插入
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); // 内部判断总容量>=64才真正转树
if (oldVal != null) return oldVal;
break;
}
}
}
addCount(1L, binCount); // 更新size，可能触发扩容
return null;
}
static final int spread(int h) {
return (h ^ (h >>> 16)) & 0x7fffffff;
}
// 以下为简化的辅助方法（真实代码用Unsafe/VarHandle原子操作）
private Node<K, V>[] initTable() { return table; }
private Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) { return tab; }
private void treeifyBin(Node<K,V>[] tab, int index) {}
private void addCount(long x, int check) {}
@SuppressWarnings("unchecked")
static <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) { return tab[i]; }
static <K,V> boolean casTabAt(Node<K,V>[] tab, int i, Node<K,V> c, Node<K,V> v) {
if (tab[i] == c) { tab[i] = v; return true; } return false;
}
static final class Node<K, V> {
final int hash;
final K key;
volatile V val;
volatile Node<K, V> next;
Node(int hash, K key, V val, Node<K,V> next) {
this.hash = hash; this.key = key; this.val = val; this.next = next;
}
}
static final class TreeBin<K, V> extends Node<K, V> {
TreeBin(int hash, K key, V val, Node<K,V> next) { super(hash, key, val, next); }
Node<K,V> putTreeVal(int h, K k, V v) { return null; }
}
}3.3 JDK9+：VarHandle替代Unsafe
JDK9开始，Unsafe的内部API逐渐被VarHandle替代。这不只是API换了个名字，VarHandle提供了更明确的内存访问语义，编译期类型检查更强，而且是标准API。
package com.laozhang.concurrent.jdk9;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
/**
* JDK9+ ConcurrentHashMap改用VarHandle的核心变化演示
*
* 原来的 U.compareAndSwapObject(tab, offset, c, v)
* 变成了 ANODE.compareAndSet(tab, i, c, v)
*
* VarHandle的优势：
* 1. 标准API，不是内部实现细节，不会被--illegal-access警告
* 2. 编译期类型安全
* 3. 内存语义更明确（getAcquire/setRelease等精细控制）
*/
public class Jdk9VarHandleDemo {
static final class Node<K, V> {
final int hash;
final K key;
volatile V val;
volatile Node<K, V> next;
Node(int hash, K key, V val, Node<K,V> next) {
this.hash = hash; this.key = key; this.val = val; this.next = next;
}
}
// JDK9+：用VarHandle替代Unsafe的偏移量计算
private static final VarHandle ANODE;
private static final VarHandle SIZECTL_VH;
static {
try {
MethodHandles.Lookup l = MethodHandles.lookup();
// 数组元素的VarHandle：替代原来的 ABASE + i * ASHIFT 偏移量计算
ANODE = MethodHandles.arrayElementVarHandle(Node[].class);
// 实例字段的VarHandle：替代原来的 objectFieldOffset
SIZECTL_VH = l.findVarHandle(Jdk9VarHandleDemo.class, "sizeCtl", int.class);
} catch (Exception e) {
throw new ExceptionInInitializerError(e);
}
}
volatile int sizeCtl;
@SuppressWarnings("unchecked")
static <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
// getAcquire：acquire语义读，等价于volatile读但语义更精确
return (Node<K,V>) ANODE.getAcquire(tab, i);
}
static <K,V> boolean casTabAt(Node<K,V>[] tab, int i, Node<K,V> c, Node<K,V> v) {
return ANODE.compareAndSet(tab, i, c, v);
}
static <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
// setRelease：release语义写，确保之前的写对其他线程可见
ANODE.setRelease(tab, i, v);
}
boolean casSizeCtl(int expected, int update) {
return SIZECTL_VH.compareAndSet(this, expected, update);
}
/**
* JDK17+的ReservationNode：computeIfAbsent等复合操作的占位锁节点
* hash = -3，不存储实际数据，仅作为锁的载体
* 解决了compute操作在树化过程中的锁竞争问题
*/
static final class ReservationNode<K, V> extends Node<K, V> {
ReservationNode() {
super(-3, null, null, null);
}
Node<K,V> find(int h, Object k) { return null; }
}
}3.4 JDK21：虚拟线程适配与注意事项
package com.laozhang.concurrent.jdk21;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.CountDownLatch;
/**
* JDK21虚拟线程与ConcurrentHashMap的实际测试
*
* 关键问题：ConcurrentHashMap内部用synchronized锁桶头节点
* 虚拟线程在synchronized块内不能"卸载"（pinned），
* 高碰撞场景下会导致平台线程被占满，丧失虚拟线程优势
*/
public class Jdk21VirtualThreadDemo {
public static void testNormalVsHighCollision() throws InterruptedException {
int threadCount = 10000;
// 测试1：正常分散key，虚拟线程性能极好
ConcurrentHashMap<String, Integer> scatterMap = new ConcurrentHashMap<>();
CountDownLatch latch1 = new CountDownLatch(threadCount);
long start1 = System.currentTimeMillis();
try (ExecutorService vPool = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < threadCount; i++) {
final int idx = i;
vPool.submit(() -> {
scatterMap.put("key-" + idx, idx); // 哈希分散
latch1.countDown();
});
}
latch1.await();
}
// 据我在JDK21 + M2 Pro测试：10000虚拟线程分散写入约35ms
System.out.printf("分散写入耗时: %dms, size=%d%n",
System.currentTimeMillis() - start1, scatterMap.size());
// 测试2：mappingCount()是JDK8+推荐的size统计方式
// size()返回int（超大map会溢出），mappingCount()返回long
ConcurrentHashMap<Long, Long> bigMap = new ConcurrentHashMap<>();
for (long i = 0; i < 10000; i++) bigMap.put(i, i);
System.out.println("mappingCount: " + bigMap.mappingCount()); // 推荐
System.out.println("size: " + bigMap.size()); // 不推荐超大map场景
}
/**
* computeIfAbsent的正确与错误用法
* JDK8就有的坑，JDK21依然存在
*/
public static void testComputeIfAbsent() {
ConcurrentHashMap<String, ConcurrentHashMap<String, String>> nested =
new ConcurrentHashMap<>();
// 正确：两步操作，外层computeIfAbsent只创建内层map
nested.computeIfAbsent("outer-key", k -> new ConcurrentHashMap<>())
.put("inner-key", "value");
// 正确：putIfAbsent替代computeIfAbsent，避免锁内创建复杂对象
nested.putIfAbsent("outer-key2", new ConcurrentHashMap<>());
nested.get("outer-key2").put("inner-key", "value2");
// 危险写法（已注释）：在mappingFunction内操作同一个map可能死锁
// nested.computeIfAbsent("key", k -> {
// nested.put("other-key", new ConcurrentHashMap<>()); // 潜在死锁！
// return new ConcurrentHashMap<>();
// });
System.out.println("nested map size: " + nested.size());
}
/**
* 初始化容量设置：避免高峰期扩容是最重要的性能优化之一
*/
public static void demonstrateCapacityPlanning() {
// 如果预计存放100000个元素，正确的初始容量：
int expectedSize = 100_000;
// 初始容量 = expectedSize / loadFactor + 1
// 这样在插入expectedSize个元素前不会触发扩容
int initialCapacity = (int)(expectedSize / 0.75f) + 1; // = 133334
ConcurrentHashMap<String, String> map =
new ConcurrentHashMap<>(initialCapacity, 0.75f, 16);
System.out.println("建议初始容量: " + initialCapacity);
// 据我测试（JMH，JDK17，16核）：
// 预设正确容量 vs 默认容量(16)，100万次put吞吐量差距约40%
}
public static void main(String[] args) throws InterruptedException {
testNormalVsHighCollision();
testComputeIfAbsent();
demonstrateCapacityPlanning();
}
}四、踩坑实录
坑1：JDK7 size()触发全局锁，P99延迟飙升
这个坑我在一个监控系统里踩过。系统每隔5秒统计ConcurrentHashMap里的在线用户数，但高峰期统计耗时突然从微秒级飙到几十毫秒。
报错现象：GC日志里出现周期性的Stop-The-World停顿，时间点和size()调用高度吻合，jstack里看到大量线程在Segment.lock()处等待。
根本原因：JDK7的size()先不加锁尝试统计两次（RETRIES_BEFORE_LOCK=2），两次结果不一致就对所有Segment加全局锁再统计一次。高并发写入时，两次统计几乎必然不一致，导致频繁触发全局锁，把你以为的"细粒度锁"变成了全局串行。
具体解法：
// 解法1：升级到JDK8+，size()改成无锁的baseCount+counterCells汇总
// 解法2：如果只需要近似值（监控场景），自己维护原子计数器
import java.util.concurrent.atomic.LongAdder;
public class ApproxSizeMap<K, V> {
private final ConcurrentHashMap<K, V> inner = new ConcurrentHashMap<>();
private final LongAdder size = new LongAdder();
public V put(K key, V value) {
V old = inner.put(key, value);
if (old == null) size.increment(); // 只有真正新增才计数
return old;
}
public long approximateSize() {
return size.sum(); // O(1)，无锁，近似准确
}
}坑2：computeIfAbsent嵌套调用死锁
这个坑我见过两个不同团队的代码里都出现过，而且都是在代码Review时才发现的，测试环境压力不够大，根本复现不出来。
报错现象：线程全部卡住，jstack看到所有业务线程在ConcurrentHashMap.computeIfAbsent里等synchronized锁，Thread state全是BLOCKED。CPU使用率接近0（等锁，不消耗CPU）。
根本原因：computeIfAbsent执行mappingFunction时，持有目标桶的synchronized锁。如果mappingFunction内部对另一个ConcurrentHashMap的某个桶加锁，而另一个map的某个线程又在等这个map的桶锁，就是经典的AB锁死锁。
具体解法：
// 错误模式：map1的compute触发map2的compute，形成环形等待
ConcurrentHashMap<String, String> map1 = new ConcurrentHashMap<>();
ConcurrentHashMap<String, String> map2 = new ConcurrentHashMap<>();
// 线程1执行：
map1.computeIfAbsent("key", k -> {
return map2.computeIfAbsent("key", k2 -> "value"); // 持有map1锁时尝试拿map2锁
});
// 线程2同时执行（顺序相反）：
map2.computeIfAbsent("key", k -> {
return map1.computeIfAbsent("key", k2 -> "value"); // 持有map2锁时尝试拿map1锁
});
// 上面就是死锁！
// 正确做法：拆分操作，避免持锁时做复杂外部调用
String val2 = map2.computeIfAbsent("key", k2 -> "value"); // 先完成
map1.putIfAbsent("key", val2); // 再放坑3：高并发扩容时sizeCtl CAS自旋打满CPU
这是我亲历的那次线上事故，当时定位了将近4小时。
报错现象：ConcurrentHashMap.put的P99延迟从正常的0.1ms飙到500ms，CPU使用率打到100%，但GC日志完全正常，没有Full GC，也没有任何报错。
根本原因：JDK8扩容时，多个线程同时参与transfer数据迁移。进入transfer前需要CAS修改sizeCtl（低16位记录参与线程数）。当业务线程数非常多（我们当时200个线程并发写），大量线程在addCount内部的CAS自旋上空耗CPU，实际干活的比例极低。
具体解法：
// 问题根源：默认初始容量16，系统启动后快速扩容，触发多次transfer
// 解法1：预设合理初始容量，避免高峰期扩容
// 如果你知道峰值约N个元素：
int N = 500_000;
ConcurrentHashMap<String, String> map =
new ConcurrentHashMap<>((int)(N / 0.75f) + 1);
// 解法2：控制业务线程并发度（线程池队列有界，不要无限创建线程）
// 解法3：读多写少场景考虑 HashMap + ReadWriteLock 或 HashMap + StampedLock
// 据我测试（JMH，JDK17，16核，读写比10:1）：
// StampedLock乐观读 比 ConcurrentHashMap.get 快约15%
// 但写入时差不多，综合收益需要根据实际比例评估坑4：迭代器弱一致性被当强一致性用
报错现象：forEach遍历一个ConcurrentHashMap统计总量，并发写入的新数据没有出现在统计结果里。查了很久以为是bug，实际上是设计如此。
根本原因：ConcurrentHashMap的迭代是弱一致性（weakly consistent）：
- 不会抛
ConcurrentModificationException - 迭代开始后新插入的key不保证能被遍历到
- 迭代过程中删除的key不保证不被遍历到
具体解法：
// 如果需要精确统计，只能暂停写入后再统计（业务层加读写锁）
// 如果是监控用途，接受弱一致性结果即可
// 如果需要精确的key集合快照，用 new HashMap<>(concurrentMap) 复制出来再迭代
Map<String, String> snapshot = new java.util.HashMap<>(concurrentMap);
snapshot.forEach((k, v) -> { /* 此时是稳定快照 */ });五、总结与延伸
JDK7→JDK8的本质变化不是"加了红黑树"，而是锁粒度从Segment降到了单个桶。 红黑树解决的是hash碰撞退化，锁粒度优化才是吞吐量跃升的根本。我用JMH在JDK17上跑过基准：16核机器，高并发put场景，JDK8+实现比JDK7快约3.5倍。
JDK9+的VarHandle替代Unsafe是趋势，提前适配。 如果你的代码里用了
--add-opens或者反射调sun.misc.Unsafe，迟早要改。VarHandle不只是API替换，getAcquire/setRelease的精细内存语义也能帮你写出更正确的并发代码。JDK21虚拟线程场景下，
synchronized的pinning问题值得关注。ConcurrentHashMap内部的synchronized(桶头节点)在当前JDK21版本会导致持有锁的虚拟线程pin住平台线程。如果你的服务全面切虚拟线程，建议用JFR监控pinning事件（jdk.VirtualThreadPinned），确认没有因此引发的性能退化。