Java 虚拟线程为什么会被锁固定到载体线程

在 JDK 21—23 的实现中，虚拟线程持有 synchronized 监视器并发生阻塞时，可能无法从载体线程卸载，这就是常说的固定。JDK 24 起已改进这类监视器固定问题，不能再把“用了 synchronized 就会固定”当作跨版本结论；native 方法和外部函数等场景仍需关注。

官方 Java 文档：https://docs.oracle.com/en/java/

面对一个使用虚拟线程却吞吐不佳的服务，我会先问运行时版本，再问阻塞栈在哪里。仅凭源码中出现锁关键字就安排全量替换，容易把版本差异、锁竞争和下游容量混在一起。下面表达的是方案取舍，示例不代表已执行压测。

我会先确认 JDK 版本，再判断锁的影响

虚拟线程需要挂载到平台线程上执行，这个平台线程称为载体。正常可卸载的阻塞会让载体腾出来执行其他任务；固定时，这种释放受限。频繁且持续较久的固定，才更容易影响并发扩展能力，而不是一出现固定就代表程序结果错误。

Oracle 的 JDK 21 文档列出了 synchronized 与 native/外部函数固定场景；JDK 24、25 文档的固定说明已不再把 synchronized 列为该场景。我会把旧版本排障建议与较新版本的运行行为分开，不把过去的改锁建议无条件延续。

把固定、串行化与下游限流分开

一把锁即使不固定载体，仍只能按互斥规则让任务进入临界区。升级运行时可以解决某类调度约束，但不会把一段串行代码自动变成并行代码。虚拟线程数量增加，也不会增加数据库连接数或外部服务的处理能力。

因此我会分别记录持锁时间、下游等待和固定事件。若大量请求等同一把业务锁，先考虑共享状态能否分区，或能否把不需要互斥的工作移出锁。若瓶颈是连接池，应先看池容量与下游限额，而不是简单增加载体线程。

把 I/O 移到锁外需要重新论证一致性。例如先读取版本、外部处理后再提交，可能需要检查期间共享状态是否变化。不能只为减少持锁时间而打破原有原子操作边界。

旧版本改锁时要保留原有语义

下面用等待演示旧版本需要关注的结构，等待并非真实业务 I/O。多个任务共享同一个锁对象时，持锁等待会阻止其他任务进入这一临界区。

final class SharedGate {
    private final Object monitor = new Object();

    void pauseInsideMonitor() throws InterruptedException {
        synchronized (monitor) {
            // 仅用等待表达长阻塞位置，不是推荐业务写法
            Thread.sleep(120);
        }
    }
}

若旧版本中已经定位到频繁长固定，并且确实需要互斥，可以评估 ReentrantLock。它改变的是同步实现方式，不会消除临界区的串行性质。我不会因为一段短小的内存操作使用 synchronized 就急于重写。

import java.util.concurrent.locks.ReentrantLock;

final class ExplicitGate {
    private final ReentrantLock gate = new ReentrantLock();

    void pauseInsideLock() throws InterruptedException {
        gate.lock();
        try {
            // 仍然持有互斥锁；是否应保留等待要由业务语义决定
            Thread.sleep(120);
        } finally {
            // 等待被中断或代码抛错时也必须释放锁
            gate.unlock();
        }
    }
}

如果还需要可中断获取锁、定时等待或公平性，应另外选择对应 API 并审查语义。将 synchronized 换成显式锁后，漏掉 finally 反而可能引入更严重的阻塞问题。

用与运行版本匹配的证据做决定

JFR 的 jdk.VirtualThreadPinned 事件可以帮助观察超过阈值的固定；默认阈值意味着没有事件不等于绝无短固定。记录时同时保存 JDK 发行商、完整版本、负载条件和关键调用栈，再判断变化是否来自升级、代码调整或下游波动。

# recording.jfr 为预先采集的记录；只展示事件读取方法
jfr print --events jdk.VirtualThreadPinned recording.jfr

我会选择相同请求范围比较吞吐、等待和失败情况，而不是只比较线程数量。没有固定事件但仍很慢时，继续查看锁竞争、CPU 和下游容量。这里没有给出虚构运行结果，也不保证某一种改法必然提升特定百分比。

synchronized 是否应该全部替换？

不应该。先区分运行版本、阻塞时长和调用频率，再评估同步语义。

换成 ReentrantLock 后请求一定并行吗？

不会。共享同一把互斥锁的临界区依然串行。

JDK 24 后是否再也没有固定？

不能这样理解。监视器相关改进不代表所有 native 或外部函数路径都可卸载。

旧版本行为：https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html

JDK 24 行为：https://docs.oracle.com/en/java/javase/24/core/virtual-threads.html

JDK 25 参考：https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html