Java 虚拟线程执行阻塞调用时的线程池边界

Java 虚拟线程的关键价值不是让单个任务跑得更快，而是让大量等待 I/O 的任务不必长期占住平台线程。实际设计时可以记住一句话：阻塞 I/O 交给每任务一个虚拟线程，CPU 密集计算交给有界的平台线程池，数据库连接数和下游并发量用独立的资源限额控制。

先按任务性质划出三条边界

虚拟线程适合“任务很多、每个任务大部分时间在等待”的场景。它不是吞吐量无限的开关：连接池只有 32 个连接时，同时启动 10 万个虚拟线程也不会把数据库变成 10 万并发。

阻塞调用用每任务一个虚拟线程承载

Executors.newVirtualThreadPerTaskExecutor() 的语义是每提交一个任务创建一个虚拟线程。它表达的是“线程跟随任务”，不是传统意义上的工作线程池；用固定大小的虚拟线程池反而会重新制造排队点。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

try (ExecutorService ioExecutor = Executors.newVirtualThreadPerTaskExecutor()) {
    // 阻塞等待只占用当前虚拟线程，I/O 等待期间不长期占住 carrier。
    Future result = ioExecutor.submit(() -> loadFromBlockingClient());
    String body = result.get(); // 这里示意等待任务完成，生产代码仍要设置业务超时。
    consume(body);
} catch (InterruptedException ex) {
    // 恢复中断标记，避免调用链丢失取消信号。
    Thread.currentThread().interrupt();
    throw new IllegalStateException("任务被中断", ex);
} catch (Exception ex) {
    // 将执行失败转换为当前业务层能够处理的异常。
    throw new IllegalStateException("阻塞调用失败", ex);
}

这里的重点不是把所有代码改成异步回调，而是保留直观的同步写法。任务结束后执行器用 try-with-resources 关闭，避免生命周期散落到全局。

把资源上限放在调用外，而不是池化虚拟线程

如果下游只允许 32 个并发请求，限制应贴近下游资源，而不是把虚拟线程数硬设为 32。Semaphore 可以让多余任务保持为可调度的等待状态，同时保留每个请求的同步控制流。

import java.util.concurrent.Semaphore;

Semaphore permits = new Semaphore(32);

String loadWithLimit() throws Exception {
    permits.acquire(); // 只保护下游配额，不把虚拟线程改造成固定大小线程池。
    try {
        return loadFromBlockingClient();
    } finally {
        permits.release(); // 无论成功、失败还是取消，都归还许可。
    }
}

同一层还要配置客户端连接池、超时和重试上限。Semaphore 只控制进入数量，不能替代连接池、熔断器或请求超时；许可数也应按下游承受能力和实际压测结果调整。

CPU 密集阶段保留有界平台线程池

虚拟线程解决的是等待造成的平台线程浪费，不会增加 CPU 核数。压缩、加密、解析大对象等长时间计算如果无限创建任务，仍然会造成竞争和排队。因此可以把 I/O 与计算拆成两个执行器：

int cores = Runtime.getRuntime().availableProcessors();
try (ExecutorService io = Executors.newVirtualThreadPerTaskExecutor();
     ExecutorService cpu = Executors.newFixedThreadPool(
         cores, Thread.ofPlatform().name("cpu-", 0).factory())) {
    // I/O 阶段允许大量等待，但外部连接仍由连接池或 Semaphore 限制。
    String body = io.submit(() -> loadFromBlockingClient()).get();
    // CPU 阶段使用平台线程池，把并行度绑定到机器处理能力。
    cpu.submit(() -> digest(body)).get();
}

排查时先看“等待在哪里”：外部连接耗尽应调连接池或许可数，CPU 队列增长应看平台线程池和任务粒度，虚拟线程被 pinning 才需要进一步查 native 或 foreign function 调用。JFR 的 jdk.VirtualThreadPinned 事件和 jcmd Thread.dump_to_file -format=text dump.txt 可作为观察入口。

常见问题

阻塞 I/O 还需要固定线程池吗？

通常不需要。优先使用每任务一个虚拟线程；只有遗留库、明确的隔离策略或特殊线程上下文要求时，才单独评估平台线程池。

虚拟线程数量很大，数据库连接也要同步放大吗？

不应该。虚拟线程数量和数据库连接数是两个维度，连接数应根据数据库容量、事务时间和压测结果设置。

什么时候应该改用平台线程池？

当任务主要消耗 CPU、需要有界队列或必须隔离某类阻塞风险时，使用有界平台线程池，并让拒绝策略成为可观测的背压信号。