Java 虚拟线程为什么不等于无限并发：从等待型任务说起

一个接口要请求外部模型、查询数据库、读取远程文件，大部分时间可能都在等。为了同时处理更多请求，传统做法往往是调大线程池；但平台线程不是没有成本，线程数量也不能无限增加。

虚拟线程为这种“每个任务按顺序写代码、执行中经常阻塞等待”的场景提供了另一种选择。它在 JDK 21 成为正式特性，目标重点是提高大量等待型任务的并发承载能力，而不是让单个计算任务自动变快。1

线程轻了，真正的资源没有变多

可以把虚拟线程理解为由 JVM 调度的轻量线程。适用的阻塞操作发生时，运行它的平台线程可以释放出来执行其他虚拟线程。具体行为还取决于操作、库实现和 JDK 版本，不能把“阻塞都没有成本”当成保证。

假设数据库连接池只有 20 个连接，即使创建 10,000 个虚拟线程，数据库也不会自动变成能同时处理 10,000 个查询。等待只是从平台线程池队列转移到了获取连接的地方。如果每个任务还持有大对象，内存仍然可能耗尽。

因此需要分清三件事：线程用于承载执行；并发限制用于保护有限资源；入口限流或有界队列用于控制系统接收多少工作。只改变第一件事，后两件事仍要设计。

一个带并发上限的完整示例

下面的程序面向 Java 21 及以上，使用 Thread.sleep 模拟等待，不访问外部服务。它演示同一时间最多八个任务进入受保护区域，不是性能基准。将代码保存为 VirtualThreadBulkhead.java 即可按后面的命令运行。

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class VirtualThreadBulkhead {
    private static final Semaphore GATE = new Semaphore(8);
    private static final AtomicInteger ACTIVE = new AtomicInteger();
    private static final AtomicInteger PEAK = new AtomicInteger();

    private static String callDownstream(int id) throws InterruptedException {
        // 只在成功拿到许可后进入 finally，避免误释放许可。
        if (!GATE.tryAcquire(2, TimeUnit.SECONDS)) {
            return "REJECTED:" + id;
        }

        try {
            int active = ACTIVE.incrementAndGet();
            PEAK.accumulateAndGet(active, Math::max);
            Thread.sleep(40); // 模拟可中断的等待，不代表真实接口耗时。
            return "OK:" + id;
        } finally {
            ACTIVE.decrementAndGet();
            GATE.release();
        }
    }

    public static void main(String[] args) throws Exception {
        List<Future<String>> futures = new ArrayList<>();
        int succeeded = 0;
        int rejected = 0;

        try (ExecutorService executor =
                     Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 200; i++) {
                final int id = i;
                futures.add(executor.submit(() -> callDownstream(id)));
            }

            for (Future<String> future : futures) {
                String result = future.get();
                if (result.startsWith("OK:")) {
                    succeeded++;
                } else {
                    rejected++;
                }
            }
        }

        if (PEAK.get() > 8) {
            throw new IllegalStateException("并发上限被突破");
        }
        System.out.printf("ok=%d rejected=%d peak=%d%n",
                succeeded, rejected, PEAK.get());
    }
}

运行方式：

javac --release 21 VirtualThreadBulkhead.java
java VirtualThreadBulkhead

这里的 200 是有限的演示输入。生产系统不应先把任意多请求全部提交，再认为一个 Semaphore 已经解决过载。入口仍应设置接收上限、排队时限或拒绝策略。

tryAcquire 只限制等待许可的时间，不限制真正的远程请求时间。替换成 HTTP 或数据库调用后，还要配置调用超时、连接池获取超时，并按业务需要管理整体截止时间。Future.get() 超时也不等于远程动作一定停止；取消通常只是请求中断，底层客户端是否响应必须验证。

以上 Java 21 示例经过代码审阅，但未附编译运行验证；这里不提供运行结果或吞吐量数字。它适合用来观察任务与许可的关系，真实服务还需要在对应 JDK 和依赖环境中验证。

虚拟线程最有价值的地方，是保留直观的顺序代码，同时承载更多等待中的任务。上线前真正需要验证的，是下游容量、排队时间、内存和取消行为，而不是只数创建了多少线程。

参考资料

1 OpenJDK：JEP 444 — 虚拟线程的目标与正式引入。
2 Oracle：Java 21 Virtual Threads — 使用方式与限制。
3 Oracle：Java 24 Virtual Threads — 新版本中的行为说明；另见 JEP 491。

本文不报告性能实测。资料核对日期：2026-10-08。

Java 虚拟线程为什么不等于无限并发：从等待型任务说起

线程轻了，真正的资源没有变多

一个带并发上限的完整示例

并发上限和每秒请求数不是一回事

哪些任务不适合指望虚拟线程提速

关于 synchronized，要写清 JDK 版本

参考资料