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

虚拟线程不改变i/o的阻塞性质，仅通过jvm调度实现阻塞时自动卸载，使同步阻塞i/o（如jdbc、socket）在高并发下不卡死；无需改io代码，但需用newvirtualthreadpertaskexecutor、避坑synchronized长临界区及object.wait()。

如何利用 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++; }）
⚠️ 特别注意：java.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 <pid> VM.native_memory summary</pid> 比 jstat 更能反映真实内存压力——虚拟线程栈内存不计入 Thread 区，而算在 Internal 或 Other