Executors.newVirtualThreadPerTaskExecutor()不能直接提升吞吐量，必须配合异步IO；同步IO（如传统JDBC、ServletInputStream）会使载体线程阻塞，导致虚拟线程饿死、吞吐下降；需改用NIO、R2DBC、AsynchronousFileChannel等JVM可感知的异步API，并启用Tomcat虚拟线程支持及StructuredTaskScope管理生命周期。
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()); } - 关键点：
scope.join()阻塞直到所有子任务完成或失败，throwIfFailed()统一抛出首个异常，避免子任务异常静默丢失 - 容易踩的坑：在
scope外捕获子任务异常会导致join()永远不返回；shutdown()不等于join()，必须显式调用
System.out.println() 在高并发下都可能成为瓶颈**——它的内部锁会串行化所有虚拟线程的输出，建议用异步日志框架或禁用调试日志。 
