直接用executors.newvirtualthreadpertaskexecutor()替换传统线程池，配合jdk 21+、spring boot 3.1+及适配的i/o组件，可在不改业务逻辑前提下完成线程模型升级。
直接用 Executors.newVirtualThreadPerTaskExecutor() 替换传统线程池，配合标准阻塞式 I/O（如 HttpURLConnection、JDBC、Socket），就能在不改业务逻辑的前提下完成线程模型升级——前提是 JDK 21+、Spring Boot 3.1+，且底层 I/O 调用落在 JVM 可感知的挂起点上。
确认运行环境是否就绪
虚拟线程不是“开箱即用”，需要基础组件协同支持：
- JDK 版本 ≥ 21（推荐 21 或 22，已通过 Loom 正式稳定）
- Spring Boot ≥ 3.1（内置对虚拟线程的自动配置支持）
- Web 容器：Tomcat 10.1.15+（默认启用虚拟线程调度），或 Jetty/Undertow 需显式开启（如
jetty.httpConfig.virtualThreadsEnabled=true） - 禁用 Spring MVC 的默认超时：
spring.mvc.async.request-timeout=-1，避免它在 I/O 等待中途中断虚拟线程
替换执行器，不碰 Controller 和 Service
无需重写业务代码，只需调整线程供给方式：
- 删掉旧的
ThreadPoolExecutorBean（如newFixedThreadPool(50)） - 注入新执行器：
@Bean public TaskExecutor taskExecutor() { return Executors.newVirtualThreadPerTaskExecutor(); } - 若使用
@Async，确保该执行器被其识别（Spring 默认会找名为taskExecutor的 Bean） - 注意：不要调用
shutdownNow()或依赖getActiveCount()监控——虚拟线程执行器无队列、不可中断、不暴露活跃数
适配 I/O 层：避开“伪阻塞”陷阱
虚拟线程只对 JVM 知道的阻塞点自动卸载。以下操作能触发卸载，可放心保留：
-
Thread.sleep()、Object.wait()、LockSupport.park() - 阻塞模式的 NIO 通道：
SocketChannel.read()（需configureBlocking(true)） - 新版 JDBC 驱动：
mysql-connector-j 8.0.33+、pgjdbc 42.6+（连接 URL 不加useSSL=false等强制绕过 SSL 的参数） -
HttpURLConnection、OkHttpClient（默认同步模式）、java.net.Socket
以下操作会导致载体线程卡死，必须规避：
-
Selector.select()（纯 NIO 事件循环，JVM 不感知） - 老版本 JDBC（如 MySQL 8.0.29 之前）、未配置为阻塞模式的
FileChannel -
synchronized块内长时间计算、Unsafe.park()、JNI 调用 - Servlet
InputStream.read()（Tomcat 10.1.15+ 已适配，但低版本需升级）
上下文与监控要换思路
虚拟线程生命周期短、复用载体线程频繁，传统做法会出问题：
-
ThreadLocal存 traceId？→ 改用InheritableThreadLocal+ 显式copy()，或迁移到MDC（Logback 1.4+ / Log4j 2.20+ 自动支持） - 想看当前有多少虚拟线程在跑？→ 不查
getQueue().size()，改用 JVM TI 工具，例如 JFR 中监听jdk.VirtualThreadStart事件 - 需要结构化管理任务生命周期？→ 用
StructuredTaskScope替代手工join()或countDownLatch - 数据库连接池要不要调小？→ 是的，从 50–100 降到 10–20 即可，虚拟线程本身不争抢连接，瓶颈在 DB 而非线程数
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
