Java 虚拟线程 pinned同步块为什么让虚拟线程失去并发优势为什么结果为空或不符合预期

Java 虚拟线程出现 pinned，并不等于代码一定错误。真正需要排查的是：一个虚拟线程在 synchronized 同步块或同步方法里执行了较长的阻塞操作，导致它不能及时从载体线程卸载，载体线程也就不能马上承载其它虚拟线程。短小的内存临界区通常不用改；长时间、频繁的阻塞才会让并发优势明显下降。

这篇文章按“现象—证据—修复—反向验证”排查。先确认是 pinning 而非普通锁等待，再用 JFR 或启动参数定位调用栈，最后只改动高风险边界。

先区分 pinning 与普通锁等待

普通锁等待是线程在等待互斥锁；pinning 更具体：虚拟线程已经挂在载体线程上，遇到阻塞操作时不能卸载。最容易触发它的形态如下，示例只用于说明结构：

class UserCache {
    private final Object lock = new Object();

    String load(String key) {
        synchronized (lock) {
            // 共享状态与阻塞调用被放进同一个同步区间，容易形成 pinning。
            return remoteRead(key);
        }
    }

    private String remoteRead(String key) {
        // 这里代表网络、文件或数据库等可能阻塞的调用。
        return "value:" + key;
    }
}

如果同步块只做几个字段的读写，即使存在竞争，也不能直接叫 pinning。相反，远程调用、睡眠等待、文件读取等操作被包在同步区间中，才值得优先观察。图1是静态结构说明图，不是运行截图。

用 JFR 或启动参数收集证据

不要只因为吞吐下降就把所有 synchronized 替换掉。先采集证据。JDK Flight Recorder 提供 jdk.VirtualThreadPinned 事件，默认关注超过约 20ms 的 pinning；它可以帮助你看到阻塞操作、载体线程和调用栈。

# 启动时保存 JFR，退出时把记录写到 recording.jfr
java -XX:StartFlightRecording=dumponexit=true,filename=recording.jfr App

# 只打印虚拟线程 pinning 事件，定位阻塞位置
jfr print --events jdk.VirtualThreadPinned recording.jfr

需要快速看启动日志时，也可以使用诊断参数。它不改变锁语义，只把发生阻塞时的相关栈打印出来：

# full 显示完整栈；short 只显示更紧凑的关键帧
java -Djdk.tracePinnedThreads=full App

证据判断可以分三层：第一层看是否真的出现 jdk.VirtualThreadPinned；第二层看栈中是否存在同步监视器与阻塞调用；第三层看该位置是否高频、持续时间是否足以影响并发。只有三层都指向同一处，才进入修复。图1中的 JFR 事件是观测关系示意，不代表某次真实运行输出。

缩小同步区间并替换高风险锁

首选修复通常不是换锁，而是缩短同步区间：先在锁内读取或更新必要的共享状态，再把网络、磁盘或数据库操作移到锁外。如果业务确实需要在阻塞期间保持互斥，可以针对这一处考虑 ReentrantLock，并保证异常路径释放锁。

class UserCache {
    private final ReentrantLock lock = new ReentrantLock();
    private String cached;

    String load(String key) {
        String hit;
        lock.lock();
        try {
            // 临界区只读取共享缓存，尽量不在锁内做阻塞操作。
            hit = cached;
        } finally {
            // finally 保证异常或提前返回时也会释放锁。
            lock.unlock();
        }
        if (hit != null) {
            return hit;
        }
        // 把可能阻塞的远程读取放到互斥边界之外。
        return remoteRead(key);
    }

    private String remoteRead(String key) {
        // 这里只表达阻塞调用的位置，实际代码应处理超时和异常。
        return "value:" + key;
    }
}

这种改法需要重新检查竞态：多个虚拟线程可能同时发现缓存未命中，因此应根据业务补充单飞、版本号或结果回填策略。若同步块本身只保护短小的内存操作，则保留 synchronized 往往更简单。图2说明保护边界与阻塞释放边界，不是某个 IDE 或终端截图。

反向验证：确认修复有效且没有过度改造

修复后用相同的 JFR 事件或诊断参数复查同一业务路径，重点比较 pinning 位置是否消失、阻塞是否仍被锁包住，以及结果是否保持正确。不要把“没有看到事件”解释成所有并发问题都解决了，它只说明当前观测条件下没有捕捉到达到阈值的 pinning。

可以用下面的清单收尾：

• 同步块里是否存在网络、文件、数据库或长时间等待？
• JFR 或 jdk.tracePinnedThreads 是否指向同一调用栈？
• 阻塞是否高频且足够长，确实影响载体线程复用？
• 能否把共享状态读取与阻塞调用拆开？
• 使用 ReentrantLock 时是否在 finally 中解锁？
• 改动后是否重新检查缓存竞态、超时和异常路径？

常见问题

看到 synchronized 就必须换成 ReentrantLock 吗？

不需要。短小或低频的同步区间通常没有明显问题；先用证据确认是长时间、频繁的阻塞 pinning，再决定是否改造。

pinning 会让结果为空吗？

pinning 主要影响调度和可扩展性，不会凭空把返回值变成空。结果为空应继续检查超时、异常处理、缓存竞态和数据源响应，不能把所有现象归因于 pinning。

参考资料

本文技术边界参考 OpenJDK JEP 444：https://openjdk.org/jeps/444；虚拟线程观测与 pinning 说明参考 Oracle Java SE 21：https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html。