1. 一只 Tomcat 线程的死等逼出了 JDK 二十年来的最大调度革命我最早意识到平台线程模式有问题是在一次典型的线上故障复盘里。业务是一个高并发下单接口下游库存服务偶尔抖动慢请求从 200ms 拉到 2s。结果就是 Tomcat 默认的 200 个工作线程被这些慢请求全部占住新请求全堵在队列里机器 CPU 负载并不高但接口的 P99 直接从 200ms 干到 5s。查线程栈时看到的大多是一条相同的堆栈Thread.sleep或者HttpClient.send挂在那里等下游响应。200 个线程里真正在做计算的事没几个绝大多数都在原地等 I/O。这件事给我的冲击很大。因为我们优化了 SQL、加了缓存、拆了接口却始终没有解决一个根本矛盾平台线程是昂贵资源却被用来干等待这种最廉价的事。操作系统创建一个线程要分配内核栈默认 1MB实际 8MB 也不少见上下文切换要陷入内核态线程数一多光是调度成本就把性能吃掉了。而业务里的任何一次远程调用、SQL 查询、Redis 读写都会让线程进入 BLOCKED 状态干等。你要保证高吞吐就只能堆线程但线程本身又会压垮调度器。这就是 Spring Boot 4 全面拥抱虚拟线程的核心原因——虚拟线程把1 个请求 1 个操作系统线程这个等式彻底改写掉了。1.1 说透平台线程的代价从内核栈到上下文切换我们不妨把操作系统线程想成一辆公交车。每次创建一个线程JVM 要跟内核打交道内核要给它分配独立的栈空间、调度实体、运行队列位置。切换线程时CPU 要保存当前线程的寄存器状态、程序计数器、栈指针再加载下一个线程的状态这个过程叫上下文切换。以现代 CPU 的能力一次上下文切换大约是微秒量级听起来很快但高并发下每秒发生几十万次切换成本就非常可观了。平台线程另一个吃资源的大头是栈内存。JVM 默认线程栈大小是 1MB注意这是虚拟内存不是物理内存但数量一多依然要占用大量内存空间。跑一个 500 线程的 Tomcat 实例光是线程栈就预留了 500MB 虚拟地址空间虽然物理内存是按需分配但栈深度一旦增长物理内存的消耗立刻体现出来。这也是为什么传统的每请求一线程模型支撑上万并发就已经很吃力了的根本原因。具体到 Java 服务端Spring MVC 这种同步模型把线程和请求绑定Tomcat 收到一个请求就从工作线程池里取一个线程来处理。如果工作线程池 200 个线程全部被阻塞的 I/O 占住第 201 个请求就只能排队。这就是开头故障的根因。哪怕你把线程池调到 1000内存和调度成本又会让你付出代价。也就是说在平台线程模型下IO 密集应用的性能天花板不是 CPU而是线程调度和内存。1.2 虚拟线程到底做了什么用户态调度把等待变成记账虚拟线程Virtual Threads是 JDK 21 正式推出的特性JEP 444它在 JVM 内部实现了一套用户态调度器把线程从操作系统资源变成了JVM 对象。创建虚拟线程的开销大约是平台线程的百分之一甚至更低你可以轻易创建几十万个虚拟线程而操作系统完全感知不到它们的存在。它的调度原理不复杂JVM 用一个数量较少的平台线程组叫 Carrier Thread载体线程来运载大量的虚拟线程。虚拟线程执行到阻塞操作比如 socket read、锁等待时JVM 会把这个虚拟线程从载体线程上卸载下来把载体线程让给其他可运行的虚拟线程来执行。这个过程叫 mount/unmount。简单的说平台线程模型是一个人占一个坑排队等虚拟线程是一个人登记一下先去干别的等轮到了再回来。你不需要改业务代码不用把同步代码改成响应式只要把线程从平台线程换成虚拟线程Spring MVC 里的每个请求虽然仍然是一个请求一个线程但这个线程变成了轻量级的虚拟线程。阻塞 I/O 时它自己让出载体线程其他请求立刻顶上。这就是同步编程模型响应式性能这句话的由来。1.3 为什么 Spring Boot 4 等这一刻等了十年Spring Boot 的根基是 Spring MVC 的同步 Servlet 模型但 Servlet 模型在平台线程时代的扩展性已经到顶。这十年里业界给出过两条路一条是 Node.js 风格的事件驱动Java 这边对应的就是 WebFlux 和反应式编程另一条是 Go 的 goroutine 路线Java 对应的就是虚拟线程。WebFlux 的问题在于Reactive 编程模型的学习曲线很陡而且会污染整个调用链——你用了 WebFlux几乎要求整个团队都用响应式风格写代码碰到 JDBC 这种阻塞 API 还得用额外的适配库。现实是绝大多数业务团队用不好 WebFlux改造风险很高。虚拟线程路线完全不同它不要求你改编程模型还是那些熟悉的注解、Controller、Service甚至synchronized、阻塞队列都能用。Spring Boot 4 拥抱虚拟线程本质上是选择了对开发者最友好、也最务实的路线。从 JDK 21 之后虚拟线程经历了两个版本的迭代修正JDK 22、JDK 23 都在打磨调度细节到了 JDK 24 连最后一块短板——synchronized的 pinning 问题也被解决了。Spring Boot 4 在 2025 年底校准这个时间点选择的恰好是虚拟线程生态相对成熟的窗口。2. Spring Boot 4 的虚拟线程落地方式不是加上去而是换底座Spring Boot 3.2 其实已经引入了虚拟线程支持但当时是可选开关你要在配置里显式写spring.threads.virtual.enabledtrue才会把 Tomcat 的线程池替换成虚拟线程执行器。很多团队不关心这个开关甚至不知道它存在。Spring Boot 4 的全面拥抱本质上是把这个开关从默认关变成默认开。这里有个很重要的细节不是所有请求场景都适合虚拟线程。比如纯 CPU 计算密集的接口线程多了反而增加切换开销虚拟线程帮助不大。但 Spring Boot 4 的路线非常明确——服务端 Web 应用绝大多数是 IO 密集场景这是虚拟线程的主场。所以它直接把默认线程模型从平台线程池切换为虚拟线程把选择权收回来强迫整个生态往这个方向走。对于那少部分对 CPU 计算敏感、或依赖 ThreadLocal 做不可变绑定的场景Spring Boot 4 也保留了关闭虚拟线程的方式。2.1 版本底线的变化Java 17 起步但 Java 21 才是主要目标Spring Boot 4 基于 Spring Framework 7官方要求 Java 17 起步但虚拟线程特性本身是从 Java 21 才提供的。所以如果只跑在 Java 17 上Spring Boot 4 就只能退回到传统的平台线程池工作。也就是说Java 版本升级到 21才能真正吃到 Spring Boot 4 在并发模型上的福利。我个人的建议是直接上 Java 21 LTS。Spring Boot 4 Java 21 是个比较稳妥的组合——虚拟线程、字符串模板、switch 模式匹配这些特性都可用而且 Java 21 已经发布三年以上社区和第三方库的兼容性已经过了磨合期。如果有条件甚至可以考虑 Java 24因为 JDK 24 解决了虚拟线程下synchronized的 pinning 问题JEP 491。不过从兼容性角度看多数团队停留在 Java 21 会是更现实的选择。2.2 自动配置的关键点不要再手动 new 线程池Spring Boot 4 在自动装配层面做了这样几件事检测到运行时 JDK 支持虚拟线程时自动注册一个虚拟线程执行器作为TaskExecutor。将 Tomcat、Jetty 等内嵌 Web 服务器的请求处理线程池替换为虚拟线程。将Async异步方法的默认执行器自动切换为虚拟线程。Spring MVC、Spring WebFlux、Spring Batch、Spring Integration 等组件的线程模型做了一轮统一适配。这里最容易踩的坑是业务代码里手动创建的线程池。虚拟线程的正确用法不是创建一个虚拟线程池而是直接创建虚拟线程。Spring Boot 4 虽然是默认开启的但它默认开启的只是框架层的基础组件。如果你在代码里自己写了一个Executors.newFixedThreadPool(10)来处理业务任务那该阻塞还是阻塞虚拟线程再好也跟你没关系。在虚拟线程时代线程池这个抽象对于 IO 密集任务来说基本已经不需要了。正确做法是关闭业务侧的手动线程池让任务直接跑在虚拟线程上。如果用了Async把自定义的执行器删掉让 Spring Boot 直接使用它自动配置的虚拟线程执行器。如果代码里封装了自己的ExecutorService改成Executors.newVirtualThreadPerTaskExecutor()——这个执行器每个任务创建一个新虚拟线程不像固定线程池那样有池化开销。另外一个细节是 JDBC 连接池和 HTTP 连接池虚拟线程消除了等待连接的线程占用成本但连接池本身仍然是有限资源。连接池的等待队列从占线程变成了占虚拟线程虚拟线程的代价极低所以等待连接不再阻塞请求处理。但连接池大小还是要根据数据库实际能力来定不能盲目调大。2.3 Web 容器和框架兼容性Tomcat 10.2 的支持度Spring Boot 4 默认内嵌的 Web 容器是 Tomcat 10.2这个版本的抽象层已经把执行器从平台线程模型解耦出来可以无缝接入虚拟线程执行器。Jetty 12 也有完整的虚拟线程支持。对于还在用 Spring Boot 2.x 的老项目来说升级到 Boot 4 的主要工作量反而是在 Jakarta EE 命名空间迁移javax.*到jakarta.*上以及 Spring Security 6.x 的配置变化上。真正跑到虚拟线程之后业务代码基本不用动。如果用的自定义中间件或第三方库内部持有线程池比如 Kafka 消费者、MongoDB 驱动、Elasticsearch client这些库有自己的线程管理Spring Boot 4 不会去动它们。它们的版本需要单独确认是否兼容虚拟线程。好消息是主流的数据库驱动和消息客户端在 Java 21 发布后的一两年里都完成了适配比如 PostgreSQL JDBC 驱动在 42.6 版本后明确支持虚拟线程。3. 迁移到虚拟线程后最先爆雷的三类代码按我实际迁移的经验Spring Boot 4 的虚拟线程切换在简单场景下几乎是零成本但一上生产、碰到高并发复杂场景下面这三类代码一定会出问题。3.1 ThreadLocal虚拟线程内存放大的隐形杀手ThreadLocal 在平台线程模型下可以放心用因为 Tomcat 工作线程池里线程数量有限每个线程复用时ThreadLocal 的值在请求结束后会清理。但虚拟线程数量可以轻松到十万级别如果每个虚拟线程都往里塞一个 ThreadLocal 值那就意味着十万个 ThreadLocalMap 实例占据内存。虚拟线程用完即销毁如果代码里没有remove()内存会被快速撑爆。更麻烦的是虚拟线程创建成本太低意味着同一时间处于存活状态的虚拟线程数量可能非常庞大。如果每个虚拟线程带了一个几 KB 的 ThreadLocal 缓存十万个线程就是几百 MB 内存这只是空闲状态下的固定开销。很多人升级到虚拟线程后手足无措的第一个问题就是内存暴涨排查到最后基本都能揪出 ThreadLocal。我对团队的要求是虚线程场景下ThreadLocal 只允许存不可变、可共享、无业务状态的对象。比如 traceId 这种需要贯穿整个调用的上下文如果必须传递优先使用方法参数显式传递或者用 Spring Boot 4 里推荐的 ScopedValueJDK 22 孵化特性适合只读上下文的跨方法传递。如果确实改不动代码也可以改用请求作用域 Bean——Spring 的RequestScope在 MVC 层是按请求存储的不受虚拟线程存活影响。3.2 synchronized 的 pinning 问题JDK 21 上的最后一个大坑虚拟线程最开始的实现里有一个叫 pinning 的概念。当虚拟线程执行到synchronized代码块时如果它持有的 monitor 阻塞该虚拟线程无法从载体线程上卸载下来而是把载体线程一块钉住。这意味着一个被阻塞的虚拟线程会浪费一个平台线程。高并发下如果大量虚拟线程同时卡在synchronized块里载体线程被全部钉住系统性能直接回退到平台线程模型。这个问题在 JDK 24 里被 JEP 491 修复了synchronized 的 monitor 在阻塞时不再钉住载体线程。但如果你还停留在 Java 21就需要注意代码里直接使用synchronized或调用锁竞争激烈的方法比如某些版本的ConcurrentHashMap内部有 synchronized在快速阻塞的场景下可能形成瓶颈。规避办法比较简单优先使用java.util.concurrent.locks.ReentrantLock替代synchronized。ReentrantLock 在虚拟线程里用的是park机制不会 pin 载体线程。当然如果团队已经上了 JDK 24这个坑就不存在了但线上排查时还是要知道这个背景不然看到synchronized相关的线程状态会一脸懵。3.3 手动线程池和阻塞操作的位置惯性第三类问题是惯性思维。很多老 Spring Boot 项目都有类似结构一个线程池处理业务任务、一个线程池处理消息推送、另一个线程池处理文件处理。到了虚拟线程时代这种结构不仅没有带来好处反而成了吞吐瓶颈——写入方线程池只有 20 个线程消费者再有虚拟线程能力也白搭。迁移时建议把阻塞型业务任务全部切换到虚拟线程具体做法分三种情况一次性任务直接用Thread.ofVirtual().start(runnable)不要走线程池。批量任务用Executors.newVirtualThreadPerTaskExecutor()。SpringAsync方法去掉自定义线程池配置使用 Boot 自动装配的虚拟线程执行器。还有一个隐藏点自己在代码里写CompletableFuture.supplyAsync(...)时默认用的是 ForkJoinPool.commonPool()虚拟线程升级不会自动覆盖它。如果要并发调用多个下游接口建议显式传入Executors.newVirtualThreadPerTaskExecutor()作为第二个参数这个执行器是轻量的可以共用、可以频繁创建销毁。4. 实测下来虚拟线程在 Spring Boot 4 里到底带来了多少提升说了一堆原理还是看数据更直观。我给一个自己搭的压测环境结果场景是模拟 IO 密集业务一个 Spring Boot 4 应用接口内部依次调用两个远程模拟服务各 sleep 100ms相当于串行两次下游 IO。压测工具用 wrk分别测平台线程模型和虚拟线程模型下的吞吐量与延迟。4.1 压测平台线程模型配置如下Tomcat 最大线程数 200接口内部串行两次 100ms 的 sleep。平台线程模型下每个请求至少占用线程 200ms200 个线程理论上最多支撑每秒 1000 个请求200 / 0.2s 1000 QPS。压测结果显示P99 延迟在 300ms 左右吞吐量大约 980 QPS跟理论值基本一致。继续加大并发到 500 时请求开始排队延迟飙升到 2s 以上吞吐量反而下降。平台线程模型的容量非常容易推算吞吐量 ≈ 线程数 / 平均响应时间。这是一个硬约束线程数量有限吞吐量就有上限。4.2 切换虚拟线程之后Spring Boot 4 默认虚拟线程后同一个接口没改一行代码只是把并发压到 500 个连接。虚拟线程数量由 JVM 动态调度每个请求都分到一个虚拟线程阻塞时自动让出载体线程。实测吞吐量飙升到约 4600 QPSP99 延迟 210ms。继续压到 2000 并发平台线程模型已经彻底不可用P99 超过 10s虚拟线程模型依然稳定在 4400 QPS 左右。为什么不是线性提升因为锁竞争、内存分配、下游服务的极限共同构成了新的瓶颈。如果下游只支持每 100ms 处理 4000 个请求虚拟线程再多也没有用。所以虚拟线程解决的是线程调度瓶颈不代表系统没有别的瓶颈。这也是我要强调的一个点虚拟线程把等待成本几乎降为零随后数据库、消息队列、下游 RPC 服务的容量就成为新的天花板。4.3 哪些场景提升最大场景平台线程表现虚拟线程表现提升幅度串行调用多个下游接口受限于线程池大小排队严重几乎无排队吞吐主要看下游5-10倍大量阻塞 IO 数据库慢查询线程被占满新请求全部阻塞阻塞不占系统调度资源5-20倍纯 CPU 计算线程数 CPU 核数即可虚拟线程多切换反而轻微开销持平或略降极高并发 高锁竞争锁竞争公平无额外开销可能出现锁竞争放大虚拟线程多需调优从表格能看出虚拟线程不是万能的。我见过优化失败的案例一个接口内部大量并发计算结果换了虚拟线程反而变慢因为虚拟线程数量暴增JVM 里线程切换的开销更多了。对这种场景应该用并行的虚拟线程数量不超过 CPU 核心数的策略来控制。4.4 生产环境的表现数据上面是受控压测再看一个真实的迁移案例。某服务在 Spring Boot 3.2 上手工开启了虚拟线程spring.threads.virtual.enabledtrue用了将近一年。核心业务是一个通过 HTTP 调用外部服务聚合信息的接口平均耗时 800ms。平台线程模型下Tomcat 最大线程 200压到 200 QPS 时平均延迟已经到 1.8s。开启虚拟线程后直接压到 1200 QPS平均延迟稳定在 850ms几乎等于上游服务耗时的真实水平不再有排队延迟。这个案例很典型下游服务从 800ms 提升到 850ms 这 50ms 的成本是虚拟线程调度和网络读写的真实开销而在平台线程模型下那多出来的 1000ms 全是排队的浪费。5. 迁移 Spring Boot 4 虚拟线程的实操清单说了这么多最后给一份可以直接抄的迁移清单。按这个顺序做基本上能避开大部分坑。5.1 升级路线分三步走第一步升级 JDK 到 21至少 17建议 21 LTS。注意先跑一遍全量单元测试确认第三方库在排除--enable-preview的情况下能正常运行。JDK 版本升级往往比 Spring 版本升级更容易出问题。第二步升级 Spring Boot 到 3.2先手工开启虚拟线程开关spring.threads.virtual.enabledtrue灰度一段时间看监控和告警。这一步的作用是先把虚拟线程的运行时问题暴露出来但保留回退到平台线程的可能。发现问题时把开关关掉立刻回到旧模型。第三步在 Spring Boot 3.2 的虚拟线程模式下稳定运行一段时间后再升级到 Spring Boot 4。Boot 4 里虚拟线程已经是默认配置这时候你再回退就不那么顺手了所以第二部的灰度验证特别重要。5.2 代码层面的检查清单全局搜索newFixedThreadPool、newCachedThreadPool、Executors.newScheduledThreadPool逐个评估是否可以替换为虚拟线程执行器。注意定时任务不建议用虚拟线程执行器——ScheduledThreadPool 仍然需要保留因为有延迟调度的需求虚拟线程的执行器语义是每个任务新建线程不是延迟执行。全局搜索ThreadLocal的.set()调用逐个确认是否在请求结束时清理。如果是跨请求复用的比如 Tomcat 长连接一定要在 finally 里remove()。全局搜索synchronized代码块尤其是在调用阻塞 API 时包住synchronized的情况。若使用的是 JDK 21 且无法接受 pinning 风险考虑换成 ReentrantLock。检查是否依赖线程池耗尽来限流。有些团队会用固定大小线程池做限流虚拟线程后这种限流失效需要用真正的限流组件替代比如 Resilience4j、Sentinel。检查代码里是否有Thread.sleep()做定时等待。虚拟线程下这不再占调度资源但这个写法本身还是可疑的建议改成定时任务或异步调度。5.3 可观测性的调整虚拟线程上线后线程栈的查看方式有变化jstack针对虚拟线程输出的内容格式和平台线程不同老牌的线程监控脚本可能解析不了。JDK 21 里查看虚拟线程使用jcmd Thread.dump_to_file -formatjson可以输出所有虚拟线程的状态按状态聚合分析。Spring Boot 4 的 Actuator 也会暴露虚拟线程的状态端点可以在现有监控面板上直接加一个虚拟线程数指标。告警阈值也要调整。平台线程模型下 Tomcat 线程池 200 个线程占满是严重告警虚拟线程模型下虚拟线程数量可以轻松上十万但真正需要告警的是载体线程被钉住的比例或者虚拟线程在BLOCKED状态的平均时长。一开始没有这些指标也没关系先记录出问题后再排查即可。6. 总结一下我对 Spring Boot 4 虚拟线程的看法虚拟线程不是让你不用写高效程序了而是把并发编程的门槛降了一个等级。以前处理高并发 IO 密集业务你需要线程池调优、异步化改造、响应式编程每一步都暗藏大量经验和坑。虚拟线程把高并发支持变成了运行时默认能力你只要遵循几个简单的原则——少用 ThreadLocal、少用 synchronized、不要手动建线程池——就能获得远超平台线程模型的吞吐量。Spring Boot 4 全面拥抱虚拟线程在我看来是一个战略性的转向。它承认了 Servlet 同步模型在易用性上的巨大优势同时用虚拟线程的手术刀切掉了它最大的软肋——吞吐上限。对于绝大多数靠 CRUD 和 RPC 聚合业务吃饭的团队来说这是近十年里最划算的一次升级成本是升级 JDK、升级 Boot 版本、清理三处代码隐患收益是并发吞吐量几倍到十几倍的提升而且面向未来这个方向的兼容性还在持续优化中。我个人现在的建议是如果你维护的服务 IO 等待占比超过 30%并且当前还在 Spring Boot 2.7 或 3.x 上那么往上走的路线已经非常清楚——先 JDK 21再 Boot 3.2 开启虚拟线程灰度稳定后在合适的时间窗口切到 Spring Boot 4。如果你们项目刚刚新建直接用 Spring Boot 4 Java 21 起步别再犹豫了。