Java 25 虚拟线程处理阻塞 I/O：线程模型与容量评估

我第一次把阻塞式 HTTP 调用迁移到虚拟线程时，最容易犯的错并不是 API 用错，而是把“能创建很多线程”理解成“可以无限放大并发”。Java 25 的虚拟线程适合大量等待 I/O 的任务，它提升的是吞吐扩展能力，不会自动降低单次请求延迟，也不会扩大数据库连接数、下游接口配额、文件描述符或 CPU 预算。

Java 25 虚拟线程官方文档：https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html

问题看似在线程数，根因却常在容量边界

传统平台线程会在整个生命周期内占用对应的操作系统线程。请求大量等待网络或 JDBC 时，平台线程池很快变成吞吐瓶颈。虚拟线程仍是 Thread，但不与某一个操作系统线程永久绑定；阻塞 I/O 发生时，运行时通常可以挂起虚拟线程，让载体线程去执行其他任务。

这解释了为什么同步阻塞代码可以获得更好的吞吐扩展，但也解释了一个反常现象：线程池瓶颈消失后，下游连接池、接口限流、堆内存和 CPU 反而更早暴露。那次迁移让我真正改掉的习惯，是不再问“虚拟线程池应该设多大”，而是问“每个稀缺资源允许多少并发任务进入”。

每个任务一个虚拟线程，不要再池化虚拟线程

Executors.newVirtualThreadPerTaskExecutor() 会为每个提交的任务启动一个新的虚拟线程。它不是一个固定大小的虚拟线程池。对于大量短生命周期、主要等待 I/O 的任务，这种“线程代表任务”的模型通常比把任务塞进共享平台线程池更直接。

下面示例保留同步阻塞式 HttpClient.send()，同时用 Semaphore 限制真正稀缺的远端调用席位。虚拟线程负责表达任务，信号量负责表达容量，两者职责不要混在一起。

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.List;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;

public final class VirtualThreadIoDemo {
    // HttpClient 可复用，避免每个任务重复创建连接管理组件。
    private static final HttpClient CLIENT = HttpClient.newBuilder()
            .connectTimeout(Duration.ofSeconds(2))
            .build();

    // 线程不再稀缺，但远端服务的并发承载能力仍然有限。
    private static final Semaphore REMOTE_SLOTS = new Semaphore(200);

    private static String fetch(URI uri) throws IOException, InterruptedException {
        // 等待容量席位也设置超时，避免请求无限堆积。
        boolean acquired = REMOTE_SLOTS.tryAcquire(100, TimeUnit.MILLISECONDS);
        if (!acquired) {
            throw new IOException("远端并发容量已满");
        }

        try {
            HttpRequest request = HttpRequest.newBuilder(uri)
                    .timeout(Duration.ofSeconds(3))
                    .GET()
                    .build();

            // 阻塞等待响应时，虚拟线程可以被挂起，载体线程可服务其他任务。
            return CLIENT.send(request, HttpResponse.BodyHandlers.ofString()).body();
        } finally {
            // 无论请求成功还是失败，都必须归还下游容量席位。
            REMOTE_SLOTS.release();
        }
    }

    public static void main(String[] args) throws Exception {
        List uris = List.of(
                URI.create("https://example.com/a"),
                URI.create("https://example.com/b")
        );

        // 执行器关闭时会等待已提交任务结束，适合明确的任务批次。
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            List> futures = uris.stream()
                    .map(uri -> executor.submit(() -> fetch(uri)))
                    .toList();

            for (Future future : futures) {
                // 示例只读取长度，实际项目应在这里处理状态码和业务结果。
                System.out.println(future.get().length());
            }
        }
    }
}

示例中的 200 不是虚拟线程上限，而是一个假定的远端并发预算。真实值要根据对方服务配额、连接池大小、超时、错误率和压测结果决定。数据库调用也是同理：如果 JDBC 连接池只有 50 个连接，创建 5 万个虚拟线程不会让 5 万条 SQL 同时执行，只会让大量任务等待连接。

容量估算从到达率和等待时间开始

容量评估可以先用一个简单关系建立量级：平均并发任务数约等于请求到达率乘以平均在途时间。目标吞吐为每秒 2000 个请求、平均在途时间为 250 毫秒时，在途任务量级约为 500。这个数字只用于起始估算，还要叠加长尾延迟、突发流量和重试带来的放大。

虚拟线程不能解决 CPU 密集型工作

Oracle 文档明确指出，虚拟线程适合大部分时间处于阻塞等待的任务，不适合长时间 CPU 密集型操作。JSON 大对象解析、图像处理、加密计算或复杂规则执行仍然消耗实际 CPU。把这些工作无上限地提交到虚拟线程，只会让更多可运行任务争抢处理器。

我的经验是先把请求拆成“等待 I/O”和“消耗 CPU”两段：I/O 段可以使用每任务一个虚拟线程；CPU 段则按核心数、延迟目标和队列长度控制并行度。这样容量模型更清晰，故障时也能区分是下游等待、载体线程受阻，还是 CPU 饱和。

Java 25 还要关注哪些固定问题

Java 25 文档把虚拟线程固定在载体线程上的主要情形列为执行 native 方法或外部函数。固定不会破坏正确性，但长时间、频繁发生时会影响扩展性。与早期版本相比，普通 synchronized 代码已不再是文档列出的常规固定原因，但本地方法和外部函数边界仍需要通过 JFR 观察。

另一个隐蔽成本是 ThreadLocal。虚拟线程不会像池化平台线程那样被多个无关任务反复复用，如果每个任务都通过 ThreadLocal 创建昂贵对象，数量放大后会消耗大量内存。优先使用可共享的不可变对象，避免把平台线程时代的缓存习惯原样搬过来。

用线程转储和 JFR 复查现场

虚拟线程仍然可以被调试和观察。Java 25 的 jcmd 能输出包含平台线程和虚拟线程的文本或 JSON 线程转储；JFR 还提供虚拟线程启动、结束、固定和提交失败等事件。容量评估不要只看平均响应时间，还要结合在途任务数、下游等待、固定事件和失败事件。

# 导出包含平台线程和虚拟线程的 JSON 线程转储。
jcmd 12345 Thread.dump_to_file -format=json threads.json

# 从 JFR 记录中打印虚拟线程相关事件。
jfr print --events jdk.VirtualThreadStart,jdk.VirtualThreadEnd,jdk.VirtualThreadPinned,jdk.VirtualThreadSubmitFailed recording.jfr

适合谁，什么时候不值得迁移

虚拟线程适合线程每请求模型、同步阻塞客户端、JDBC、文件 I/O，以及大量彼此独立的短生命周期任务。若系统并发很低、主要瓶颈是 CPU，或者框架已经采用事件循环和异步模型，迁移收益可能有限。Oracle 的采用指南也提醒，不要把同步阻塞代码和异步框架随意混用，否则线程模型和观测方式会变得更复杂。

最终判断标准不是“能启动多少虚拟线程”，而是业务吞吐是否提高、尾延迟和错误率是否受控、下游资源是否稳定。虚拟线程把线程从稀缺资源变成任务表达方式；容量控制仍然要落在连接、配额、内存、CPU 和超时这些真实边界上。