结论先行

给 Thread.ofVirtual() 换上虚拟线程的那一刻，你并没有换来「免费并发」——任何在同步块 / native 调用里做阻塞 I/O 的代码，都会把载体线程（carrier thread）钉死，最终把 ForkJoinPool.commonPool 打满，表现为 P50 好看、P99 爆炸。 JDK 21 的虚拟线程是「协程 + 阻塞语义」，不是「无限线程池」；synchronized 是它目前最大的兼容性坑。

一、现象：QPS 涨了 40%，P99 反而从 38ms 飙到 480ms

去年 Q4 我们把一个订单聚合服务从平台线程迁到虚拟线程：

• 技术栈：Spring Boot 3.2.4 + JDK 21.0.2 + Reactor Netty，单实例 8C16G，前置 4 副本
• 迁移方式：@Bean 里把 TaskExecutor 换成 Executors.newVirtualThreadPerTaskExecutor()，业务代码 0 改动
• 迁移前：3200 QPS，P50 6.8ms，P99 38ms
• 迁移后：4500 QPS（+40%），P50 4.2ms（更好），但 P99 从 38ms 飙到 480ms，每 10 分钟抖动一次，持续 8–15s

监控曲线很反直觉：CPU 只到 42%，堆内存平稳，GC 停顿 <5ms，下游 RPC 平均 RT 没变。看起来一切「正常」，但 P99 就是起不来。

二、根因：synchronized 里的阻塞 I/O 会 pin 住载体线程

虚拟线程的调度模型是：虚拟线程跑在少量载体线程上，遇到阻塞 I/O（socket、ReentrantLock、LockSupport.park）时，调度器把虚拟线程从载体上卸下来，让载体去跑别的虚拟线程。

但 JDK 21 有个已知限制：JVM 无法在 synchronized 临界区内安全地切换出载体线程（同步监视器与线程绑定），所以只要虚拟线程在 synchronized 块里做阻塞 I/O，载体线程就被「pin」住，直到阻塞结束。

我们的代码里有这么一段（历史遗留，来自一个连接池的借还逻辑）：

// 旧代码：synchronized 里做阻塞 I/O（TCP 探活 + 等待空闲连接）
public Connection borrow(long timeoutMs) {
    synchronized (pool) {
        while (idle.isEmpty()) {
            idle.await(timeoutMs, TimeUnit.MILLISECONDS); // 阻塞 I/O
            if (System.currentTimeMillis() - lastPing > 30_000) {
                pingAll(); // 内部还有 TCP 阻塞
            }
        }
        return idle.poll();
    }
}

高峰期 200+ 个虚拟线程同时进入这个 synchronized，每个都在里面阻塞 100–500ms，而载体线程只有 8 个（= CPU 核数）。8 个载体全被 pin 住，整个 ForkJoinPool.commonPool 的并发度瞬间跌到 1，后续所有虚拟线程全部排队——这就是 P99 每 10 分钟抖一次的原因（跟下游探活周期完全吻合）。

三、具体做法：三步定位 + 两步修复

1. 用 -Djdk.tracePinnedThreads=full 抓现场

JDK 21 自带诊断开关，启动参数加：

-Djdk.tracePinnedThreads=full

pin 发生时 JVM 会在 stderr 打印被 pin 的载体线程栈，形如：

Thread[#14, ...]: pinned for 312ms
  at com.acme.pool.Pool.borrow(Pool.java:87)   ← synchronized 入口
  at java.base/java.lang.Object.wait0(Native Method)

生产上更稳的做法是定时跑 jstack，统计 ForkJoinPool.commonPool-worker-* 线程的栈里有多少落在业务 synchronized 方法上。我们一次 jstack 抓到 8/8 个 worker 全部卡在 Pool.borrow，直接坐实。

2. 把 synchronized 换成 ReentrantLock

ReentrantLock 底层是 AQS + LockSupport.park，调度器可以安全地切换载体：

// 修复后：ReentrantLock + Condition
private final ReentrantLock lock = new ReentrantLock();
private final Condition notEmpty = lock.newCondition();

public Connection borrow(long timeoutMs) throws InterruptedException {
    lock.lock();
    try {
        long deadline = System.currentTimeMillis() + timeoutMs;
        while (idle.isEmpty()) {
            long waitMs = deadline - System.currentTimeMillis();
            if (waitMs <= 0) throw new TimeoutException("borrow timeout");
            if (!notEmpty.await(waitMs, TimeUnit.MILLISECONDS))
                throw new TimeoutException("borrow timeout");
        }
        return idle.poll();
    } finally {
        lock.unlock();
    }
}

3. 全局扫一遍 synchronized 与 native 调用

用 grep -rn "synchronized" src/ 把所有同步块过一遍，凡是「块内有 sleep / await / socket / JDBC / RPC」的，统一换 ReentrantLock。我们一共改了 7 处，其中 3 处在第三方库（一个老版本 Redis 客户端的 ConnectionPool），通过 shade 重命名包 + patch 解决。

四、踩过的坑与反直觉之处

1. synchronized 不是「慢」，是「毒」。平台线程时代它只是临界区竞争，虚拟线程时代它会把整个 commonPool 的并发度打到 1。同样是 500ms 的阻塞，平台线程只影响自己，虚拟线程影响所有正在跑的虚拟线程。
2. jstack 看到 RUNNABLE 不等于在干活。被 pin 的载体线程在栈里显示 RUNNABLE，但实际在做阻塞 I/O——别被线程状态骗了，要看栈顶是不是 Object.wait0 / SocketInputStream.socketRead。
3. -Xmx 对虚拟线程的影响比平台线程小得多。虚拟线程栈在堆外（每线程约 2–4KB），4GB 堆能扛住几十万并发虚拟线程，但载体线程数 = CPU 核数，这个上限不会因为 -Xmx 变大而改变。
4. ThreadLocal 在虚拟线程里是「每虚拟线程一份」，不是「每载体一份」。我们一个连接池用了 ThreadLocal<Connection>，迁移后内存从 40MB 涨到 900MB，最后改成 ScopedValue（JDK 21 preview）+ 显式传递才压回去。
5. -Djdk.tracePinnedThreads=full 有日志开销，生产常驻建议用 full 跑 1 小时抓现场就关掉，或只在灰度节点开。

五、结论与可复用清单

虚拟线程不是「把线程池调大」，是「换了一套调度模型」。 上线前必须回答三个问题：

• [ ] 业务代码里有没有 synchronized 块内做阻塞 I/O？（有 → 换 ReentrantLock）
• [ ] 第三方依赖里有没有 synchronized + 阻塞 I/O 的组合？（用 jstack + -Djdk.tracePinnedThreads=full 抓）
• [ ] ThreadLocal 的内存预算是否按「虚拟线程数 × 单份大小」重新算过？

可复用清单（贴在你自己的 checklist 里）：

| 项 | 命令 / 配置 | 说明 | |---|---|---| | pin 现场 | -Djdk.tracePinnedThreads=full | JDK 21+，stderr 输出 | | 线程栈 | jstack <pid> \| grep -A 20 "ForkJoinPool.commonPool" | 看 worker 是否落在业务同步块 | | 同步块扫描 | grep -rn "synchronized" src/ | 人工判断块内有无阻塞 I/O | | 替代方案 | ReentrantLock / synchronized → Lock | 虚拟线程安全 | | 线程局部 | ThreadLocal → ScopedValue | JDK 21 preview，JDK 22 GA | | 载体数 | 默认 = Runtime.availableProcessors() | 可用 -Djdk.tracePinnedThreads 间接验证 |

最后一句：虚拟线程上线前，把「有没有 synchronized 里的阻塞 I/O」当成发布 checklist 的第一项，比任何压测都便宜。