Java 虚拟线程适合替代哪些阻塞式任务编排

Java 虚拟线程适合替代的，主要是“每个任务都要等待一段时间”的阻塞式编排：HTTP 请求、JDBC 查询、文件读写和消息队列消费都可以保持同步写法，却让等待中的任务不长期占住平台线程。它不适合把 CPU 密集型循环变成更多并行计算，也不会自动扩大数据库连接池或下游服务配额。

判断标准可以压缩成一句话：如果任务的大部分生命周期在等待 I/O，且任务之间相对独立，就优先考虑一任务一虚拟线程；如果瓶颈是 CPU、共享锁或有限连接数，就先解决对应资源边界。

先看阻塞类型：虚拟线程解决的是 I/O 等待

平台线程与操作系统线程绑定，数量通常受栈空间和调度成本限制。虚拟线程由 Java 运行时调度到少量 carrier 平台线程上；当 Java 网络 API 等阻塞操作等待数据时，虚拟线程可以暂时让出 carrier，其他任务继续运行。这样适合“请求多、单次计算短、等待时间长”的服务。

相反，图像编码、压缩、复杂规则计算等任务如果一直占用 CPU，增加虚拟线程只会让更多任务竞争有限的处理器时间。JEP 444 也把数据并行留给 Stream 等专门抽象；这里的选择重点是等待模型，而不是“虚拟”二字带来的性能想象。

把一个阻塞任务交给一条虚拟线程

Java 21 起可以使用 Executors.newVirtualThreadPerTaskExecutor()。它为提交的每个任务创建一条虚拟线程，关闭执行器时等待已提交任务结束。下面的例子模拟两个下游 I/O 调用，并用 Future.get() 收集结果，写法仍是直线式的同步代码。

import java.util.concurrent.*;
import java.time.Duration;

public class VirtualIoTasks {
    static String callService(String name) throws InterruptedException {
        // 模拟阻塞式 I/O；真实项目可替换为 JDBC 或 HTTP 客户端调用
        Thread.sleep(Duration.ofMillis(120));
        return name + "-ok";
    }

    public static void main(String[] args) throws Exception {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            Future profile = executor.submit(() -> callService("profile"));
            Future inventory = executor.submit(() -> callService("inventory"));
            // get 只等待任务结果，不把编排改成忙等
            System.out.println(profile.get() + "," + inventory.get());
        }
    }
}

这段代码的收益来自等待期间释放 carrier，而不是让单个任务获得更多 CPU。生产代码还应把超时、取消和异常传播接上；例如对下游调用设置明确超时，捕获 InterruptedException 后恢复中断标志，避免请求已经取消却继续占用资源。

虚拟线程不替代连接池和限流

虚拟线程可以同时存在很多条，但数据库连接、下游 HTTP 并发额度和文件句柄仍然是有限资源。最容易出现的误区是：把固定平台线程池改成虚拟线程后，直接向数据库提交数万条任务。任务本身变轻了，连接池等待和下游拒绝却可能同时放大。

应把“任务并发”和“资源并发”分开。下面用 Semaphore 保护一个最多允许 20 个并发访问的外部资源；虚拟线程负责承载等待，信号量负责表达真实容量。

var permits = new Semaphore(20);
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (var id : ids) {
        executor.submit(() -> {
            permits.acquire();
            try {
                // 资源边界：这里放 JDBC、HTTP 或文件操作
                return loadOne(id);
            } finally {
                // 无论成功、失败还是取消，都归还许可
                permits.release();
            }
        });
    }
}

平台线程、虚拟线程与任务编排怎么选

迁移时先观察等待占比、连接池使用率、下游拒绝数和 CPU 利用率，再决定是否扩大任务并发。不要用 ThreadLocal 保存昂贵资源来模拟旧平台线程池的复用方式；虚拟线程应该服务于单个任务，资源生命周期仍由连接池或显式作用域管理。

常见问题

虚拟线程是不是越多越好？

不是。它适合承载更多等待中的任务，但并发上限仍应由 CPU、连接池、下游配额和内存共同决定。

可以把虚拟线程放进固定线程池复用吗？

通常不需要。JDK 的设计是按任务创建虚拟线程；需要控制的是任务和外部资源，而不是复用虚拟线程本身。

平台线程还需要保留吗？

需要。CPU 密集型工作、少量长生命周期调度器以及需要明确绑定平台线程的场景，仍应使用平台线程或有界执行器。