如何利用 JDK 21 的虚拟线程配合异步 I/O 重构高并发 Web 服务的线程模型

先直接说结论：虚拟线程本身并不会改变 I/O 的阻塞或非阻塞性质，它真正的价值在于，让开发者用同步代码写阻塞 I/O 调用时，在高并发场景下既不会卡死，也不会导致线程爆炸。你不需要、也不应该为了配合虚拟线程，强行把 HttpClient 或 JDBC 换成异步客户端——那样反而背离了它的设计初衷。

虚拟线程不是异步 I/O，却能让阻塞 I/O“不卡”

不少开发者一提到“高并发”和“I/O 密集”，本能反应就是切换到 WebFlux 或 AsyncHttpClient。但虚拟线程的定位其实非常清晰：它不替换底层的 I/O 模型，而是接管了线程的调度逻辑。当一个虚拟线程调用 socket.read() 或 connection.prepareStatement() 并被阻塞时，JVM 会悄无声息地把它从当前的载体线程上卸载下来，空出载体线程去执行其他虚拟线程。这个过程对业务代码完全透明。

所以，你继续使用 RestTemplate、JdbcTemplate，甚至 FileInputStream 都完全没问题。只要这些调用最终触发的是标准 JDK 中的 I/O 阻塞点——比如 InputStream.read()、SocketChannel.read()、Thread.sleep()——虚拟线程就能感知到，并自动执行卸载动作。

• ✅ 支持自动卸载的典型阻塞点：Thread.sleep()、Object.wait()、InputStream.read()、OutputStream.write()、ServerSocket.accept()、Socket.connect()
• ❌ 不会触发卸载的场景：synchronized 块内长时间执行、Unsafe.park() 手动挂起、调用 JNI 或 Native 方法、CPU 密集循环（比如 while(true) { i++; }）
• ⚠️ 特别注意：ja va.net.http.HttpClient 默认是阻塞式的，但它的 sendAsync() 方法确实是真正异步的。在虚拟线程里用它虽然不会报错，不过属于“过度设计”，反而会增加回调和线程切换的开销。

Spring Boot 3.1+ 启用虚拟线程的最简路径

如果你用的是 Spring Boot 3.1 及以上（基于 JDK 21），只需要改动两处配置，完全不需要重写 Controller 或 Service 层的代码：

• 在启动类或配置类中注入虚拟线程执行器：把原来的 @Bean public TaskExecutor taskExecutor() { return new SimpleAsyncTaskExecutor(); } 改为 return Executors.newVirtualThreadPerTaskExecutor();
• 在 application.properties 中添加：spring.mvc.async.request-timeout=-1，避免 Spring 自动超时而中断虚拟线程。
• 同时确认 Web 容器使用的是支持虚拟线程的模式：Tomcat 10.1.15 以上版本默认已启用，但需要核实是否被显式关闭；如果用的是 Jetty 或 Undertow，则需升级到对应的支持版本。

需要留意的是，SimpleAsyncTaskExecutor 是一个测试用的“每次新建线程”实现，它和虚拟线程的语义看起来接近，但并不是等价替换。生产环境必须使用 Executors.newVirtualThreadPerTaskExecutor()，否则用的仍然是平台线程。

为什么不能在虚拟线程里用 synchronized 做长临界区

这是最容易踩的坑。当一个虚拟线程进入 synchronized 块后，如果内部发生了 I/O 阻塞，JVM 无法将它卸载——因为锁的持有状态必须由同一个载体线程来恢复，否则会破坏内存可见性的语义。结果就是，这个载体线程被死死占住，其他几十个正在等待的虚拟线程全部卡住。

举个例子，下面这段代码会导致吞吐量断崖式下跌：

synchronized (lock) {
    Thread.sleep(1000); // 卡住整个载体线程 1 秒
    doSomething();
}

正确的做法是换用 ReentrantLock，并配合 tryLock() 或 lockInterruptibly()：

• ✅ ReentrantLock 在阻塞等待锁时，支持被 JVM 卸载（前提是没有因为 lock() 导致死锁）
• ✅ 更推荐的做法是用 StampedLock 或无锁结构（比如 ConcurrentHashMap）来替代共享可变状态
• ✅ 如果必须用同步方式访问外部资源（例如 Redis 连接池），应该把同步范围缩到最小，并且确保内部不包含任何阻塞调用

内存与监控方面容易被忽略的细节

虚拟线程的数量可以轻松达到数十万，但每一个虚拟线程仍然持有自己的 ThreadLocal 和栈帧。如果滥用 ThreadLocal——比如用来存大对象或者缓存连接——很容易引发 OOM。另外，默认的 JVM 线程 dump 命令（jstack）几乎无法解析虚拟线程的堆栈，调试时很容易误判。

• ⚠️ ThreadLocal 应该换成 ScopedValue（JDK 21 新增）。它是专门为虚拟线程设计的，生命周期绑定在作用域上而非线程上，而且没有内存泄漏的风险。
• ⚠️ 可以通过启用 -XX:+UnlockDiagnosticVMOptions -XX:+PrintVirtualThreadEvents 来输出虚拟线程的挂载和卸载日志，用来排查“卡顿”是否源于意料之外的阻塞点。
• ⚠️ 用 jcmd VM.native_memory summary 比 jstat 更能反映真实的内存压力——因为虚拟线程的栈内存不计入 Thread 区域，而是算在 Internal 或 Other 里。

真正的复杂点，其实不在于怎么开启虚拟线程，而在于如何善后。虚拟线程让“创建”变得极其廉价，但“错误传播”和“资源清理”依然要靠你自己——比如数据库连接没有关闭、HTTP 客户端没有 shutdown，这些资源会在虚拟线程退出后继续占用底层，最终拖垮整个系统。