Java virtual thread定位 synchronized 导致的固定载体线程的实现方法

我第一次把 Java Virtual Threads 接到一个阻塞型服务时，最容易误判的不是锁竞争，而是看到 carrier 数量紧张就把所有 synchronized 都列为嫌疑。更稳的判断是：JDK 21–23 中，虚拟线程在 synchronized 里执行阻塞操作，确实可能把 carrier 固定住；JDK 24 已改变这类 monitor pinning，仍要重点检查 native 或 foreign function。定位时先看 JFR，再用栈追踪落到具体的 monitor 和阻塞调用。

官方资料：https://openjdk.org/jeps/444

Java 虚拟线程的 carrier 为什么会被固定

虚拟线程运行在平台线程之上，平台线程就是 carrier。遇到普通阻塞 I/O 时，虚拟线程通常可以卸载，carrier 继续承载别的任务；如果虚拟线程被 pinning，阻塞期间 carrier 也被占住，虚拟线程数量再多也不能自动弥补。

这里有一个容易忽略的细节：Java 代码里的 Thread.currentThread() 得到的是虚拟线程本身，不能靠它直接读取 carrier 的身份。所以“定位固定载体线程”更准确的做法，是定位让虚拟线程无法卸载的代码栈，而不是在业务代码里保存一个所谓 carrier ID。

用 JFR 和栈追踪把 pinning 落到代码行

先采集一段短 JFR 记录。下面的命令只负责观察，不改变应用锁策略：

# 记录一段低开销数据，PID 替换成目标 Java 进程
jcmd  JFR.start name=vt-pinning settings=profile duration=60s filename=vt-pinning.jfr

# 只打印与虚拟线程 pinning 相关的事件，便于按栈回到业务代码
jfr print --events jdk.VirtualThreadPinned vt-pinning.jfr

jdk.VirtualThreadPinned 是第一层证据：它说明虚拟线程在无法释放 carrier 的情况下发生了足够长的阻塞。不要只统计事件条数，还要看事件栈是否落在请求热路径，以及阻塞时长是否与吞吐下降同时出现。

在 JDK 21–23 的复现或灰度环境，可以再打开：

# full 会保留较完整的调用栈，并标出持有 monitor 的相关帧
java -Djdk.tracePinnedThreads=full -jar app.jar

看到 holding monitor 只说明当前栈持有监视器，不等于这把锁本身有 bug。继续向下找同一临界区里的网络读取、队列等待、文件操作或慢速外部调用，才能确认它是否把 carrier 一起拖住。

把阻塞操作移出 monitor，再决定是否换锁

我更愿意先缩小同步范围，而不是直接全局替换。下面的结构把共享状态更新和外部等待分开；示例中的接口名是说明用的占位符，关键是锁只保护内存状态：

import java.util.concurrent.locks.ReentrantLock;

final class ProfileCache {
    private final ReentrantLock lock = new ReentrantLock();
    private Profile snapshot;

    Profile getOrLoad(String id) throws IOException {
        Profile cached;
        lock.lock();
        try {
            // 只在锁内读取共享快照，不把网络等待放进临界区
            cached = snapshot;
        } finally {
            lock.unlock();
        }
        if (cached != null) return cached;

        // 这里可能阻塞，但已经不再持有上述锁
        Profile loaded = loadFromService(id);
        lock.lock();
        try {
            // 写回前重新取得锁，避免并发更新破坏共享状态
            snapshot = loaded;
            return loaded;
        } finally {
            // 无论写回是否抛错，都必须释放显式锁
            lock.unlock();
        }
    }
}

这个示例不自动解决重复加载、缓存淘汰或异常回滚，它只展示 pinning 诊断后的锁边界决策。若临界区只是几个字段的快速读写，保留 synchronized 往往更清楚；若锁内包含远程调用、数据库读取或不可控的队列等待，应该先拆分，再考虑 ReentrantLock 或其他专门的并发原语。

常见问题

JDK 24 还需要把 synchronized 全部改成 ReentrantLock 吗？

不需要。JDK 24 已针对 synchronized 导致的虚拟线程 pinning 做了改进；短小的内存临界区仍可使用 synchronized。native、foreign function 和真正的长等待仍应单独检查。

出现 jdk.VirtualThreadPinned 就一定是性能故障吗？

不一定。事件是定位线索，默认阈值是 20ms；还要结合调用路径、并发量、阻塞时长和吞吐变化判断是否值得改代码。

为什么看不到 carrier 的线程名？

carrier 是运行时调度细节，虚拟线程在不同时间可以挂载到不同平台线程。优先使用 JFR 事件和 pinned 栈定位阻塞点，不要依赖业务代码读取 carrier 身份。