虚拟线程对阻塞式IO天然友好，包括Thread.sleep()、Object.wait()、LockSupport.park()、阻塞模式的NIO通道（FileChannel/SocketChannel）、HttpURLConnection、java.net.Socket、OkHttpClient及新版PostgreSQL/MySQL JDBC驱动；不支持Selector.select()等纯NIO事件循环。
直接用 Executors.newVirtualThreadPerTaskExecutor() 启动任务，配合标准阻塞式 IO（如 HttpURLConnection、Socket、JDBC 驱动的 Connection）就能跑通高并发 Web 服务——不需要改业务逻辑，也不需要引入响应式框架。
虚拟线程对哪些 IO 操作天然友好？
虚拟线程的挂起/恢复机制深度集成在 JVM I/O 调用中，只要底层 API 支持“可中断阻塞”，它就能自动卸载。目前已明确支持的包括：
-
Thread.sleep()、Object.wait()、LockSupport.park() - 基于 NIO 的阻塞通道：
FileChannel.read()/write()（需配置为阻塞模式）、SocketChannel.read()/write()（同上） - 传统阻塞式网络库：
HttpURLConnection、java.net.Socket、OkHttpClient（默认配置） - JDBC 驱动：PostgreSQL 的
pgjdbc（42.6+）、MySQL 的mysql-connector-j（8.0.33+），前提是连接 URL 中未启用useSSL=false&allowPublicKeyRetrieval=true等强制非阻塞路径
不支持的典型场景：Selector.select()（纯 NIO 事件循环）、AsynchronousFileChannel、Reactor 的 Mono.fromCallable() 包裹的阻塞调用（会退化为平台线程执行）。
为什么不能直接把旧线程池替换成 virtual thread executor？
不是语法错误，而是语义冲突。常见踩坑点：
- 旧代码里用了
ThreadPoolExecutor的getActiveCount()或getQueue().size()做监控——虚拟线程执行器没有任务队列，submit()立即创建并调度，这两个值恒为 0 - 手动调用
shutdownNow()并依赖interrupt()中断正在运行的任务——虚拟线程无法被中断（Thread.interrupt()不生效），必须靠业务层超时或关闭资源触发自然退出 - 在
try-with-resources外围用ThreadLocal存储上下文（如 traceId）——虚拟线程生命周期极短且频繁复用载体线程，ThreadLocal不会自动清理，导致脏数据泄漏
正确做法是：用 StructuredTaskScope 替代手工管理；用 InheritableThreadLocal + 显式 copy() 传递上下文；监控改用 Thread.currentThread().isVirtual() 和 JVM TI 工具（如 JFR 的 jdk.VirtualThreadStart 事件）。
Spring Boot 3.2+ 怎么接入虚拟线程？
Spring Boot 3.2 默认已启用虚拟线程感知，但需主动开启，否则仍走传统线程池：
- 启动参数加
-Dspring.threads.virtual.enabled=true（推荐） - 或在
application.properties写spring.threads.virtual.enabled=true - WebMvc 场景下，还需确认
WebMvcConfigurer未覆盖configureAsyncSupport()——一旦显式设置setTaskExecutor()，就会绕过虚拟线程自动配置
验证是否生效：发一个请求，在控制器里打印 Thread.currentThread().isVirtual()，返回 true 即接入成功。注意：Spring Data JDBC / JPA 默认仍是阻塞模式，无需额外配置；但 Spring WebFlux 与虚拟线程互斥，二者不可共存于同一 Web 层。
真正难的是资源泄漏控制——虚拟线程让“开多少个”不再受限，但数据库连接、HTTP 客户端连接池、文件句柄这些外部资源不会自动缩放。哪怕用了百万虚拟线程，如果只配了 20 个 DB 连接，瓶颈立刻回到连接池。所以重构时，第一优先级不是换线程模型，而是检查所有外部依赖的资源上限配置。
