Java 虚拟线程阻塞 怎样处理

Java 虚拟线程出现 BLOCKED、等待很久或吞吐下降时，先不要把“阻塞”直接等同于“虚拟线程失效”。适合 I/O 等待的虚拟线程本来就可以暂停，让载体线程去承载其他任务；真正需要处理的是载体线程是否被固定、CPU 是否被打满，以及数据库连接或外部服务是否先到达上限。

官方资料：https://docs.oracle.com/en/java/javase/26/

排查顺序建议是：先确认 JDK 版本，再看线程转储和 JFR 事件，最后根据证据调整代码或下游并发上限。JDK 24 以后，synchronized 已不应再作为旧版本经验中的首要怀疑对象；native/foreign 调用、CPU 密集任务和资源池耗尽仍要单独处理。

先分清普通等待和载体线程固定

虚拟线程是 java.lang.Thread 的一种实现，通常由少量平台线程作为 carrier 承载。阻塞 I/O 或等待队列时，虚拟线程可以挂起，carrier 释放给其他虚拟线程；这类等待本身不一定是故障。相反，若虚拟线程在不能卸载的边界中进行阻塞，carrier 也会被占住，频繁发生才会损害吞吐。

第一步应取得包含虚拟线程的线程转储，而不是只看平台线程数量：

# 把 PID 换成目标 JVM，JSON 便于工具按线程状态和锁信息读取
jcmd  Thread.dump_to_file -format=json virtual-threads.json

# 只做现场采集，不把一次 BLOCKED 状态直接当成根因
jcmd  Thread.print

重点看三件事：虚拟线程卡在锁竞争、I/O 还是业务计算；对应的 carrier 是否长期忙碌；同一时间是否有连接池、文件描述符或远端限流在等待。BLOCKED 只说明当前线程等待进入监视器等状态，不能单独证明 carrier 被固定。

按 JDK 版本看 synchronized 是否是问题

在 JDK 21–23 的实现里，虚拟线程在 synchronized 内执行阻塞操作可能固定 carrier，官方当时建议只对频繁且可能持有长时间 I/O 的监视器考虑 ReentrantLock。但 JDK 24 引入 JEP 491 后，虚拟线程在同步方法和同步块中阻塞时可以释放底层平台线程，旧文章里的“看到 synchronized 就必须改锁”不再适用于 JDK 24+。

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

    String load(String key) throws InterruptedException {
        synchronized (lock) {
            // JDK 21–23：这里的长 I/O 可能固定 carrier；JDK 24+ 已改善该边界。
            return callRemoteService(key);
        }
    }

    private String callRemoteService(String key) throws InterruptedException {
        // 示例只表达可能阻塞的外部调用，不代表文章执行过该请求。
        Thread.sleep(20);
        return "value:" + key;
    }
}

迁移时先记录实际运行的 JDK，而不是只看编译器版本。JDK 21–23 仍可先缩小监视器范围：锁内只做内存状态变更，把外部 I/O 移到锁外，或在确有证据时改用显式锁并用 try/finally 释放。JDK 24+ 也不意味着锁竞争消失；多个任务争用同一个锁仍会排队，业务临界区过大仍会降低吞吐。

用 JFR 和线程转储找真正的阻塞点

JDK Flight Recorder 提供 jdk.VirtualThreadPinned 事件，用来观察虚拟线程在固定 carrier 时发生的停车；相关 JDK 文档说明该事件默认有阈值。它比凭经验搜索某个关键字更可靠：先看事件堆栈和持续时间，再回到对应调用点判断是 native/foreign、旧版本锁边界，还是资源等待。

# 退出时保存 JFR，文件名可按服务实例改名
java -XX:StartFlightRecording:filename=virtual-threads.jfr,dumponexit=true \
  -jar app.jar

# 只打印虚拟线程相关事件，避免把普通日志当成固定证据
jfr print --events jdk.VirtualThreadPinned,jdk.VirtualThreadSubmitFailed \
  virtual-threads.jfr

在 JDK 21–23 的迁移阶段，也可以临时使用 -Djdk.tracePinnedThreads=short 或 full 辅助定位；不要把诊断参数永久当成修复方案。若没有 pinned 事件，但请求仍慢，继续检查连接池等待、远端响应、锁竞争和 CPU 火焰图，虚拟线程并不会把慢的下游变快。

用 Semaphore 限制资源，不要池化虚拟线程

虚拟线程应该代表并发任务，而不是像平台线程一样被装进固定大小的工作池。真正需要限制的是数据库、第三方接口等有限资源，可以用 Semaphore 把“允许同时进入外部调用的数量”表达出来：

final class LimitedClient {
    private final Semaphore permits = new Semaphore(20);

    Result fetch(Request request) throws InterruptedException {
        permits.acquire(); // 只限制外部服务并发，不限制虚拟线程总数。
        try {
            return call(request);
        } finally {
            permits.release(); // 无论调用成功或失败都归还许可。
        }
    }

    private Result call(Request request) {
        // 这里代表可能等待网络的调用，具体客户端由应用选择。
        return new Result(request.id());
    }
}

如果数据库连接池只有 20 个连接，许可数应结合连接池和服务端配额决定，而不是照抄示例数字。虚拟线程数量很多时，还要控制请求体、响应缓存和超时；否则只是把压力从线程池转移到堆内存或下游。

native、foreign 和 CPU 密集任务要单独处理

JDK 24+ 已经消除了同步方法和同步块带来的大部分固定问题，但 native 方法或 Foreign Function and Memory API 仍可能让虚拟线程与 carrier 发生无法透明卸载的交互。涉及 JNI、FFM 或本地库时，优先查对应库是否支持虚拟线程，再用 JFR 和线程转储确认，不能仅凭 Java 层的 Thread.State 猜测。

另一个常见误区是把 CPU 密集循环交给无限多的虚拟线程。Oracle 的 API 说明把虚拟线程定位为等待 I/O 的任务，并明确它们不适合长时间 CPU 密集工作；这类任务应按 CPU 预算使用有限的平台线程或专门执行器。虚拟线程的价值是提高可承载的并发等待数，不是让单个计算更快。

最后按这份清单收口

• 记录运行时 JDK：21–23 与 24+ 的 synchronized 结论不能混用。
• 先用线程转储确认等待位置，再用 JFR 判断是否真的发生 pinned。
• 对数据库和远端服务使用 Semaphore、连接池和超时控制，不用固定池去“管理”虚拟线程。
• native/foreign 调用和 CPU 密集循环分别评估，必要时保留平台线程边界。
• 修复后关注吞吐、排队时间、下游资源占用和异常率，不只看虚拟线程数量。

两个容易混淆的问题

虚拟线程显示 BLOCKED 就一定是 carrier 被占满了吗？ 不一定。它可能只是等待锁，也可能是正常的资源等待；要结合线程转储、JFR 和 carrier 忙碌情况判断。

JDK 24+ 是否应该把所有 synchronized 改成 ReentrantLock？ 不应该。JEP 491 已改善同步代码中的 carrier 释放，但锁竞争和过大的临界区仍然是业务设计问题；只有证据显示锁本身造成排队时才考虑缩小临界区或调整同步策略。

相关官方资料可直接查看：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/Thread.html、https://docs.oracle.com/en/java/javase/24/migrate/significant-changes-jdk-24.html 和 https://openjdk.org/jeps/444。