Java Virtual Threads 怎样避免把阻塞任务放进固定池

Java Virtual Threads 处理大量阻塞 I/O 任务时，通常采用每任务一个虚拟线程，而不是建立固定数量的虚拟工作线程池。任务准入、数据库连接数和外部接口并发应分别限制，不能把“虚拟线程便宜”理解为“请求可以无限提交”。

官方地址：https://docs.oracle.com/en/java/

我先把任务数量与线程数量分开

在为“定时拉取一批远端数据”这类任务选执行器时，我会先问：固定池的大小是在保护 CPU，还是只是沿用了平台线程昂贵时的经验？如果任务的大部分时间在等 I/O，继续用少量工作线程串着等待，未必能发挥虚拟线程的优势。

我的取舍是保留直观的阻塞式业务代码，把线程创建交给 Executors.newVirtualThreadPerTaskExecutor()，再显式定义任务入口的容量。这里谈的是设计选择，没有声称在某条线上业务测得吞吐提升。

Executors 文档说明，这个工厂自 JDK 21 提供，为每个任务创建虚拟线程，创建数量没有内置上限；固定线程池则复用固定数量的线程并使用共享无界队列。即使用虚拟线程工厂创建固定池，也仍会保留那个人为的工作线程并发上限。

用提交窗口约束批任务准入

我更愿意先从有限批次迁移，而不是把无限请求源直接接到新执行器。下面的窗口最多保留 4 个已提交但还未消费结果的任务。每消费一个完成项，再补入后续任务；4 是示例值，应按负载与依赖容量调整。

代码使用 ExecutorCompletionService收集完成项，避免按提交顺序等待一个较慢任务，而忽略已经完成的结果。其完成队列语义见官方 API。

import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorCompletionService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class VirtualBatch {
    public static void main(String[] args) throws Exception {
        List> jobs = new ArrayList();
        for (int i = 0; i  {
                // 仅模拟可中断等待；实际业务替换成配置好超时的 I/O 调用。
                Thread.sleep(50);
                return "job-" + id + ", virtual="
                        + Thread.currentThread().isVirtual();
            });
        }

        int window = 4;
        Set> active = new HashSet();
        var pending = jobs.iterator();

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            var completed =
                    new ExecutorCompletionService(executor);
            try {
                while (pending.hasNext() || !active.isEmpty()) {
                    // 控制任务准入，不通过固定数量虚拟工作线程来限流。
                    while (pending.hasNext() && active.size()  done =
                            completed.poll(3, TimeUnit.SECONDS);
                    if (done == null) {
                        throw new TimeoutException("三秒内没有任务完成");
                    }
                    active.remove(done);
                    System.out.println(done.get()); // 任务异常由这里传播。
                }
            } finally {
                // 当前批次失败或中断时，请求其余任务协作取消。
                for (Future task : active) {
                    task.cancel(true);
                }
            }
        }
    }
}

# 在支持该 API 的 JDK 21 或更高版本下，以源文件模式运行。
java VirtualBatch.java

本文没有运行这段代码，也没有提供伪造的输出记录。读者运行后应关注两点：任务报告自己的虚拟线程身份，结果不保证按编号排序。窗口约束的是在途任务与未消费结果的数量；示例的输入 List 本身已经保存整批任务，不能因此宣称总内存与输入规模无关。

失败和超时也属于批任务协议

采用这种写法后，我最在意的变化是：原来由池大小隐含表达的容量，现在变成了能直接说明的入口策略。相应地，失败策略也必须写清楚。上例选择一项失败就结束当前批次，进入 finally 请求取消其余在途任务；如果业务要求收集全部成功与失败，应在完成项消费处记录异常并继续。

Future 文档区分等待、结果和取消。cancel(true)是请求中断，不是保证远端操作回滚；任务应使用可中断等待或客户端取消接口，并在自己的 finally 中释放资源。不能捕获中断后继续无限重试。

示例的 poll(3, TimeUnit.SECONDS)只表示这一轮等下一完成项最多三秒。如果其他任务不断完成，某个慢任务可能等待更久；它不是单任务截止时间，也不是整批总时限。真实 HTTP、JDBC 等操作仍需配置各自超时，整批截止时间要另外计算并传递。

ExecutorService 文档说明，关闭执行器会等待其终止。因此 try-with-resources 不等于“到时间立即返回”；不响应中断、没有底层超时的任务可能拖延收尾。关闭等待与任务取消应作为同一份生命周期设计。

我会按依赖容量决定是否采用

如果任务在等待网络响应，我会优先考虑每任务虚拟线程；如果大部分时间在做压缩或计算，我不会只换一个工厂就期待加速。Oracle 虚拟线程指南也强调，它面向大量等待型任务的扩展性，并不让计算本身更快。

当一个任务会访问多个下游时，入口窗口也未必能精确保护每个依赖。可为某个下游单独设置 Semaphore，只在访问该资源的范围内获取许可，并在 finally 释放。Semaphore API定义了许可的获取与释放。许可数量应来自依赖容量，不应机械照搬原线程池大小。

我会把是否采用落到同一组任务的完成率、入口等待、依赖超时、连接等待与收尾耗时上；条件和负载不一致时，不比较一个孤立的“线程数”。如果依赖已经饱和，首先减少压力或处理依赖瓶颈。

固定池以后都不能用了吗？

仍可用于合适的容量控制与 CPU 工作负载。这里建议调整的是用固定数量虚拟线程承接大量等待任务的设计，不是要求所有执行器统一替换。

把窗口调到很大就能提升吞吐吗？

只有依赖与系统还能承受时才可能有效。应逐步调整，同时观察错误率和尾延迟；入口必须有可解释的容量及超载处理。

可以把所有数据库连接放进 ThreadLocal 吗？

不建议将虚拟线程当作少量可复用工作线程来缓存昂贵连接。每任务线程模型下，更适合使用明确的连接池与作用域释放，并避免让线程本地对象随任务数量放大。