先交代一下背景我负责的API网关服务之前一直是 Java 17 Spring Boot 3.1 的配置Tomcat 默认线程池跑得好好的单机压测 QPS 卡在 3000 左右延迟曲线虽然有点锯齿但基本可控。直到公司要求 Java 21 升级我也顺手续了 Spring Boot 3.5看到官方文档里“启用虚拟线程”只差一行配置心想着这波白捡性能结果上线前压测直接把网关压崩了CPU 飙到 100%请求大面积超时最后带着一堆线程转储回去加班排查。这篇文章就是那次事故的完整复盘把虚拟线程与传统线程池在网关场景里如何“互相打架”的事故现场、原理拆解、修复步骤和配置模板都写清楚。如果你也在 Java 21 Spring Boot 的升级路线中或者正在犹豫要不要打开虚拟线程开关这篇文章值得看完再动手。1. 升级背景为什么要把网关迁到虚拟线程1.1 虚拟线程到底强在哪里先说虚拟线程解决了什么问题。传统平台线程是 1:1 映射操作系统线程创建成本高、切换成本更高所以 Java 应用一直靠线程池来复用线程。而线程池一旦满新任务只能排队排队意味着阻塞阻塞意味着延迟上升。网关这类服务大量时间花在等待下游 HTTP 响应、等待数据库连接、等待 Redis 返回上真正的 CPU 计算时间可能只占很小一部分。平台线程在这种“大部分时间都在等”的场景里效率极低。虚拟线程把线程变成了 JVM 管理的轻量级对象一个平台线程可以承载无数个虚拟线程阻塞时 JVM 自动把你的虚拟线程从载体线程上卸下来载体线程继续去跑别的虚拟线程。这就让“每个请求一个线程”的模型变得可行不需要再绞尽脑汁去压榨线程池大小。对于 IO 密集型的网关服务理论上吞吐量能提升好几倍因为这彻底消除了“线程数不够用”的瓶颈。当初我就是被这句话打动了才动了全量开启的心思。这个原理本身没问题问题出在我只想到了入口线程的模型改变完全没去审视下游组件、连接池、线程池这些基础设施是不是真的能配合虚拟线程工作。踩坑之后我才意识到虚拟线程不是“Spring Boot 的开关”而是“全链路并发模型的重新设计”。1.2 Spring Boot 3.x 启用虚拟线程的三种方式Spring Boot 从 3.2 开始正式支持虚拟线程启用方式有三种我分别列一下第一种配置文件方式在 application.yml 里加spring: threads: virtual: enabled: true这是最推荐的方式。Spring Boot 检测到 Java 21 环境后会自动把 Tomcat 或 Jetty 的请求处理线程切换为虚拟线程。如果你用的不是 Tomcat而是 Spring Cloud Gateway 底层的 Netty这个配置项同样适用会让 Netty 的事件循环拿到的任务在虚拟线程里执行。第二种编程式方式在 main 方法里调用SpringBootApplication public class GatewayApplication { public static void main(String[] args) { SpringApplication app new SpringApplication(GatewayApplication.class); app.setVirtualThreads(true); app.run(args); } }这种方式适合需要动态判断环境再决定是否开启的场景比如本地开发关掉、压测环境打开。第三种只给特定业务开启不动全局请求线程。注入一个ThreadFactory然后基于它创建 ExecutorServiceBean public AsyncTaskExecutor applicationTaskExecutor() { return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor()); }这适合你只想让某些异步任务跑在虚拟线程上但不想影响 HTTP 容器已有的线程模型的情况。不过我后来复盘时发现这种“局部开启”方式容易埋雷因为虚拟线程创建的并发任务没有上限一旦某个业务场景没做好隔离照样能把系统拖垮。具体坑在哪下一节用事故现场来拆。2. 压崩现场虚拟线程与传统线程池的冲突根源2.1 第一轮压测吞吐上去了延迟却飙升升级配置后我先在本地跑了一轮简单压测接口是一个标准的网关转发逻辑收到请求拼参数调用下游订单服务拿结果返回。输入输出都不大下游服务我用 Mock Server 模拟固定延迟 30ms。压测工具用的 wrk20 个线程、2000 连接压了 1 分钟。结果很有意思QPS 从原来的 3000 直接冲到了 11000热呼呼的吞吐提升我当时差点就点了“发布上线”按钮。但仔细看延迟分位数P99 从原来的 85ms 涨到了 450msP999 已经超过了 1.5s。更离谱的是后半段压测时Tomcat 的活跃连接数冲到了 7000 多GC 频率肉眼可见地加快整个服务的响应时间像过山车一样一下子 50ms、一下子 1000ms剧烈抖动。这时候千万别以为是“正常现象”。对一个网关来说吞吐升高但延迟恶化往往意味着资源已经出现瓶颈只是还没完全崩溃而已。我立刻停掉压测去翻线程堆栈和指标发现了一个之前完全没料到的现象大量虚拟线程并不像预期那样“挂了就卸下来”而是集体卡在某个线程池的任务队列里。这就是虚拟线程被“池化”之后造成的极度反直觉的坑。2.2 事故元凶一你把虚拟线程塞进了小线程池看线程转储的时候我发现了大量这样的堆栈Thread-123 virtual java.lang.Thread.parkNanos(java.base21/Thread.java:600) java.util.concurrent.locks.LockSupport.parkNanos(java.base21/LockSupport.java:253) java.util.concurrent.SynchronousQueue$TransferQueue.awaitFulfill(...) java.util.concurrent.SynchronousQueue.transfer(...) java.util.concurrent.ThreadPoolExecutor.execute(...) ...翻译一下就明白了我们的网关转发下游调用时并不是直接发起 HTTP 请求而是经过了一个自己封装的路由组件组件内部用了一个固定大小的线程池初始配置是核心线程数 40、最大线程数 40队列用的是 SynchronousQueue。原来在平台线程时代这个设计很合理下游服务的核心线程数有限网关不能无限发请求过去40 个线程加上排队机制刚好能保护下游。问题在于开启虚拟线程后Tomcat 接收请求的线程变成了虚拟线程虚拟线程数量瞬间可以开到几千。每一个进入网关的请求最终都要把任务提交到这个只有 40 个线程的线程池里。结果就是几千个虚拟线程全部阻塞在ThreadPoolExecutor.execute()的入队环节等待线程池里的线程空闲出来。虚拟线程节约的上下文切换开销又全部变成了线程池内部锁竞争和排队等待。更隐蔽的是虚拟线程被阻塞在线程池队列上的时候它的载体线程并没有被释放。因为ThreadPoolExecutor.execute()里有全局锁mainLock所有线程都在争抢这个锁往队列里塞任务于是 CPU 很快就满了网关进入了“看起来线程很多、实际能干活的一个都没有”的假死状态。这件事给我的教训是虚拟线程让“线程数”不再是稀缺资源但你的代码里如果还存在“固定大小线程池”这种中间层它就会成为新的瓶颈。虚拟线程并不是要消灭线程池而是要把线程池从“任务执行层”退位到“资源保护层”。2.3 事故元凶二连接池成了新的瓶颈点第二个元凶就藏在连接池里。我们的网关有两个核心连接池一个是 MySQL 的 HikariCP 连接池另一个是下游 HTTP 调用的连接池用的是 Apache HttpClient默认每个路由最多 5 个连接总共 20 个连接。在平台线程时代Tomcat 默认 200 个线程最多 200 个并发请求同时执行连接池虽然有等待但不至于把系统拖垮。开启虚拟线程后Tomcat 同时处理的请求变成了几千个。每个请求在处理过程中都要从 HikariCP 获取一个数据库连接HikariCP 的 maximumPoolSize 当时配的是 10连接不够用时调用方会阻塞等待。原来的平台线程模型下最多只有 200 个线程在阻塞等待连接虚拟线程模式下可能有 3000 个虚拟线程同时阻塞在HikariCP.getConnection()上。每个阻塞等待者都持有各自的调用栈、请求参数、响应对象几百兆的堆内存瞬间就被吃光了Full GC 一个接一个地来。HikariCP 的内部实现里有一个公平锁来维护连接分配队列连接池越小、等待线程越多这个锁的竞争就越激烈。压测时甚至能看到 CPU 的火焰图里HikariCP$ConnectionPool.getConnection占了接近 40% 的采样时间。也就是说虚拟线程把并发能力提上来了但连接池的容量没有跟着提上来于是瓶颈从“线程不够”变成了“连接不够”。修复思路其实很清楚要么把连接池调大要么给虚拟线程做并发限流否则连接池在超高并发下一定会成为最短的那块木板。更干净的做法是直接减少对连接池的依赖比如下游调用改为非阻塞式 HTTP 客户端但这是后话我放在修复部分详细说。3. 关键决策虚拟线程、传统线程池与阻塞队列怎么选3.1 一张表看清虚拟线程的适用边界经历过这次事故我后来在组内分享时画过一张表直接给虚拟线程划分了适用边界场景虚拟线程是否合适原因网关转发、RPC 调用、数据库访问适合线程大部分时间在等待 IO虚拟线程能腾出载体线程纯 CPU 计算、加密解密、压缩不适合没有阻塞等待虚拟线程没有任何收益反而增加调度开销大量 synchronized 同步块谨慎虚拟线程进入同步块后阻塞时可能 pin 住载体线程导致载体线程被占死调用 native 方法或 JNI不适合JVM 无法在 native 方法处让出载体线程虚拟线程会直接 pin 住平台线程无界线程池 无界队列堆积危险虚拟线程数量几乎无上限积压任务时会拖垮整个 JVM其实核心就一句话虚拟线程的价值建立在“线程经常阻塞、阻塞代价高昂”这个前提上。如果你的任务里根本没有阻塞或者阻塞发生在 synchronized 块和 native 调用里那虚拟线程不仅帮不上忙反而会成为负担。网关场景最容易踩的就是中间那位“大量 synchronized 同步块”。很多老项目里日志输出、度量上报、本地缓存更新都会用 synchronized 做保护少量并发看不出来虚拟线程并发量一上来一旦某个虚拟线程在 synchronized 块里执行了阻塞操作比如打印日志时 IO 抖动它会把载体线程一起按住其他虚拟线程统统没有载体线程可用。排查这种问题特别讨厌因为线程转储里看状态都是 RUNNABLE压根看不出是谁造成了阻塞。3.2 线程池阻塞队列选型从 SynchronousQueue 到 ArrayBlockingQueue既然提到传统线程池就绕不开阻塞队列的选型。很多人配 ThreadPoolExecutor 只盯核心线程数和最大线程数完全忽略了队列类型才是决定线程池行为的关键因素。我整理一下四种常见队列在网关场景下的表现SynchronousQueue队列容量为 0任务不会排队要么直接交给空闲线程执行要么直接触发拒绝策略。它适合“让所有任务立即尝试执行”的场景但如果线程数固定并发一上来就会频繁触发 CallerRunsPolicy 或 AbortPolicy。我事故里那个 40 线程池就是它的典型误用本来是保护下游的结果变成拦路虎。LinkedBlockingQueue默认无界队列可以无限增长。如果你不希望丢任务它就是“看起来最安全”的选择但也是最危险的。网关下游服务挂掉时任务会在队列里越积越多内存被无界队列全部吃掉直到 OOM。我见过不止一次因为无界队列导致的线上事故所以网关这类对延迟敏感的服务坚决不推荐无界队列。ArrayBlockingQueue有界队列容量用代码明确指定。队列满了之后走拒绝策略再配合合理的线程数可以有效防止任务无限堆积。这是网关线程池里最实用的方案。PriorityBlockingQueue无界优先队列按优先级出队适合有业务优先级区分的场景但同样有 OOM 风险网关里基本用不上。经验总结就是网关的线程池队列要么用 ArrayBlockingQueue要么直接用 SynchronousQueue 配合较大的最大线程数绝对不要因为“怕丢请求”就去用无界队列。丢请求总比整个服务 OOM 强。3.3 网关场景下的 Server 容器与编程模型搭配这次事故还暴露了一个更基础的问题网关的 Server 容器选型直接决定了你开启了虚拟线程会不会有效果。如果你的网关是基于 Spring MVC 构建的默认容器是 Tomcat开启虚拟线程后 Tomcat 会用虚拟线程处理请求。因为 Spring MVC 是阻塞式模型代码里大量调用RestTemplate.getForObject()或block()这类阻塞方法虚拟线程恰好能把阻塞等待的浪费抹平所以这个组合是成立的只要把下游的连接池和线程池处理好。如果你的网关是 Spring Cloud Gateway底层是 WebFlux 和 Netty情况就变了。Netty 本身是非阻塞事件循环模型线程模型和虚拟线程是有冲突的。Spring Cloud Gateway 的过滤器里如果调用了阻塞式 API比如 JDBC、RestTemplate这些阻塞调用发生在 Netty 的 event loop 线程上会让整个 event loop 卡住比传统线程池的阻塞严重得多。开启虚拟线程后这个卡顿只是被转移到了虚拟线程上并没有解决根本问题。所以在网关场景里我的建议是如果团队用的是 Spring MVC 风格可以放心开启虚拟线程但要同步改造线程池和连接池如果团队用的是 Spring Cloud Gateway 这种响应式架构第一选择永远是保持全链路非阻塞而不是靠虚拟线程去兜底阻塞调用。把 WebFlux 的代码改成阻塞式然后用虚拟线程等于放弃响应式的所有优势换来一个不伦不类的模型。4. 实操修复从崩溃到稳定的完整过程4.1 第一步把入口切换到虚拟线程但做并发限流压测崩过一次之后我没有退回到 Java 17而是把这次升级当作一次全链路并发模型重构来做。第一步是保留虚拟线程入口不再把虚拟线程当作“无限并发”的许可而是给它加上明确的并发闸门。入口层要做两件事。第一确认spring.threads.virtual.enabledtrue已经全局打开让 Tomcat 用虚拟线程处理请求。第二引入信号量做并发限流限制同时处理的请求数量防止虚拟线程失控式增长Configuration public class GatewayConcurrencyConfig { // 根据压测结果估算单机能稳定处理的并发请求上限 private final Semaphore requestSemaphore new Semaphore(800); Bean public FilterRegistrationBeanOncePerRequestFilter concurrentLimitFilter() { FilterRegistrationBeanOncePerRequestFilter registration new FilterRegistrationBean(); registration.setFilter(new OncePerRequestFilter() { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { if (!requestSemaphore.tryAcquire(2, TimeUnit.SECONDS)) { response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value()); return; } try { chain.doFilter(request, response); } finally { requestSemaphore.release(); } } }); registration.addUrlPatterns(/*); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); return registration; } }这里的思路是虚拟线程保证了入口并发能力足够高但信号量保证下游同时面对的真实负载是可控的。800这个数字不是拍脑袋定的而是先关了限流压测观察下游连接池稳定工作的最大并发数再留 20% 余量定出来的。后续你完全可以按自己的压测结果调整。4.2 第二步用信号量替代线程池做下游隔离入口限流只是保护了网关自身还不能解决“固定线程池 虚拟线程”互相打架的问题。我本来想直接把那个 40 线程的线程池调大比如调到 200但仔细一想这根本没有解决问题只要线程池大小是固定的并发超过它就必须排队只要排队虚拟线程就会堵在入队环节。所以我把这个中间层从“任务线程池”直接换成了信号量。下游调用不再通过 ExecutorService 提交任务而是直接在当前虚拟线程里执行但用信号量控制同时发往下游的请求数量Component public class DownstreamCaller { private final Semaphore downstreamSemaphore new Semaphore(300); private final RestTemplate restTemplate; public DownstreamCaller(RestTemplate restTemplate) { this.restTemplate restTemplate; } public String callDownstream(String url) { if (!downstreamSemaphore.tryAcquire(1, TimeUnit.SECONDS)) { throw new TooManyRequestsException(downstream overloaded); } try { // 直接在当前虚拟线程执行不经过固定线程池 return restTemplate.getForObject(url, String.class); } finally { downstreamSemaphore.release(); } } }这样改造的好处是虚拟线程的并发能力被信号量约束在可控范围内不再有队列堆积的 OOM 风险也不会有几千个线程同时堵在ThreadPoolExecutor.execute()上抢锁。信号量本身是 JVM 内置实现使用 LockSupport.park阻塞虚拟线程时能让出载体线程性能和并发能力都远好于线程池排队。如果你不想完全去掉线程池还有一个折中方案线程池本身改用虚拟线程工厂即“虚拟线程池”。但注意虚拟线程池的核心线程数上限最好等于下游能承受的最大并发数不要再用几百几千否则等于又开了一道无底洞。我实测下来信号量方案比虚拟线程池更简单直接也更不容易被误配置。4.3 第三步连接池参数按虚拟线程特性重新调优去掉中间的固定线程池后连接池的调优反而变得更重要了。虚拟线程模式下同时阻塞在连接池上的线程数可能成千上万连接池内部锁竞争异常剧烈。连接池不是越大越好它必须适配下游数据库的真实处理能力、数据库连接的内存占用和网络带宽。HikariCP 的参数我是这样调的spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 2000 validation-timeout: 500 idle-timeout: 300000 max-lifetime: 1200000connection-timeout从默认的 30 秒急速下降到 2 秒这个调整很关键。虚拟线程模式下如果连接池耗尽与其让几千个虚拟线程在等待连接上反复 park/unpark不如快速失败、把请求打到备用链路或者直接返回 429。连接池本身是资源保护层它应该尽早暴露压力而不是无限期拖住调用方。HTTP 连接池我用的 RestTemplate底层是 Apache HttpClient调了这几个关键参数# HttpClient 连接池配置代码里对应成 Config maxConnectionsPerRoute: 300 maxConnectionsTotal: 500 connectTimeout: 1500ms socketTimeout: 5000ms connectionRequestTimeout: 1000ms注意connectionRequestTimeout这个参数特别容易漏。它控制的是“从连接池请求一个连接”的等待时间不设置的话连接池耗尽时请求会无限等下去压测时表现就是一批请求全部卡死在获取连接上表现和之前 HikariCP 的等待一模一样。给连接池请求也加上超时才算把整个链路都收口了。4.4 最终配置模板与压测数据完整修复后我的网关配置长这样拿出来直接抄也没问题spring: threads: virtual: enabled: true datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 2000 validation-timeout: 500 idle-timeout: 300000 max-lifetime: 1200000 server: tomcat: max-connections: 6000 accept-count: 200 threads: max: 0这里server.tomcat.threads.max: 0是一个细节当虚拟线程开启时Tomcat 的线程数配置默认被忽略显式写成 0 是为了提醒后续维护者“这个参数已经不起作用了别再往这里找线程池问题”。max-connections和accept-count依然有效它们控制的是 TCP 连接层的积压能力虚拟线程模式下同样要注意连接数超了会先在这里排队。压测验证结果我记录一下同样的 wrk 压测参数QPS 稳定在 9500 左右比出问题时略有下降但 P99 降到了 78msP999 降到 210ms全程 GC 频率正常没有一次 Full GC。和最初“吞吞吐量但延迟爆炸”的状态相比这个结果才是真的可用状态。吞吐没有虚高但延迟曲线全程平缓我认为对网关来说延迟稳定比极限 QPS 更重要毕竟真正压垮系统的从来不是某个高 QPS 数字而是不可控的延迟引起调用链雪崩。5. 常见问题排查与避坑清单5.1 故障速查表把这些天踩过的坑全部汇总成一张速查表排查时直接对着看症状可能原因排查手段解决方案开启虚拟线程后 CPU 飙高ThreadPoolExecutor 入队锁竞争、synchronized pinningjstack 看 RUNNABLE 线程栈去掉中间固定线程池换信号量吞吐升高但 P99 飙升连接池容量不足或等待超时过长看 HikariCP/HttpClient active 连接数调连接池缩短 connectionRequestTimeout大量虚拟线程阻塞在任务队列固定线程池成为瓶颈看堆栈中 SynchronousQueue/ArrayBlockingQueue用信号量替代线程池做下游保护内存持续增长最终 OOM无界队列堆积、虚拟线程阻塞对象过多观察堆内存、JFR 分配采样限流 有界队列 缩短等待超时synchronized 大户下虚拟线程假死虚拟线程 pin 住载体线程jfr 查看 Carrier Threads 占用替换同步块为 JUC 类或降低虚拟线程并发Tomcat 连接数迅速打满TCP 连接层积压看 server.tomcat.max-connections调大 max-connections 或前置限流出现前三种症状时最快定位方式就是一次线程转储先看虚拟线程到底堵在什么位置再看有没有大量载体线程被 pin 住一般两分钟就能判断出是线程池还是连接池的问题。5.2 线程转储怎么看区分 Pinned 与 Blocked虚拟线程的线程转储格式和平台线程不一样一开始容易看走眼。用 jcmd 抓线程转储jcmd pid Thread.dump_to_file -formatjson thread_dump.jsonjstack 也能看到虚拟线程但会显示成java.lang.VirtualThread。我重点看两类状态第一是 Blocked比如java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire这代表虚拟线程在等锁。如果大量虚拟线程都在等同一个 AQS 锁检查是不是在访问同一个连接池、同一个线程池。第二是 Pinned 标记这是虚拟线程特有的问题。JFR 或者较新版本的 jcmd 转储里会直接标注这个虚拟线程是否 pin 住了载体线程。如果你的虚拟线程在 synchronized 块里调用网络 IO 导致 pin 住应该立即在 JFR 里看jdk.VirtualThreadPinned事件这个事件能准确告诉你 pin 发生在哪一行代码。我排查时发现很多所谓“虚拟线程崩溃”问题本质都不是虚拟线程本身的问题而是你把一堆本来由线程池吞掉的等待、排队、冲突全部原样转移给了虚拟线程结果并发量放大之后才爆发出来。看转储时别被一堆 VirtualThread 的标记唬住回到“它在等什么、为什么等”这两个问题上答案很快就出来了。5.3 我整理的避坑清单最后分享一份避坑清单每条都是真金白银换来的教训虚拟线程不是性能银弹它解决的是线程切换和阻塞成本不解决下游资源不足。如果你下游的数据库、HTTP 服务本来就撑不住高并发开虚拟线程只会让它们更快崩掉。永远不要用无界队列配合虚拟线程。虚拟线程的创建几乎无成本意味着任务堆积时数量可以无限膨胀无界队列 虚拟线程 OOM 两件套。ThreadPoolExecutor的阻塞队列是隐藏的并发壁垒。开启虚拟线程后凡是“可同时只有 N 个”的组件包括固定线程池、数据库连接池、HTTP 连接池都会成为新的瓶颈点。逐一审视它们的容量、等待超时、拒绝策略。连接层的超时时间必须缩短。平台线程池模式下连接等待 30 秒还能拖一拖虚拟线程模式下几千个等待就是灾难。连接池耗尽时快速失败永远比无限等待更安全。网关如果走的是响应式架构不要强行混入虚拟线程和阻塞 API。Spring Cloud Gateway 这类非阻塞模型保持全链路非阻塞是正道虚拟线程救不了响应式代码里的阻塞调用。压测时要同时看 P99 和 P999光看 QPS 一定会被骗。虚拟线程模式下吞吐飙升很容易掩盖延迟恶化的真相延迟曲线一旦在压测后段开始波动哪怕 QPS 还在涨也要立刻停下来找瓶颈。说到这算是把这次事故从头到尾复盘完了。最后再分享一个小技巧我的压测环境里一直开着 JFR 录制出问题时直接拿jfra recording.jfr --untilnow --filenamecrash.jfr把事故现场留下来方便事后慢慢看。另外虚拟线程这趟水建议先在非核心链路上跑一个季度把线程模型变化带来的影响观察清楚了再动核心网关这类服务。毕竟对线上系统来说稳定可预期的延迟永远要比刺激的吞吐数字更值得追求。
