Java 虚拟线程实战：适用边界、线程池与迁移要点

虚拟线程让“一个请求一个线程”的阻塞式代码拥有更高并发承载能力。它降低的是线程等待 I/O 的成本，不会让 CPU 密集型任务自动变快，也不会消除数据库连接、下游限流和内存容量这些真实约束。

最适合什么场景

典型适用场景是大量任务在等待网络、数据库或文件 I/O，而且每个任务逻辑相对独立。原来为了控制平台线程数量而层层拆回调的代码，可以恢复为更易读的同步流程。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = requests.stream()
        .map(req -> executor.submit(() -> remoteCall(req)))
        .toList();

    for (var future : futures) {
        consume(future.get());
    }
}

不要把虚拟线程再放进固定大小线程池。虚拟线程本身就应该按任务创建；如果要保护下游资源，限制的是资源并发，而不是虚拟线程数量。

var permits = new Semaphore(50);

Result callDatabase(Request request) throws Exception {
    permits.acquire();
    try {
        return repository.query(request);
    } finally {
        permits.release();
    }
}

迁移时最容易忽略的边界

数据库连接池不会变大

一万个虚拟线程仍可能只争抢几十个数据库连接。没有超时和背压时，等待队列会把请求与上下文全部保留在内存中。连接池大小应依据数据库能力确定，并让等待有 Deadline。

CPU 密集任务仍受核心数约束

压缩、加密、大量 JSON 计算等任务不会因虚拟线程加速。此类任务应控制并发，必要时使用专门执行器，避免大量可运行线程争抢 CPU。

ThreadLocal 成本会被放大

为每个虚拟线程存放大对象会造成显著内存压力。检查日志上下文、ORM 会话、缓存和安全上下文是否使用 ThreadLocal，并确保及时清理。能用显式参数传递的状态，不要默认塞进线程局部变量。

Pinning 与长临界区

监控在 synchronized 或本地调用期间发生阻塞的情况。即使新版 JVM 持续改善 Pinning，长时间持锁执行 I/O 仍是糟糕设计。可以用 JFR 观察虚拟线程事件与阻塞位置。

稳妥迁移步骤

  1. 选择一个 I/O 密集、依赖边界清晰的接口。
  2. 补齐每个外部调用的超时、取消与并发上限。
  3. 用平台线程版本建立吞吐、P99、连接池等待和内存基线。
  4. 切换虚拟线程后做长时间压测，而不是只看峰值 QPS。
  5. 检查 ThreadLocal、锁竞争、下游拒绝率和故障恢复。
  6. 小流量灰度，并保留快速切回路径。

虚拟线程最大的收益通常是简化并发代码和降低等待成本。若迁移后只是把系统瓶颈从线程池转移到数据库连接池，说明资源治理还没有完成。

参考资料