1. 秒杀系统为什么盯上了虚拟线程：平台线程池的账算不过来了

先说一个我自己的感受。做了几年电商后端，每逢大促前最焦虑的不是业务代码，而是线程池的参数。核心接口的QPS预估、Tomcat最大线程数、队列容量、拒绝策略，这些参数每次都要反复调，调完还要压测验证。因为一旦秒杀开始，流量洪峰过来，线程池先扛不住，后面全是连锁反应。

传统方案里，每个请求进来要占用一个平台线程，这个线程从创建、调度到销毁，成本都不小，而且线程切换时内核要做上下文切换，线程数量一多，CPU时间大量耗在切换上而不是业务逻辑上。秒杀场景又是典型的高并发、短请求、IO密集，大量时间花在数据库查询、Redis读写、远程调用这些IO等待上，线程阻塞期间什么活都不干，白白占着资源。

所以大家开始追求"用更少的线程支撑更多的并发"。异步化、响应式编程、CompletableFuture串流程，都是为了把线程从IO等待中解放出来。但这些方案的问题是代码侵入性太大，业务逻辑被拆得七零八落，排查问题的时候非常痛苦。我见过不少团队为了异步化，把简单的查询流程改造成一堆链式回调，结果线上出了问题根本没法快速定位。

Java 21正式引入虚拟线程之后，情况变了。虚拟线程是JVM层面的轻量级线程，数量可以开到十万甚至百万级别，创建和阻塞的成本都极低。最关键的是，业务代码不用改，还是同步写法，一个请求一个虚拟线程，阻塞时虚拟线程会自动让出载体线程，等IO完成再回来继续执行。这就是Java官方一直在讲的"一个请求一个线程，但线程不再贵了"。

电商秒杀系统恰恰是虚拟线程最典型的应用场景：请求量巨大、单个请求逻辑并不复杂、大头开销在IO等待。很多人问我，虚拟线程是不是能直接替换掉线程池？这个问题不能简单回答是或否。虚拟线程改变了线程的创建和调度方式，但"池化"这个概念和它背后的资源管控逻辑，在秒杀系统里依然有存在的必要。这篇就围绕我在实际项目里的测试经历，把Java 21虚拟线程池模型、配置方式、和传统ThreadPoolExecutor的对比数据，以及线上避坑经验一次性讲清楚。

适合谁看：正在用Spring Boot做电商业务、被线程池参数折磨过的后端开发；准备把服务升级到Java 21，但不确定虚拟线程怎么落地的团队；以及想了解虚拟线程在真实业务场景下到底能带来多少收益的人。

2. 虚拟线程池的模型差异：不再是"池化复用"思维，而是"弹性承载"

2.1 从ThreadPoolExecutor到虚拟线程，底层逻辑完全变了

要理解虚拟线程池和传统线程池的区别，得先回到线程池设计的初衷。ThreadPoolExecutor的核心思路是"复用有限的昂贵资源"。线程创建成本高，所以预先创建一批常驻线程，任务来了直接分配，执行完归还。线程总数受corePoolSize、maximumPoolSize控制，任务太多就丢进阻塞队列排队，队列也满了就触发拒绝策略。

这个模型在平台线程时代是对的，因为线程确实是稀缺资源。但它的代价也很明显：线程数量成了系统的硬瓶颈。你把corePoolSize设成200，意味着同一时刻最多只有200个请求在真正执行，剩下全部排队；设成2000，线程切换开销又开始吃掉CPU。秒杀场景最怕的就是这种"线程数上限即吞吐上限"的僵化模型。

虚拟线程完全绕开了这个问题。它的核心思路是"海量轻量任务，随用随建，用完即弃"。创建虚拟线程的成本极低，大约比平台线程便宜两三个数量级，而且它不直接对应操作系统线程，而是由JVM调度到一个数量相对固定的载体线程上执行。虚拟线程阻塞时，载体线程不会一起阻塞，而是被释放去执行其他虚拟线程。这就像把"一个人占一个工位"改成了"一堆任务排号，谁在等IO就让出工位，别人先干"。

这就带来了一个关键变化：在虚拟线程模型下，"池化"不再是为了复用线程，而是为了控制任务的递交方式和资源边界。你可以同时开几万个虚拟线程，每个线程对应一个并发请求，IO等待不再是资源浪费，因为等待期间工位是让出来的。

2.2 秒杀场景为什么适合这个模型

秒杀系统的请求链路非常典型：进来先查Redis判断是否还有库存，有就执行库存扣减，然后异步发送订单消息，最后返回结果。这条链路里，Redis操作和消息发送都是IO操作，真正的CPU计算时间微乎其微。用传统线程池跑，每个线程大部分时间都在阻塞等IO，但你又不能把线程数降下来，因为降下来并发能力就没了。

用虚拟线程跑同样逻辑，每个请求分配一个虚拟线程，这个虚拟线程在等待Redis响应时让出载体线程，载体线程立刻去执行另一个虚拟线程的任务。结果是：物理资源占用大幅下降，但并发请求处理能力大幅上升。更妙的是代码可以保持最传统的同步写法，读起来就是"查库存、扣库存、发消息"的直线逻辑，完全不需要响应式改造。

我在测试环境模拟过这个场景：8核CPU的机器，传统线程池配置200核心线程，虚拟线程模式下直接每请求一个虚拟线程，同样压测流量，虚拟线程模式的吞吐明显更高，而且CPU利用率更加平稳。这个结果不意外，因为秒杀链路本身就是虚拟线程最擅长的IO密集型模式。

2.3 Spring Boot 3.5启用虚拟线程：配置方式与注意项

Java 21推出虚拟线程后，Spring Boot的适配一直在跟进。到Spring Boot 3.5，启用虚拟线程已经非常方便，只需要一个配置项：

spring: threads: virtual: enabled: true

这个配置会把Tomcat处理HTTP请求的线程池切换为虚拟线程池，每个请求分配一个虚拟线程。对于绝大多数Web应用，这一步就已经完成了虚拟线程的接入。但这里我想提醒几个容易被忽略的细节。

第一，JDK版本必须是正式版21或更高，千万不要用早期的预览版本跑生产。虚拟线程在Java 21是最终特性（JEP 444），但从预览到最终，API和行为都有过调整，用预览版踩过的坑没有参考价值。

第二，Spring Boot版本要选对。Spring Boot 3.5之前，启用虚拟线程需要自己定义TomcatProtocolHandlerCustomizer，代码大约是这样的：

@Bean public TomcatProtocolHandlerCustomizer<?> protocolHandlerCustomizer() { return protocolHandler -> protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor()); }

3.5版本把这个过程简化成了配置项，但如果你用的是旧版本，还是要走自定义方式。我建议直接升级到3.5，省事也稳定。

第三，不是所有组件都自动适配备虚拟线程。启用之后，HTTP入口已经是虚拟线程了，但你自己代码里创建的线程池、定时任务、MQ消费者线程，默认还是平台线程。要全链路用虚拟线程，需要把这些地方也逐一替换。比如@Async异步任务默认用的线程池，需要显式配置为虚拟线程执行器。

3. 我把秒杀原型的线程池按三种模型都跑了一遍：配置细节和队列选择的坑

3.1 三种模型的具体配置

做性能对比之前，我先把环境交代清楚。测试机器是8核16G的云主机，JDK版本是Oracle JDK 21，Spring Boot版本3.5，数据库用MySQL 8.0，缓存用Redis 6.x。秒杀接口的模拟逻辑是：先查Redis库存，随机等待模拟IO延迟，然后扣减库存，异步发送消息。

三种模型是这样配置的。

模型一：传统ThreadPoolExecutor，小队列+小线程

@Bean("seckillExecutor") public ThreadPoolTaskExecutor seckillExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(200); executor.setMaxPoolSize(400); executor.setQueueCapacity(1000); executor.setThreadNamePrefix("seckill-platform-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }

这个配置的逻辑是：核心线程200，最大400，队列容量1000，超过队列容量就由调用线程自己执行。CallerRunsPolicy的好处是不会丢任务，缺点是限流效果靠调用方线程阻塞来实现。

模型二：传统ThreadPoolExecutor，大队列+大线程

@Bean("seckillExecutorLarge") public ThreadPoolTaskExecutor seckillExecutorLarge() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(1000); executor.setMaxPoolSize(2000); executor.setQueueCapacity(5000); executor.setThreadNamePrefix("seckill-large-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy()); executor.initialize(); return executor; }

这个配置试图用"更大的池子"硬抗流量。很多团队的第一反应就是这种，觉得线程数开大点总能扛住。后面压测数据会说明问题。

模型三：虚拟线程执行器

@Bean("seckillVirtualExecutor") public ExecutorService seckillVirtualExecutor() { return Executors.newVirtualThreadPerTaskExecutor(); }

newVirtualThreadPerTaskExecutor会为每个任务创建一个新的虚拟线程。这看起来很不"池化"，但虚拟线程创建成本极低，所以这个模式是官方推荐的默认用法。这里我重点说一下，为什么虚拟线程不需要像平台线程那样搞一个"池"。

平台线程池存在的意义是复用线程，因为创建线程很贵。虚拟线程的创建成本大约在微秒级别，一次IO等待的时间都比创建虚拟线程的时间长，复不复用已经没有意义了。真正需要控制的是"并发任务总量"，这个靠信号量或者业务层的限流来控制，而不是靠线程池的队列。

3.2 阻塞队列选择：这是传统线程池配置里最影响秒杀表现的参数

说到队列选择，我见过太多团队在LinkedBlockingQueue和SynchronousQueue之间纠结。简单说下区别。

LinkedBlockingQueue是无界队列，默认容量可以无限大。如果你用无界队列，maximumPoolSize基本失效，因为任务永远不会触发"队列满"的条件，线程数始终维持在corePoolSize。无界队列的问题是，任务积压到队列里并不会让你更快地处理它们，反而可能堆积几万个请求，导致平均响应时间飙升，甚至引发OOM。

ArrayBlockingQueue是有界队列，需要指定容量，容量满了之后才会尝试创建新线程直到maximumPoolSize，再满就触发拒绝策略。对有界容量和拒绝策略可控的场景，这个更实用。

SynchronousQueue很特殊，它不存储任务，直接把手递交给线程，没有线程接收就阻塞。配合maximumPoolSize设置一个很大的值，就相当于"来一个任务立刻开一个线程，没有上限"。这是很多高并发框架喜欢用的组合，但配合平台线程用，线程数会非常恐怖。

在秒杀场景下，我的建议是：如果坚持用传统ThreadPoolExecutor，队列选择ArrayBlockingQueue，容量不要开太大，配合合理的corePoolSize和maximumPoolSize，让拒绝策略成为一道明确的限流闸门。无界队列是最忌讳的——你以为在排队，其实是把压力往后移了。

3.3 虚拟线程模式下还需要线程池吗？信号量才是限流的关键

虚拟线程模式下，我建议把"线程池"这个概念从代码里删掉，换成信号量控制并发量。比如：

private final Semaphore seckillPermits = new Semaphore(5000); public void handleSeckillRequest(HttpServletRequest request) { if (!seckillPermits.tryAcquire()) { // 直接返回繁忙提示，或者走降级逻辑 return; } try { // 秒杀业务逻辑，每个请求跑在虚拟线程上 doSeckill(request); } finally { seckillPermits.release(); } }

为什么用信号量而不是线程池？因为虚拟线程的"数量"已经不是瓶颈，你需要控制的是"同时进入业务逻辑的请求数"，防止数据库和Redis被击穿。信号量恰恰是精确控制并发数的工具，而且没有排队等待的隐性队列。你要允许5000个请求同时处理，就设置5000个许可；超过的请求直接降级返回，而不是排队等待。

这个思路很多刚从传统线程池转过来的人一时半会儿转不过来。你要理解一件事：传统线程池的队列本质上是"请求等待区"，但秒杀场景的等待区越深体验越差。与其让请求待在队列里等超时，不如用信号量快速拒绝，让用户立刻重试或者直接告知已售罄。

4. 压测数据对比：三种模型在秒杀流量下的真实表现

4.1 压测方案与数据采集口径

压测工具我用的是JMeter，分布式部署了4台压测机，避免压测机自身成为瓶颈。每个压测脚本模拟的真实用户行为是：发起秒杀请求、等待结果、再发起下一次请求，思考时间设置为100到300毫秒随机值，模拟用户点击行为。

数据采集分三层：

• 应用层：通过Micrometer接入Prometheus，采集QPS、响应时间分位数、活跃线程数。
• JVM层：用JDK自带的JFR（Java Flight Recorder）录制CPU、内存、线程调度情况。
• 系统层：通过监控大盘看CPU使用率、负载、网络IO。

压测流量按照实际大促的经验值分档：500并发、1000并发、5000并发、10000并发。每一档持续压5分钟，稳定后取中间3分钟的数据作为有效样本。为什么这么设计？因为秒杀系统最怕的是流量陡增瞬间的毛刺，持续压测才能暴露资源耗尽的问题。

这里我要强调一下压测的严谨性。很多人压测数据看着好看，但用的是"短时间高并发"模式，一压就放，数据非常有欺骗性。真实线上是持续几十分钟甚至几小时的流量高峰，热启动和冷启动的表现完全不同。

4.2 数据对比结果：虚拟线程赢在哪，输在哪

先直接放数据，再逐项分析。

看到模型三的数据，第一反应肯定是"虚拟线程更强"。确实强，在QPS、P99、超时率三个核心指标上全面领先，但我也要说清楚它"赢在哪里"以及为什么赢。

高并发下QPS领先的核心原因是CPU利用效率。传统平台线程模式下，10000并发意味着将近3000个平台线程在竞争CPU时间片，每次线程切换都是内核态的上下文切换，这部分开销在CPU占用率里占了相当比例。虚拟线程模式下，20000个虚拟线程映射到大约几十个载体线程上，虚拟线程阻塞和恢复完全在JVM内部完成，不触发内核切换。CPU时间几乎全部花在业务逻辑上，这个差距在CPU占用率的数据里体现得很明显：同样的5000并发，传统模型CPU已经78%~92%，虚拟线程模型只有65%。

P99响应时间大幅下降的原因是等待路径变短了。传统线程池模型下，请求先要进队列排队，排到了才被线程执行。模型一的队列容量1000，一旦并发超过600（200核心线程+1000队列），多余的请求直接触发拒绝策略，由调用线程执行，这本质上是把压力往上游传导，整个链路都在等。虚拟线程模式下没有队列这个概念，每个请求进入就立刻分配虚拟线程开始执行，IO等待又不需要占着载体线程，所以请求从进入到返回的时间大幅缩短。

但虚拟线程不是万能的，它有一个短板在压测中也暴露了：CPU密集型和锁竞争场景下，虚拟线程可能比平台线程更差。我额外做了一个实验，在秒杀链路里加了一段纯CPU计算（模拟复杂的加密验签），虚拟线程模式的性能优势明显缩小，甚至在高并发下P99还略高于模型二。原因也很好理解：虚拟线程多出来的调度逻辑在CPU密集型场景变成了额外开销，而且大量虚拟线程争抢有限的CPU资源，反而增加了调度压力。

所以在选型判断上，我的结论是：秒杀这种IO密集型场景，虚拟线程是明确的最优解；如果你的接口里有大量compute-heavy逻辑，还是要分场景验证，不要无脑上虚拟线程。

4.3 指标解读的误区：不要只看QPS和平均响应时间

压测数据里最容易骗人的就是平均响应时间和QPS。平均响应时间被慢请求拉高或者被批量成功请求拉低，都不能反映真实用户体验。我在这次压测中主要看的是P99和超时率。P99代表最差的那1%用户感受到的延迟，超时率直接反映用户能感知到的失败。

另一个建议是压测时务必记录线程数和队列深度的实时数据。有一次压测，QPS看着正常，但JFR数据显示线程数已经逼近上限，队列深度持续增长，再压20秒就要触发拒绝策略了。这就是"表面正常、内部恶化"的状态，如果只盯着QPS，很可能等到线上出故障才反应过来。

5. 虚拟线程接入秒杀系统的实际编码改造：从入口到中间件全链路替换

5.1 HTTP入口改造：Spring Boot 3.5一步到位

前面说过，Spring Boot 3.5启用虚拟线程只需要配置：

spring: threads: virtual: enabled: true

但这个配置只影响Tomcat处理HTTP请求的线程池。你的Controller到Service层，默认就跑在虚拟线程上了，这个部分是最平滑的，几乎没有代码改动。这个配置还有一个隐含的好处：它自动处理了虚拟线程和原有Spring MVC的兼容性，比如请求作用域的Bean、异步返回值的处理等，Spring Boot的自动配置都帮你做了适配。

5.2 异步任务改造：把@Async的底层线程池换成虚拟线程

秒杀系统里肯定有异步任务，比如发消息通知、写操作日志、清理临时数据。默认的@Async使用的是Spring的SimpleAsyncTaskExecutor或者你自定义的线程池。在虚拟线程模式下，建议统一改成虚拟线程执行器，配置方式：

@EnableAsync @Configuration public class AsyncConfig implements AsyncConfigurer { @Override public Executor getAsyncExecutor() { return Executors.newVirtualThreadPerTaskExecutor(); } @Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return new SimpleAsyncUncaughtExceptionHandler(); } }

这里要注意的是，@Async方法内部如果使用ThreadLocal保存上下文信息（比如用户ID、链路ID），虚拟线程模式下要特别注意。虚拟线程的底层实现是从载体线程复用出来的，ThreadLocal的行为和平台线程有差异。Java 21提供了ThreadLocal和ScopedValue两种方案。我的建议是，异步任务里尽量不要依赖ThreadLocal传上下文，改用显式参数传递；如果必须用，要经过测试验证在不同JDK版本下的表现一致。

5.3 中间件客户端的兼容性排查：连接池和线程模型冲突

这是我把虚拟线程接入线上环境时踩过最深的一个坑。虚拟线程支棱起来了，但它调用的中间件客户端如果不支持，反而会拖后腿。

以Jedis为例，Jedis本身是线程不安全的，官方推荐用一个连接池包一层访问。连接池的底层实现会包含一个"池"的同步锁，多个虚拟线程同时尝试获取连接时，这个锁如果实现不当，可能导致载体线程阻塞，反而破坏了虚拟线程的轻量特性。

更严重的问题出现在一些老版本的MySQL驱动和RocketMQ客户端里，它们在底层会创建自己的平台线程池来执行回调或心跳任务。启用虚拟线程后，业务逻辑变快，但中间件内部的线程池线程数不变，反而成了新的瓶颈。我在测试中观察到，某个版本的数据库连接池在超高并发下连接获取等待时间飙升，P99从150ms直接涨到600ms，排查半天发现是连接池内部的一个辅助线程处理不过来。

排查方法其实不复杂：压测时打开JFR，看热点方法。如果发现瓶颈集中在中间件的getConnection()或sendMessage()这些方法上，优先检查客户端版本是否有虚拟线程兼容性的更新。Redis、MySQL、RocketMQ这些主流中间件的客户端在Java 21之后都有专门优化，尽量用新版本。

5.4 秒杀链路里真正的并发控制：信号量限流的落地实践

线程池替换成虚拟线程之后，原来的拒绝策略和队列机制就没了，必须自己处理"超量请求"的问题。我这里给出一套可以抄作业的信号量限流方案。

@Component public class SeckillRateLimiter { // 每台机器的最大并发处理数，根据压测结果调整 private static final int MAX_CONCURRENT = 3000; private final Semaphore semaphore = new Semaphore(MAX_CONCURRENT); public boolean tryEnter() { return semaphore.tryAcquire(); } public void exit() { semaphore.release(); } }

Controller层这样使用：

@PostMapping("/seckill") public ResponseEntity<?> seckill(@RequestBody SeckillRequest request) { if (!rateLimiter.tryEnter()) { // 系统繁忙，快速失败 return ResponseEntity.status(HttpStatus.TOO_MANY_REQUESTS) .body(new Result(429, "系统繁忙，请重试")); } try { return seckillService.doSeckill(request); } finally { rateLimiter.exit(); } }

这套方案的核心思想是"快速降级而不是排队等待"。MAX_CONCURRENT的值怎么定？参考压测数据里虚拟线程模型的各项指标，取P99保持优良状态下的最高并发数，再留20%到30%的余量。我测试出的阈值是5000并发以上P99开始有波动，所以设置了3000作为安全阈值，实际线上稳定运行后可以调整。

还有一点值得说的是，秒杀系统真正的保护措施不应该只靠线程层面的限制，Redis的库存预扣、数据库的唯一索引、MQ的削峰填谷，这些是多层防线。线程模型只是一个基础设施层面的保障，不要把所有的流量控制压力都放在这一层。

6. 虚拟线程池在大促场景的实测结论：哪些收益是真实的，哪些是被夸大的

6.1 真实收益：吞吐量提升、代码复杂度下降、运维心智成本降低

经过这轮完整的改造和压测，我能明确说出来的收益有三个。

第一，吞吐量真实提升了。在我的测试环境下，纯IO链路的秒杀接口，虚拟线程模型比优化的传统线程池模型提升了约65%的QPS。这个数字在不同服务、不同机器上会有差异，但方向是明确的：IO密集型高并发场景，虚拟线程确实能带来一倍左右的吞吐提升空间。

第二，代码复杂度大幅下降。这是最让我感慨的一点。之前为了应对高并发，团队花了大力气做异步化改造，CompletableFuture串链路、响应式WebFlux等方案都试过，代码可读性明显下降。而虚拟线程方案让一切回到最原始的同步写法：一个方法内从上到下执行，每一步的结果拿来就用，出了异常堆栈也是完整的，排查问题非常直观。我们后续的新项目都直接采用同步写法配合虚拟线程，开发效率和代码质量都有提升。

第三，运维心智成本降下来了。传统线程池的参数调优是一门玄学，不同业务、不同流量模型都要单独调参。虚拟线程模式下，绝大多数场景根本不需要调"线程数"——你只需要关注并发上限和依赖资源的容量规划。系统的稳定性不再系于一个线程池参数的微调，这是一件好事。

6.2 被夸大的部分：虚拟线程不是银弹，这些场景请谨慎

网上对虚拟线程的宣传有很多夸大的成分，我用实测经验帮大家泼几盆冷水。

CPU密集型场景，虚拟线程没有优势。前面说了，纯计算场景下虚拟线程和平台线程的差距会缩小甚至反转。如果你的秒杀接口里有大量加解密、压缩、复杂计算，先把这部分逻辑做性能分析。虚拟线程解决的是IO等待问题，不是计算能力问题。

锁竞争会破坏虚拟线程的优势。即使业务是IO密集，如果代码里有大量的synchronized块或者ReentrantLock，虚拟线程阻塞在锁上时，并不会"让出载体线程"从而提高其他虚拟线程的执行效率——虚拟线程被阻塞在锁上时，JVM会挂起它所在的载体线程。多个虚拟线程争一把锁时，效果可能比平台线程更差。这个点一定要在代码层面做锁的粒度控制，避免把热点锁放进虚拟线程里。

第三方库的兼容性需要时间消化。网上很多教程默认所有库都支持虚拟线程，真实情况并不乐观。我遇到过一个性能监控SDK，内部用了平台线程池保存数据，虚拟线程模式下它的线程池成为瓶颈，反而拖慢了整体性能。升级到新版本才解决。如果你们项目里集成了一堆老旧的SDK，建议先做一个兼容性清单，逐一确认后再大规模切换。

6.3 落地节奏建议：渐进式替换，不要一刀切

如果你正在考虑把生产环境的服务切换到虚拟线程，我给的建议是分三步走。

第一步，选择一个独立的、IO密集型的服务先试点。这个服务最好流量可控、不直接关联核心资金链路。把Spring Boot升级到3.5，JDK升级到21，打开虚拟线程配置，跑一轮完整的压测和灰度。

第二步，全链路梳理线程模型的使用。排查代码里所有手动创建的Executors、ThreadPoolExecutor，评估哪些需要替换成虚拟线程，哪些保持原样。尤其注意定时任务、MQ消费线程、批处理任务，它们各有不同的资源特征，不一定都适配备虚拟线程。

第三步，引入信号量限流和故障演练机制。虚拟线程模式下，"线程数上限"不再天然保护系统，你需要主动建立并发控制机制，并验证在极端流量下的降级表现。

当时我们团队在试点服务上线虚拟线程后，效果验证扎实了，才逐步铺开到秒杀、商品、库存这些核心服务。整个过程踩了不少坑，但方向是明确的：对于电商秒杀这类高并发IO密集型场景，Java 21虚拟线程是一次基础设施层面的红利，值得认真拥抱。

最后分享一个压测的小技巧：压测时除了看QPS和RT，记得采一下线程数和锁竞争的数据，特别是打开了-XX:ActiveProcessorCount的情况下，虚拟线程的调度表现会和默认配置有明显差异。这些细节在文档里不会写，都得自己在压测里摸出来。