Java 虚拟线程批量发起网络请求时如何限制并发度

批量调用几十、几百个 HTTP 接口时，虚拟线程解决的是“任务如何轻量并发”，不是“远端服务最多允许多少个请求”。实用做法是继续使用 Executors.newVirtualThreadPerTaskExecutor()，再用一个 Semaphore 把真正的网络调用包住。这样可以让任务按需创建虚拟线程，同时把同时占用远端连接的数量固定在可解释的范围内。

虚拟线程数量和网络并发上限不是一回事

虚拟线程很适合“一项任务对应一条线程”的阻塞式代码，但它并不会替远端 API、数据库连接池或本机文件描述符做容量管理。把虚拟线程改成固定大小的平台线程池，确实能限制同时运行的任务，却也把“限制资源”与“复用昂贵线程”绑在了一起。Java 官方建议虚拟线程按任务创建；如果要限制访问某个服务的并发，应使用专门的同步器。

因此，批量任务可以有数千个，Semaphore(50) 只代表最多 50 个任务同时进入网络调用区。等待许可的虚拟线程仍属于任务本身，不等同于占满 50 条平台线程。

用 Semaphore 把许可放在请求边界

下面的示例用 Java 21+ 的虚拟线程执行器和同步式 HttpClient.send。每个任务只在真正发请求前申请许可，成功、超时和异常都在 finally 中归还。

var httpClient = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(3)) // 连接建立超时，避免许可长期占用
        .build();
var permits = new Semaphore(50); // 只限制同时访问目标服务的任务数

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List> futures = new ArrayList();
    for (URI uri : uris) {
        futures.add(executor.submit(() -> {
            permits.acquire(); // 未拿到许可时等待，不创建额外平台线程池
            try {
                var request = HttpRequest.newBuilder(uri)
                        .timeout(Duration.ofSeconds(8)) // 单次请求超时要小于批处理容忍度
                        .GET()
                        .build();
                return httpClient.send(request,
                        HttpResponse.BodyHandlers.ofString()).body();
            } finally {
                permits.release(); // 成功、异常和中断都必须归还许可
            }
        }));
    }
    for (var future : futures) {
        System.out.println(future.get()); // 生产代码应按业务记录结果和失败原因
    }
}

如果 acquire() 被中断，任务不会进入 try，也就不会错误地释放并不存在的许可；如果请求阶段抛出异常，finally 仍会执行。批处理需要取消时，应保留中断信号并停止继续提交新任务，而不是吞掉 InterruptedException。

四个参数不要混成一个并发数

例如远端只允许 20 个并发连接，许可数就不应从“虚拟线程很多”推导出来。若一次任务还会串行访问两个下游服务，可以分别设置两个 Semaphore，不要用一个总数掩盖更窄的瓶颈。CPU 密集型计算也不适合通过增加虚拟线程来提速，应该单独考虑处理器并行度。

常见问题

为什么不直接用固定线程池限制并发？

固定线程池同时限制了任务数量和线程资源，适合确实需要固定工作线程的场景；虚拟线程场景更推荐把“线程承载”和“外部资源限额”拆开。

许可应该在创建任务前申请吗？

通常应在任务内部、实际网络调用前申请。这样任务可以先完成本地准备，也不会让提交线程因为远端容量不足而被同步阻塞。

超时后需要手动归还许可吗？

只要请求代码位于 try 内，就由 finally 统一归还；不要在成功和异常分支各写一份 release。

许可数越大越快吗？

不一定。超过远端配额后，限流、排队、连接争用和重试可能让总耗时更长，应以成功率、超时率和下游响应时间共同判断。

核心判断只有一句：虚拟线程负责让大量等待型任务保持清晰的线程式写法，Semaphore 负责守住网络资源的并发边界。两者分开配置，批量请求才容易排查、取消和逐步放量。