上周四下午三点。监控大盘上P99延迟从50 ms飙到5 s，持续了大约四十秒后自行恢复。看着屏幕，我先以为是上游挂了——查了一圈，上游依旧稳如老狗。老实说，随后翻到线程 dump。800多条虚拟线程全是TIMED_WAITING底层只有16个载体线程，全部被钉死。按理说，CPU 占用表面正常，但程序已经瘫痪。那一刻，我的脑海里只有一句话：完了上周灰度的虚拟线程出事了。

再看动机。一行配置的神话

我们是中等体量 ToB 服务，日均请求量约 800 万。技术栈为 Spring Boot + JDK21，标准 2024 新建项目。之前使用网站线程，Tomcat 线程池设为 200，一直跑得还行。年初技术评审时leader 提议试试 JDK21 虚拟线程在生产环境已有落地案例。

当时心动原因很简单——嫌网站线程调参太麻烦。每次大促前都要算 corePoolSize、maxPoolSize、队列容量，一旦算错就 OOM 或拒绝请求。虚拟线程的宣传语是“每个请求一个线程，不用池化”，听起来像从此不再洗碗。我查了一些资料，Spring Boot 2 开启虚拟线程只需一行：

spring:
threads:
virtual:
enabled: true

开启后Tomcat 请求处理、@Async 方法、@Scheduled 定时任务全部自动跑虚拟线程比网站线程快将近 8 倍；内存使用降了 72%，这不就是白捡性能吗？我当时真这么想，不过，

第一次翻车

灰度上线天就是我开头描述的场景。 我排查过程痛苦：常规 jstack、jmap 看来几乎没有线索——看到大量虚拟线程在等锁，而持有锁的几个虚拟线程又绑死在载体线上。

I stared at jstack for almost ten minutes. Unlike platform thread problems where pool/full queue is obvious,virtual threads behave differently: many virtual threads wait on a few carrier threads. My colleague suggested checking JFR events like jdk.VirtualThreadPinned. Installing it revealed ~15k pinning events per minute with average pin duration ~45 ms.

The culprit turned out to be synchronized. When a virtual thread enters a synchronized block or calls a native method it gets “pinned” on its carrier thread and cannot be unloaded. If synchronized block performs IO,carrier thread stalls along with it.

The default number of carrier threads equals CPU cores – our machine had 16 cores。so only 16 carrier threads existed. Once enough virtual threads were pinned,all subsequent requests queued up.

I wrote a quick script to scan all synchronized usages:

# Find all synchronized blocks sorted by call depth
grep -rn "synchronized" --include="*.java" src/main/java/ | \
grep -v "test" | wc -l
# Result: 247 occurrences

The list revealed around thirty cases involving IO operations inside synchronized blocks – a classic double disaster:

// Cache loading method – legacy code
public synchronized String getConfig {
if == null) {
// 💀 Database query inside synchronized!configCache.put);}
return configCache.get;}

This pattern was fine under platform threads – up to 200 concurrent threads could queue on lock without crashing. With virtual threads each request pins one carrier thread;after sixteen requests all carriers were exhausted.

The fix was simple: replace synchronized with an AQS-based lock such as ReentrantLock,which allows virtual threads waiting for lock to unload correctly.

private final ReentrantLock lock = new ReentrantLock;public String getConfig {
lock.lock;try {
if == null) {
configCache.put);}
return configCache.get;} finally {
lock.unlock;}
}

This addressed most obvious hotspot but re were many third‑party libraries using synchronized internally . Those couldn’t be changed directly.

A practical workaround was adding JVM flag -Djdk.tracePinnedThreads=short。which prints stack traces when pinning occurs – helping us spot problematic spots quickly.

说到第二次翻车，ThreadLocal 的复仇

昨天早上收到 GC 告警：老年代内存继续增长，从每天一次 Full GC 升至每三小时一次。最初怀疑新加缓存未过期或慢查询导致结果集堆积，却越排越迷糊。

"你检查过 ThreadLocal 吗？说起来，虚拟线程创建那么多。每个都带一份 ThreadLocalMap，如果泄漏会爆炸！"

• Synchronized 与 I/O:
  • If you have multiple I/O operations in a synchronized block that runs frequently under high concurrency,you might want to consider refactoring those into separate methods or using non-blocking I/O patterns. This reduces contention on shared locks.
• Pinned Threads Monitoring:

• If you see frequent “pinning” events in your JFR logs,it’s a sign that some part of your application is holding onto CPU-bound resources too long. Address se before enabling production usage.