虚拟线程不能仅靠替换ExecutorService启用，必须确保阻塞调用在JVM已知挂起点（如Thread.sleep、Socket.read）才能自动yield载体线程；自定义JNI、Unsafe.park或未适配的连接池会使其退化为平台线程阻塞。
直接替换 ExecutorService 就能用上虚拟线程？别急，先看线程创建方式
不能简单把 Executors.newFixedThreadPool(200) 换成 Executors.newVirtualThreadPerTaskExecutor() 就完事。虚拟线程不是“线程池扩容补丁”，它是调度模型的切换——你得让阻塞调用真正被 JVM 挂起，而不是继续卡在平台线程上。
关键点在于：只有在 Thread.sleep()、BlockingQueue.take()、Socket.read()、Object.wait() 等 JVM 已知的挂起点，虚拟线程才会被自动 yield 并交出载体线程。如果你代码里混着自定义的 native 阻塞、JNI 调用、或未封装的 Unsafe.park()，虚拟线程照样会阻塞载体线程，失去意义。
- 优先使用标准 JDK I/O（如
Files.readString()、HttpClient）而非老式FileInputStream+BufferedReader手动循环读取 - 避免手动
synchronized块包裹长耗时逻辑；改用ReentrantLock.lockInterruptibly()或结构化并发作用域 - 数据库连接池必须支持虚拟线程——HikariCP 5.0+ 默认启用
allowPoolSuspension=true，而旧版或 Druid 需显式配置useUnfairLock=true且禁用连接泄漏检测的定时扫描
Spring MVC 还能跑虚拟线程吗？Tomcat 和 WebMvcConfigurer 怎么配
能跑，但默认不生效。Spring Boot 3.2+ + Tomcat 10.1.22+ 开始原生支持虚拟线程，但需主动开启——它不会自动把每个 HTTP 请求扔进虚拟线程，除非你明确告诉容器：“请用虚拟线程处理请求”。
关键配置项是 server.tomcat.threads.virtual.enabled=true（Spring Boot 3.2.7+），同时必须关闭传统线程池：server.tomcat.threads.max=0。否则 Tomcat 仍会先走平台线程池，再把任务转发给虚拟线程执行器，多一层调度反而更慢。
- WebMvcConfigurer 不需要重写任何方法；虚拟线程对 Spring MVC 是透明的，Controller 方法体内的所有阻塞调用（如
repository.findById()、restTemplate.getForObject()）都会被自动挂起 - 不要在 Controller 里手动
Thread.start()或ForkJoinPool.commonPool().submit()——这会绕过虚拟线程调度，退回到平台线程 - 日志框架需升级：Logback 1.5+ 或 Log4j2 2.20+ 才能正确打印虚拟线程名（如
VirtualThread[#34]/runnable@ForkJoinPool-1-1），旧版日志里看到的仍是 carrier 线程名，误导性极大
为什么加了虚拟线程后压测 QPS 反而下降？常见性能陷阱
最典型原因是“虚假并发”：你启了 10 万个虚拟线程，但底层数据库连接池只有 20 个连接，所有虚拟线程全卡在获取连接上，实际并行度还是 20。此时线程数暴涨，JVM GC 压力陡增，响应时间反而恶化。
虚拟线程降低的是线程调度开销，不是 I/O 瓶颈本身。它只是让你能更“奢侈”地为每个请求分配独立栈空间，但资源竞争点（DB 连接、Redis 连接、文件句柄、CPU 密集计算）没变。
- 检查
jcmd <pid> VM.native_memory summary</pid>中Internal区域是否暴涨——若超过 1GB，说明虚拟线程栈太多且未及时回收，可能是异步回调里忘了scope.close()或try-with-resources - 用
jstack -l <pid></pid>观察线程状态：大量VIRTUAL_THREAD PARKED是健康信号；若出现WAITING on java.util.concurrent.ForkJoinPool，说明载体线程被占满，需调大ForkJoinPool.commonPool().parallelism()（默认是 CPU 核数） - 同步日志、全局锁、静态 SimpleDateFormat 实例等“隐藏阻塞点”，在虚拟线程下会被放大——原来 200 个线程抢一个锁，现在 20000 个虚拟线程抢，锁争用指数级上升
要不要和 WebFlux 混用？Virtual Thread + Mono 的边界在哪
不建议混用。虚拟线程和 WebFlux 是两条不同路径：前者保留阻塞编程模型，靠 JVM 调度优化；后者彻底放弃线程绑定，靠数据流编排实现非阻塞。强行把 Mono.fromCallable(() -> blockingCall()) 丢进虚拟线程，等于给马套上火箭推进器——既没发挥 Reactor 背压优势，又浪费了虚拟线程的轻量调度能力。
真实项目中，边界很清晰：I/O 密集型、业务逻辑复杂、第三方 SDK 多为阻塞式（如老版本 Elasticsearch REST Client、PayPal SDK），选虚拟线程；纯网关、API 编排、事件驱动流水线、且生态已全面响应式（如 Spring Cloud Gateway、R2DBC），选 WebFlux。
- 已有 WebFlux 项目不必迁；已有 Spring MVC 项目，只要 JDK ≥21、Spring Boot ≥3.2，且无强依赖平台线程特性（如
ThreadLocal<securitycontext></securitycontext>未做适配），改造成本极低 -
StructuredTaskScope是虚拟线程的黄金搭档，替代CompletableFuture.allOf()；它能保证子任务生命周期受控，避免“幽灵请求”拖垮整个 carrier 线程 - 调试时别依赖 IDE 的“suspend thread”功能——虚拟线程暂停后可能被立即调度到其他 carrier 上，断点失效；改用
jdk.jfr.Event+ JFR 录制，观察VirtualThreadSubmit和VirtualThreadPinned事件
