虚拟线程避坑全解：Thread Pinning 问题定位与 3 种主流解决方案对比

一、Thread Pinning 到底是什么

触发 Pinning 的两个官方条件（JDK 21~23）

1. 虚拟线程正在执行 synchronized 块/方法内部发生阻塞 —— JVM 的 ObjectMonitor 绑定的是底层 OS 线程身份，unmount 会破坏 monitor 语义，所以禁止卸载。
2. 虚拟线程正在执行 native 方法 / JNI / FFM 外部函数​ 且内部阻塞 —— JVM 管不到 C 栈，无法冻结。

注：JDK 24 通过 JEP 491​ 重写了 monitor 实现，让大部分 synchronized + 阻塞 IO 场景不再 pin；但 native/JNI pinning 仍然存在，且大量团队还停在 JDK 21/22/23，所以本文结论对当前生产依然成立。

二、怎么定位 Pinning（生产可用手段）

1. JFR 事件（最推荐，线上常驻）

# 启动录制
java -XX:StartFlightRecording=filename=app.jfr,settings=profile -jar app.jar
# 或运行时开
jcmd <pid> JFR.start name=vt settings=profile
# 查看 pinning 事件与堆栈
jfr print --events jdk.VirtualThreadPinned app.jfr

2. 启动参数强行打印（排查期临时用）

-Djdk.tracePinnedThreads=full     # 打印完整栈，标出 monitor/native 帧
-Djdk.tracePinnedThreads=short    # 只打问题帧

3. jcmd 线程快照

jcmd <pid> Thread.dump_to_file -format=json vt.json

4. 辅助信号

• 载体线程池 ForkJoinPool-1-worker-* 全部 RUNNABLE 但实际在做网络等待
• jdk.VirtualThreadSubmitFailed 事件出现 → 载体耗尽前兆
• 吞吐上不去但 CPU 不高，carrier 数 ≈ 核数，排队 VT 数暴涨

三、3 种主流解决方案对比

方案 A：synchronized → ReentrantLock（治 Monitor Pinning）

// ❌ pinning：锁内做 IO
synchronized(cache){
    return db.query(id); // 载体被钉 500ms
}

// ✅ 可卸载
private final ReentrantLock lock = new ReentrantLock();
lock.lock();
try { return db.query(id); }
finally { lock.unlock(); }

方案 B：Native / 老 IO 卸载到独立平台线程池（治 Native Pinning）

static final ExecutorService OFFLOAD =
    Executors.newCachedThreadPool(); // 平台线程池

CompletableFuture.supplyAsync(() -> nativeBlockingCall(x), OFFLOAD);

方案 C：升级 JDK 24+（JEP 491 让 synchronized 不 pin）

四、三种方案怎么选（决策树）

1. JDK 21/22/23 + 自己代码里 synchronized 包 IO​ → 方案 A（ReentrantLock），收益最大
2. 卡在第三方 native/JNI/老驱动​ → 方案 B（卸载到平台线程池），短期必做
3. 新建服务 / 能控基线版本​ → 直接 JDK 24+（方案 C）+ 对 native 调用仍保留 B
4. synchronized 只在启动加载、低频纯内存​ → 不管它，别过度重构

五、几个容易踩的反模式

• 为了"统一"把所有 synchronized 无脑换 ReentrantLock——低频纯内存锁换了只增加复杂度
• 虚拟线程里套 Executors.newFixedThreadPool 当虚拟线程池——虚拟线程本就不该进池
• 以为开虚拟线程就能跑 CPU 密集循环——不阻塞就不 unmount，载体被占满
• 靠调大 jdk.virtualThreadScheduler.maxPoolSize 缓解 pinning——只是用更多 OS 线程掩盖病灶
• ThreadLocal 重对象缓存 + 虚拟线程——每个 VT 一份，内存炸；改用 ScopedValue（JDK 25+）或局部变量

小结