Java 虚拟线程访问同步块时如何识别 pinning

线上把线程池换成虚拟线程后，吞吐没有预期提升，线程转储里还看到一批任务卡在同步代码附近，不能直接把原因归结为“用了 synchronized”。真正需要确认的是：虚拟线程在阻塞点是否仍挂在 carrier 上，以及阻塞是否足够频繁、足够持久。JDK 21 到 JDK 23 可以重点排查同步块内的阻塞；JDK 24 起 JEP 491 已改善 synchronized 的卸载行为，但 native 方法和 foreign function 仍可能造成 pinning。

为什么同步块里的阻塞会占住 carrier

虚拟线程通常运行在少量 carrier platform thread 上，遇到可卸载的阻塞 I/O 时会让出 carrier。JDK 21–23 中，如果阻塞发生在 synchronized 方法或块内，虚拟线程不能及时卸载，carrier 也会被一起占住；当这种路径大量出现时，其他虚拟线程就会排队。

先看三个条件是否同时成立：运行在线程是 virtual thread；阻塞点位于同步保护范围；阻塞持续时间和出现频率足以消耗 carrier。只看到锁竞争，或者只看到一个很短的同步内存操作，都不足以证明发生了有害 pinning。

先按 JDK 版本划定排查范围

版本差异会改变结论，排查前先执行 java -version 并记录运行时。JDK 21 文档仍把 synchronized 和 native/foreign 调用列为 pinning 场景；JDK 24 的发布说明则明确包含 JEP 491，使同步方法和同步语句中的虚拟线程更容易释放底层平台线程。

用 JFR 和 tracePinnedThreads 交叉确认

生产排障优先使用 JFR，因为它能把事件线程、carrier、阻塞操作和持续时间放在同一条记录里。默认情况下，jdk.VirtualThreadPinned 的阈值是 20 ms；这个阈值用于筛出可能有影响的事件，不是业务故障的绝对界线。

# 让 JVM 在退出时保存 JFR，便于复盘虚拟线程事件
java -XX:StartFlightRecording=dumponexit=true,filename=virtual-thread.jfr \\
  -jar app.jar

# 只打印 pinning 相关事件，避免把整份录制输出到终端
jfr print --events jdk.VirtualThreadPinned virtual-thread.jfr

重点看 eventThread 是否是 virtual、carrierThread 是否被明确记录、blockingOperation 是什么，以及 duration 是否反复超过业务可接受范围。若原因指向 monitor 竞争，要回到调用栈确认同步块内是否夹着网络、文件、队列或其他长等待。

JDK 21–23 还可以临时加启动参数获取更直接的堆栈：

# full 会显示较完整的持有 monitor 和调用栈信息
java -Djdk.tracePinnedThreads=full -jar app.jar

# short 适合先观察问题集中在哪些应用帧
java -Djdk.tracePinnedThreads=short -jar app.jar

什么时候换成 ReentrantLock

修复动作不是“全项目搜索 synchronized 并替换”。如果锁内只有更新内存对象、时间很短或只在启动阶段执行，保留 synchronized 通常更清楚。需要重点改造的是高频请求路径中，锁保护范围内又包含潜在长 I/O 的代码。

private final ReentrantLock lock = new ReentrantLock();

void refreshRemoteState() {
    lock.lock();
    try {
        // 远程调用可能长时间阻塞，使用显式锁让虚拟线程具备更好的卸载机会
        remoteClient.refresh();
        // 只在临界区内更新共享内存状态，避免扩大锁的持有范围
        this.state = State.READY;
    } finally {
        // 无论远程调用抛出什么异常，都必须释放锁
        lock.unlock();
    }
}

改完后不要只看平均耗时：重新抓取 JFR，比较 pinning 事件数量、持续时间和 carrier 利用情况；同时确认锁的公平性、超时和中断语义没有改变。JDK 24+ 仍应对 native 或 foreign function 路径保留这套检查。

相关问题

看到 jdk.VirtualThreadPinned 就一定要改代码吗？

不一定。它说明某次阻塞期间 carrier 没有释放，是否有害还要结合频率、持续时间和吞吐影响判断。

同步块里调用短暂的内存方法也会造成线上事故吗？

通常不会因为 pinning 本身造成事故。短小且不阻塞的临界区更应该保持简单，再用实际 JFR 和延迟指标决定是否调整。

为什么换成 ReentrantLock 后还可能看到 pinning？

如果调用栈进入 native 方法或 foreign function，仍可能固定 carrier；另外也要确认部署时真正使用的 JDK 版本和启动参数，而不是只看编译环境。

排查 pinning 的关键不是锁关键字，而是“虚拟线程在什么阻塞点、以什么原因、占住了哪个 carrier 多久”。先用 JFR 定位，再用堆栈确认，最后只改造有数据支持的长阻塞路径。