Java 虚拟线程 pinned同步块为什么让虚拟线程失去并发优势怎样完成一个可复用的最小示例

Java 虚拟线程的价值是让大量以等待 I/O 为主的任务可以用直观的同步写法运行，但它不是“任何阻塞都自动变便宜”。在 JDK 21 及更早版本中，如果虚拟线程在 synchronized 持锁期间执行阻塞调用，虚拟线程可能被 pinned 在 carrier 平台线程上，carrier 也就不能及时去承载其他虚拟线程。

先记住一个判断：短小的内存临界区通常不值得为了理论上的 pinning 改写；真正需要处理的是“高频进入、持锁时间长、里面还有阻塞调用”的路径。JDK 24 通过 JEP 491 改变了普通 synchronized 阻塞时的实现，但 native/foreign 调用等剩余 pinning 风险仍应单独观察。

官方文档：https://docs.oracle.com/en/java/javase/24/core/virtual-threads.html

先把 pinned、虚拟线程和 carrier 分开

虚拟线程由 Java 运行时调度到少量 carrier 平台线程上。遇到普通阻塞 I/O 时，虚拟线程可以暂时卸载，让 carrier 去运行别的虚拟线程；这正是虚拟线程适合 I/O 密集型任务的原因。

问题出在早期 JDK 的特定组合：虚拟线程已经持有对象监视器，又在监视器范围内等待。它不能把自己和持有的执行状态安全地拆开，于是阻塞会连带占住 carrier。若这种路径很少发生，影响可能很小；如果同一个锁保护着频繁的网络、文件或数据库等待，就会把 carrier 逐渐变成隐藏的并发上限。

用最小示例看见同步块里的阻塞

下面的示例故意把等待放进 synchronized，用于理解 JDK 21 及更早版本的风险边界。它没有伪造吞吐量或运行输出，重点是锁的持有范围和阻塞位置。

import java.time.Duration;

public class PinnedVirtualThreadDemo {
    private static final Object LOCK = new Object();

    static void blockingTask(String name) {
        synchronized (LOCK) {
            // 这里同时持有监视器并等待，早期 JDK 中可能把 carrier 一起占住。
            System.out.println(name + " entered monitor");
            try {
                Thread.sleep(Duration.ofMillis(500));
            } catch (InterruptedException e) {
                // 恢复中断标记，让上层仍能感知取消请求。
                Thread.currentThread().interrupt();
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {
        // 每个任务都使用虚拟线程；示例只观察锁与等待的关系。
        Thread first = Thread.startVirtualThread(() -> blockingTask("first"));
        Thread second = Thread.startVirtualThread(() -> blockingTask("second"));
        first.join();
        second.join();
    }
}

运行时若使用 JDK 21，可以把 pinned 诊断开关放在启动命令中：

# JDK 21 及更早版本：输出发生 pinning 时的相关堆栈
java -Djdk.tracePinnedThreads=full PinnedVirtualThreadDemo

这个开关适合定位问题，不适合长期开在高流量生产环境中。真正的性能结论仍要结合阻塞时长、调用频率、carrier 数量和业务吞吐观察。

早期 JDK 怎样改写长阻塞临界区

第一选择通常不是把所有 synchronized 全部替换掉，而是把共享状态更新和外部等待拆开。能在锁内完成的内存操作先完成，网络、文件、数据库等待放到锁外；如果业务确实需要一个可中断、可观测的显式锁，再考虑 ReentrantLock。

import java.time.Duration;
import java.util.concurrent.locks.ReentrantLock;

final class SafeBlockingSection {
    private final ReentrantLock lock = new ReentrantLock();
    private int version;

    void updateWithBlockingCall() throws InterruptedException {
        int requestVersion;
        lock.lock();
        try {
            // 只在锁内读取并更新短小的共享状态，尽快释放互斥资源。
            requestVersion = ++version;
        } finally {
            // finally 保证异常路径也释放显式锁。
            lock.unlock();
        }

        // 外部等待移到锁外，避免把共享状态锁变成 I/O 队列。
        Thread.sleep(Duration.ofMillis(500));
        System.out.println("completed request version=" + requestVersion);
    }
}

这个改法保留了“状态更新互斥”的语义，却没有让外部等待覆盖整个临界区。要注意：如果业务要求“等待期间必须阻止其他线程观察状态”，就不能只按性能建议机械拆锁，而应重新设计状态机或使用更细粒度的锁。

JDK 24+ 为什么不能直接套用旧结论

Oracle 的 JDK 24 发布说明记录了 JEP 491：当虚拟线程在 synchronized 方法或语句中阻塞时，运行时可以释放底层平台线程给其他虚拟线程使用。也就是说，JDK 21 文章中“同步块必然让 carrier 被占住”的结论不能直接套到 JDK 24+。

但这不等于所有 pinning 都消失。当前文档仍提示 native 方法和 foreign function 会让虚拟线程 pinned；涉及 Object.wait、JNI、FFM 或第三方库的路径，也应该通过实际诊断确认。跨 JDK 版本维护库时，最好把“JDK 版本、阻塞类型、调用频率”作为三个独立维度记录。

用 JFR 和 jcmd 观察真正有影响的 pinning

不要因为代码里出现了 synchronized 就判定需要改造。可以先用 JDK Flight Recorder 记录，再按事件持续时间和调用频率筛选。

# 退出时写出 JFR 文件，文件名可按项目需要固定
java -XX:StartFlightRecording:dumponexit=true,filename=virtual-threads.jfr PinnedVirtualThreadDemo

# 只读取虚拟线程 pinned 事件，定位阻塞操作和堆栈
jfr print --events jdk.VirtualThreadPinned virtual-threads.jfr

# 需要线程快照时导出虚拟线程线程 dump
jcmd  Thread.dump_to_file -format=json virtual-threads.json

JFR 的 jdk.VirtualThreadPinned 事件默认用于捕捉超过阈值的 pinned 情况；分析时优先看是否反复出现在同一调用点、是否伴随长时间外部等待，以及 carrier 是否已经成为吞吐瓶颈。

最后用一张表决定是否改造

常见问题

虚拟线程里完全不能使用 synchronized 吗？

不是。短小、低频、只操作内存的临界区通常可以保留。需要关注的是持锁时间长并且发生阻塞的路径。

JDK 24+ 是否还需要 ReentrantLock？

如果只是为了规避早期 JDK 的 synchronized pinning，升级后应重新评估；如果需要可中断加锁、超时获取、条件队列或更清晰的锁生命周期，ReentrantLock 仍有独立价值。

为什么只看普通线程 dump 不够？

pinning 是虚拟线程与 carrier 调度关系上的问题，JFR 的 pinned 事件和带诊断参数的堆栈更容易把阻塞点、持锁点和调用来源联系起来。线程 dump 适合作为补充，而不是唯一依据。

结论：先确认运行时版本，再确认阻塞是否发生在锁或 native/foreign 边界，最后用 JFR 证明它是否高频且足够长。这样才能把 Java 虚拟线程的并发优势从“理论上很多线程”落实到真正可用的 carrier 调度上。