Java 虚拟线程实战：用同步写法扛住十万并发

为什么需要虚拟线程#

传统的 Java 线程是对操作系统线程的一层薄封装，一个线程大约占用 1MB 栈空间，创建和切换成本都不低。于是我们才有了线程池、回调、CompletableFuture、响应式编程这一整套「为了省线程而牺牲可读性」的方案。

虚拟线程（Virtual Thread，JDK 21 正式）换了个思路：线程由 JVM 调度，成本极低，可以轻松创建几十万个。阻塞时，JVM 会把它从载体线程（carrier thread）上卸下来，让出 CPU。

结论：可以继续用最直观的同步代码，同时拿到接近异步的吞吐。

最小示例#

1
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
2
    List<Future<String>> futures = new ArrayList<>();
3
    for (int i = 0; i < 100_000; i++) {
4
        int id = i;
5
        futures.add(executor.submit(() -> {
6
            Thread.sleep(Duration.ofSeconds(1));
7
            return "task-" + id;
8
        }));
9
    }
10
    for (var f : futures) {
11
        f.get();
12
    }
13
}

十万个任务各睡一秒，总耗时依然接近一秒。换成固定大小的平台线程池，你会等很久。

在 Spring Boot 中启用#

Spring Boot 3.2+ 只需要一行配置：

1
spring:
2
  threads:
3
    virtual:
4
      enabled: true

Tomcat 的请求处理线程、@Async 的执行器都会切换成虚拟线程。

常见误区#

1. 不要池化虚拟线程。 它们本来就是廉价的，用完即弃。需要限流时用 Semaphore，而不是缩小线程池。
2. CPU 密集型任务没有收益。 虚拟线程解决的是「等待」问题，不是「计算」问题。
3. 小心 synchronized 造成的 pinning。 在 JDK 21 中，虚拟线程在 synchronized 块里阻塞会钉住载体线程。能换成 ReentrantLock 就换。可以用 -Djdk.tracePinnedThreads=full 排查。
4. ThreadLocal 要克制。 线程数量暴涨后，每个线程一份 ThreadLocal 的内存开销会被放大。

小结#

虚拟线程不是银弹，但对大多数 IO 密集的业务后端来说，它能让代码回到最朴素的样子。升级 JDK 21 之后，先把它开在非核心服务上压测一遍，数据会告诉你答案。