如何利用 JDK 21 的虚拟线程配合异步 IO 重构高并发 Web 服务的线程模型-java教程-PHP中文网

Executors.newVirtualThreadPerTaskExecutor()不能直接提升吞吐量，必须配合异步IO；同步IO（如传统JDBC、ServletInputStream）会使载体线程阻塞，导致虚拟线程饿死、吞吐下降；需改用NIO、R2DBC、AsynchronousFileChannel等JVM可感知的异步API，并启用Tomcat虚拟线程支持及StructuredTaskScope管理生命周期。

如何利用 jdk 21 的虚拟线程配合异步 io 重构高并发 web 服务的线程模型

Executors.newVirtualThreadPerTaskExecutor()

能直接替换传统线程池，但**仅靠它无法自动提升吞吐量**——虚拟线程必须配合异步 IO 才能真正释放调度优势。同步阻塞调用（如 Thread.sleep()、InputStream.read()、JDBC 的 executeQuery()）会让载体线程卡住，导致其他虚拟线程饿死。

为什么虚拟线程 + 同步 IO 会失效

虚拟线程的“卸载”能力只在 JVM 知道的阻塞点生效。JDK 21 对以下操作做了原生支持：Thread.sleep()、Object.wait()、LockSupport.park()、NIO 的 Selector.select()。但传统同步 IO（比如 Socket.getInputStream().read() 或老版 JDBC 驱动）会直接陷入操作系统内核态阻塞，JVM 完全不可见，也就无法挂起当前虚拟线程。

此时行为退化为：一个载体线程被死死占住，成百上千个虚拟线程排队等它，吞吐量不升反降，内存占用还更高。

典型错误现象：java.lang.Thread.State: RUNNABLE 却长时间无响应，jstack 显示大量虚拟线程卡在 java.io.FileInputStream.readBytes(Native Method)
使用场景：Spring Boot 默认嵌入 Tomcat，其 ServletInputStream 是同步阻塞的；MySQL Connector/J 8.0.29 之前默认也是同步驱动
性能影响：吞吐量可能比 newFixedThreadPool(50) 还低，CPU 利用率反而更低

必须切换到 NIO 或异步客户端

要让虚拟线程真正“流动”起来，所有 I/O 操作必须进入 JVM 可感知的挂起点。这意味着放弃 java.io 和传统 JDBC，改用：

HTTP 客户端：用 HttpClient.newBuilder().build()（JDK 11+ 内置），它底层基于 NIO，sendAsync() 返回 CompletableFuture，但可在虚拟线程中安全调用
数据库：MySQL 推荐 mysql-connector-java:8.0.33+ 并启用 useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC，关键是要用 Connection.setNetworkTimeout() 配合虚拟线程；更稳妥的是迁移到 R2DBC（如 r2dbc-mysql）
文件读写：避免 FileInputStream，改用 AsynchronousFileChannel.open() 或 Files.readString(path, charset)（JDK 11+ 的静态方法是阻塞但已适配虚拟线程）
日志：Logback 1.4+ 或 Log4j 2.20+ 支持异步 Appender，避免 FileAppender 同步刷盘拖慢虚拟线程

Tomcat 需显式启用虚拟线程支持

Spring Boot 3.2+ 默认仍用平台线程处理请求，即使你代码里用了 newVirtualThreadPerTaskExecutor()，入口线程仍是重量级的。必须让 Web 容器本身运行在虚拟线程上。

配置项：server.tomcat.threads.virtual.enabled=true（Spring Boot 3.2.2+）
或手动替换 Tomcat 的 TaskExecutor：在 @Configuration 类中定义 WebServerFactoryCustomizer，将 TomcatServletWebServerFactory.getProtocolHandler().setExecutor(...) 设为 Executors.newVirtualThreadPerTaskExecutor()
注意：启用后，Thread.currentThread().isVirtual() 在 Controller 方法里应返回 true；若仍为 false，说明配置未生效
兼容性影响：部分依赖 ThreadLocal 的老库（如旧版 HikariCP 初始化逻辑）可能出问题，优先用 ScopedValue 替代

结构化并发管理生命周期

虚拟线程数量可能瞬间飙升到数万，不用 try-with-resources 或 StructuredTaskScope，极易泄漏。

错误写法：executor.submit(() -> { ... }); 后不等待也不关闭 —— 虚拟线程不会自动回收，JVM 会持续持有它们直到 GC

正确做法：用 StructuredTaskScope 包裹批量任务，例如聚合多个下游调用：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var dbHandle = scope.fork(() -> queryDB());
    var apiHandle = scope.fork(() -> callExternalAPI());
    scope.join();
    scope.throwIfFailed();
    return merge(dbHandle.get(), apiHandle.get());
}