Java virtual threads 怎样限制并发外部调用数量

Java virtual threads 解决的是“可以用较低线程成本承载很多并发任务”，并不等于外部服务可以同时接收无限请求。Executors.newVirtualThreadPerTaskExecutor() 会为每个提交的任务创建一个虚拟线程，官方文档明确说明它的线程数量是无界的；如果下游 HTTP 服务、数据库连接池或第三方接口只能承受固定并发量，就要把限流放在外部调用边界上。

最直接的组合是：虚拟线程负责承载任务，Semaphore 负责发放有限许可。下面的示例假设使用 Java 21 或更高版本。官方资料可以从 https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html 和 https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/Semaphore.html 进入。

不要为了限制外部调用而把虚拟线程塞进固定大小的线程池。让每个任务继续拥有自己的虚拟线程，再用 Semaphore 的许可数表达下游真正能承受的并发量。

先把两个“并发数”分开

虚拟线程数量描述的是应用愿意同时推进多少个任务；外部调用许可数描述的是同一时刻有多少个任务可以进入受保护的资源。两者不是同一个旋钮。

例如同时有 1000 个订单任务，它们可以各自运行在虚拟线程上，但支付接口只允许同时处理 20 个请求，那么信号量应初始化为 20。其余虚拟线程可以在 acquire() 处等待，等待期间不会像占满 20 个平台线程的旧式线程池那样把“工作线程配额”误当成资源配额。

用 Semaphore 包住真正的外部调用

许可应该覆盖从准备发起请求到拿到响应所需的资源占用区间，而不是覆盖整个业务任务。这样，任务中不访问下游的计算、组装和日志处理不会无谓占用许可。

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;

final class ExternalCallLimiter {
    private final Semaphore permits;
    private final HttpClient client;

    ExternalCallLimiter(int maxInFlight) {
        if (maxInFlight 

acquire() 被中断时会抛出 InterruptedException，这时任务尚未拿到许可，因此不能执行 release()。一旦成功拿到许可，后续所有路径都必须进入 finally。如果业务需要有界等待，可以使用 tryAcquire，把“排队太久”转成可观测的超时结果。

虚拟线程执行器只负责承载任务

提交任务时保持“一任务一虚拟线程”，把同一个限流器共享给所有任务。try-with-resources 负责关闭执行器；关闭时会等待已经提交的任务结束，外部调用本身仍由信号量控制。

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

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var limiter = new ExternalCallLimiter(20); // 20 是下游允许的同时调用数，不是线程数
    var futures = new java.util.ArrayList>();

    for (var url : urls) {
        futures.add(executor.submit(() -> limiter.getWithin(
                url, 2, java.util.concurrent.TimeUnit.SECONDS))); // 排队超时要能被调用方感知
    }

    for (var future : futures) {
        try {
            System.out.println(future.get()); // 这里只收集结果，不再增加外部调用许可
        } catch (java.util.concurrent.ExecutionException ex) {
            System.err.println("外部调用失败：" + ex.getCause()); // 单个失败不应吞掉根因
        }
    }
}

这个结构的重点不是把并发任务总数硬截成 20，而是让大量虚拟线程可以等待，同时让真正进入外部服务的任务不超过 20。若下游客户端自身有连接池、每主机连接上限或服务端配额，许可数还要取这些约束中更小的安全值。

许可数怎么定，哪些写法容易失控

常见失控写法有三种：把 newFixedThreadPool(20) 当成唯一限流器、拿到许可后又异步转移到另一个执行器、以及异常路径漏掉 release()。第一种混淆了线程资源和外部资源，第二种让许可保护的区间失效，第三种会让可用许可逐渐归零。

小结：把限制放在资源边界

Java virtual threads 适合让阻塞式外部调用保持清晰的同步写法，但它们不会自动替你保护下游。用 newVirtualThreadPerTaskExecutor() 表达任务并发，用 Semaphore 表达外部调用并发，用超时、中断和监控处理排队与失败，才能让两个“并发数”各自对应真实的工程约束。

相关问题

Semaphore 的许可数等于虚拟线程数吗？

不等于。虚拟线程数对应同时存在的任务，许可数对应能进入某个受保护外部资源的任务；通常后者更小。

为什么不直接固定线程池大小？

固定线程池会同时限制任务承载和外部访问，两个边界耦合在一起。使用虚拟线程加 Semaphore，可以独立调整这两个约束。