直接换掉线程池可显著提升吞吐量，但须规避threadlocal泄漏、阻塞调用未适配、第三方库不兼容三类故障；推荐使用executors.newvirtualthreadpertaskexecutor()，避免手动管理虚拟线程生命周期。
直接换掉线程池即可显著提升吞吐量，但必须避开 ThreadLocal 泄漏、阻塞调用未适配、第三方库不兼容这三类典型故障。
替换 ExecutorService 为虚拟线程执行器
传统 ThreadPoolExecutor 是瓶颈根源：100 个平台线程最多并发 100 路阻塞 I/O，再多就排队。Java 21+ 提供开箱即用的替代方案：
-
Executors.newVirtualThreadPerTaskExecutor()是最安全的起点，它自动管理虚拟线程生命周期，且会等待所有任务完成后再关闭 - 避免手动用
Thread.ofVirtual().start()包裹每个任务——缺少统一资源回收，容易在异常路径下泄漏 - Spring Boot 3.3+ 默认已使用虚拟线程，但需确认未被显式覆盖：
@Bean TaskExecutor taskExecutor()若存在，必须返回基于虚拟线程的实现 - 不要复用同一个
ExecutorService实例跨多个 HTTP 请求生命周期（尤其在 WebFlux 或异步 Servlet 中），否则 Carrier Thread 复用可能放大上下文污染
识别并剥离 ThreadLocal 依赖
虚拟线程频繁挂起/恢复，导致 ThreadLocal 值在不同请求间意外残留——这是生产环境最隐蔽的内存泄漏和上下文错乱源。
- Spring 的
RequestContextHolder、TransactionSynchronizationManager在虚拟线程中默认失效，不能靠RequestContextHolder.setRequestAttributes()手动设值 - 改用
ScopedValue替代：声明ScopedValue<string> traceId = ScopedValue.newInstance();</string>，再用Scope.open().set(traceId, "t-123")绑定，虚拟线程启动时自动继承且隔离 - Logback 的
AsyncAppender和旧版 SLF4J MDC 实现不兼容虚拟线程，需升级到 2.0.12+ 并启用logback.configurationFile中的includeScopesInMdc配置项 - 检查所有自定义过滤器、拦截器、AOP 切面，移除对
ThreadLocal.get()的隐式依赖
验证第三方库是否支持 Loom
不是所有“同步 API”都能在虚拟线程里安全运行——底层若调用 Unsafe.park() 或持有 JVM 内部锁，会触发 UnsupportedOperationException。
- HikariCP 5.0+ 才正式声明 Loom 兼容；低于此版本在虚拟线程中调用
getConnection()可能卡死或抛出java.lang.UnsupportedOperationException: Virtual threads are not supported - OkHttp 4.12+ 支持虚拟线程调度，但需禁用连接池的线程本地缓存：
new OkHttpClient.Builder().connectionPool(new ConnectionPool(16, 5, TimeUnit.MINUTES)).build() - JDBC 驱动必须是 4.0+（如 PostgreSQL 的
pgjdbc-ng或 Oracle 的ojdbc11），旧驱动在ResultSet.next()等阻塞点可能无法正确挂起虚拟线程 - 用
jstack -l <pid></pid>观察线程 dump：若看到大量VirtualThread[#N]@xxx卡在park或wait，说明某依赖尚未适配
监控 Carrier Thread 的实际负载
虚拟线程本身不耗资源，但底层 Carrier Thread 数量有限——默认由 JVM 控制（通常等于 CPU 核数 × 2），若 Carrier Thread 成为瓶颈，所有虚拟线程都会排队等待调度。
- 通过 JFR（Java Flight Recorder）开启
jdk.VirtualThreadMount和jdk.VirtualThreadUnmount事件，观察挂载/卸载频率与延迟 - 设置 JVM 参数
-XX:ActiveProcessorCount=16显式限制 Carrier Thread 上限，避免突发流量打满 OS 线程导致系统级阻塞 - 不要盲目追求“百万虚拟线程”，真实吞吐受制于 I/O 子系统（DB 连接池、Redis 客户端、网卡中断等），需同步扩容这些配套资源
- 压测时关注
java.lang:type=Threading/TotalStartedThreadCount（飙升说明创建无节制）和java.lang:type=Threading/CurrentThreadCpuTime（若远低于总耗时，说明大量时间花在 I/O 等待而非计算）
真正难的不是把 newFixedThreadPool 换成 newVirtualThreadPerTaskExecutor，而是厘清哪些代码路径仍隐式依赖平台线程语义——尤其是那些写了十年、没人敢动的工具类和中间件封装层。
