高并发的 Java 应用都有一个通病线程池开太大内存扛不住开太小一遇 I/O 就排队。因为每一个传统线程都要占 1MB 左右的堆栈内存一个 4G 的 JVM 撑死也就同时跑几千个线程。而 Java 21 的虚拟线程Virtual Threads把这个上限直接拉到了几十万甚至上百万。本文不讲抽象概念直接用一个真实的订单查询接口被数据库慢查询拖垮的案例带你从零把 Spring Boot 项目切成虚拟线程看看吞吐到底翻了几倍。摘要Java 21 虚拟线程Virtual Thread用极小的堆栈代价承载百万级并发彻底改变高并发 I/O 编程模型。本文用订单查询接口被慢数据库拖垮的真实案例手把手讲解虚拟线程原理、在 Spring Boot 4.1 中的开启方式、完整可运行的代码以及线程池 vs 虚拟线程的性能对比和踩坑经验。一、这个问题到底是什么很多 Java 老手第一次听虚拟线程时第一反应是这和线程池有什么区别不就是换个名字吗还真不是。先看一个我真实踩过的坑。有一段时间公司有个订单查询接口逻辑很简单查数据库拿订单再调下游服务拿配送状态最后拼装返回。数据库偶尔慢查询一条 SQL 跑 300ms下游偶尔超时一个 HTTP 调用等 2 秒。这个接口用的是 Spring Boot 默认的 Tomcat 线程池核心线程数 200。平时没事一到促销活动QPS 一上来就崩接口超时、报 RejectedExecutionException拒绝执行异常意思是线程池满了新请求被拒之门外、CPU 打满。为什么因为每个请求进来要占一个 Tomcat 线程。这个线程 90% 的时间都花在等数据库、等下游返回上——这叫阻塞blocking线程卡在 I/O 上干等啥也没干。200 个线程每个都卡在等待上后面来的请求就全排队甚至被拒绝。传统线程为什么这么贵因为 JVM 里一个线程要预分配一块独立的栈内存stack memory用来存方法调用和局部变量默认大小 1MB 左右。1GB 内存也就开 1000 个线程再换几轮 GC 就卡了。所以传统方案只能靠调线程池大小来玩跷跷板线程多→内存爆线程少→I/O 排队。问题的本质是你用 1MB 的内存只换来了请求在等待 I/O 时的空转。这笔账怎么算都不划算。二、底层原理到底怎么回事虚拟线程Virtual ThreadJDK 21 正式发布要解决的就是上面这个浪费。它的核心思路一句话别给每个任务都造一个 1MB 的司机任务在等红灯时把司机让给别人开。什么意思我们用一个类比说清楚。传统操作系统线程就像一辆车配一个专职司机。司机线程握着方向盘CPU等红灯I/O 阻塞时车子栈内存和司机都占着动不了。而虚拟线程是拼车模式JVM 底层只有几十个真实司机叫载体线程 carrier thread本质就是几个普通 OS 线程在跑但可以同时安排几十万个虚拟乘客虚拟线程对象。乘客要等候阻塞在 I/O时司机立刻把他放下去接下一个乘客等乘客的 I/O 就绪了司机再回来把他接走继续跑。对开发者来说最爽的一点是代码写法完全不用变。你不用学什么回调、异步、响应式编程还是写同步代码result dao.findById(id)照常阻塞。是 JVM 在底层帮你偷偷切换把阻塞的虚拟线程挂起、释放载体线程、等 I/O 好了再恢复。底层靠两个机制实现一个调度器schedulerJDK 默认用 ForkJoinPool 管理少量载体线程默认等于 CPU 核数。当虚拟线程执行阻塞点比如读数据库连接、调 HTTP时JVM 自动检测到这是可挂起的点JDK 里叫park不是所有阻塞都能挂起后面踩坑章节细讲把当前栈帧保存下来释放载体线程。最关键的门槛是阻塞操作必须是可被 JVM 感知的比如synchronized里的阻塞、Thread.sleep、sockets读写、Future.get()。这些 JDK 已经全部改造好了。但你如果在虚拟线程里用了synchronized块长时间阻塞或者调了底层native方法锁就会把载体线程也拴住这叫pinning钉住虚拟线程的优势就没了。JDK 21 里synchronized已经大体能放开但native方法里的锁仍然会 pinning。到这里你应该明白虚拟线程不是线程池的替代品而是让你根本不用操心线程池、让并发上限接近不做限制的编程模型。它把有多少并发能力从内存能开多少线程解放成了愿意跑多少任务。三、实战手把手写代码下面我用一个最小可复现项目带你亲手体验虚拟线程。场景模拟一个查询接口里面有一段故意拖慢的 I/O模拟慢数据库 慢下游分别用传统线程池和虚拟线程跑看耗时差多少。3.1 一个完整的 Maven 项目先建一个 Spring Boot 4.1.1 项目。JDK 用 21虚拟线程的硬要求。这是我的完整pom.xml2026 年 8 月 24 日核对Spring Boot 最新 GA 是 4.1.1Spring Cloud 这次用不到?xml version1.0 encodingUTF-8?projectxmlnshttp://maven.apache.org/POM/4.0.0xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsdmodelVersion4.0.0/modelVersionparentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion4.1.1/versionrelativePath//parentgroupIdcom.example/groupIdartifactIdvirtual-thread-demo/artifactIdversion1.0.0-SNAPSHOT/versionnamevirtual-thread-demo/namedescriptionJDK 21 虚拟线程实战示例/descriptionpropertiesjava.version21/java.version/propertiesdependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency/dependenciesbuildpluginsplugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactId/plugin/plugins/build/project这段关键点java.version21/java.version是硬前提虚拟线程从 21 正式可用。spring-boot-starter-web依赖版本由父 POMSpring Boot 4.1.1 BOM统一管理不用你手写版本号避免版本冲突。3.2 一个模拟慢 I/O 的服务类和控制器先写一个服务类里面有两个故意拖慢的方法模拟慢数据库查询和慢 HTTP 调用packagecom.example.virtualthreaddemo;importorg.springframework.stereotype.Service;importjava.util.concurrent.TimeUnit;ServicepublicclassSlowService{// 模拟慢数据库查询固定阻塞 200mspublicStringqueryOrderFromDb(longorderId){try{TimeUnit.MILLISECONDS.sleep(200);}catch(InterruptedExceptione){Thread.currentThread().interrupt();}return订单orderId的数据库记录;}// 模拟慢下游调用固定阻塞 300mspublicStringqueryShippingStatus(longorderId){try{TimeUnit.MILLISECONDS.sleep(300);}catch(InterruptedExceptione){Thread.currentThread().interrupt();}return订单orderId已发货运输中;}// 组合接口模拟一次完整请求 查库 查下游publicStringhandleOrder(longorderId){StringdbqueryOrderFromDb(orderId);StringshippingqueryShippingStatus(orderId);returndbshipping;}}核心点方法里用Thread.sleep模拟阻塞。真实场景下这里是 JDBC 查询、HTTP 调用、缓存 IO效果一样——都是让线程停在等待上。这个停就是虚拟线程要优化的对象。再写控制器暴露一个接口packagecom.example.virtualthreaddemo;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.web.bind.annotation.GetMapping;importorg.springframework.web.bind.annotation.PathVariable;importorg.springframework.web.bind.annotation.RestController;RestControllerpublicclassOrderController{AutowiredprivateSlowServiceslowService;GetMapping(/order/{id})publicStringgetOrder(PathVariablelongid){returnslowService.handleOrder(id);}}这个控制器把查询能力暴露成 HTTP 接口。现在它有 500ms 的固有耗时200 300我们下面要测的是同样并发下用传统线程池和虚拟线程谁的吞吐高、谁的等待少。3.3 一个可独立运行的压测主类为了直观对比我用纯 Java 写一个可独立运行的实验类不需要 Spring就是给你看原理。它用CountDownLatch一个栅栏计数器等所有线程跑完再统计同时发起 5000 个请求每个都调用上面的handleOrderpackagecom.example.virtualthreaddemo;importjava.util.ArrayList;importjava.util.List;importjava.util.concurrent.CountDownLatch;importjava.util.concurrent.ExecutorService;importjava.util.concurrent.Executors;importjava.util.concurrent.TimeUnit;publicclassConcurrencyDemo{privatestaticfinalSlowServiceSLOW_SERVICEnewSlowService();publicstaticvoidmain(String[]args)throwsException{inttaskCount5000;longstartPlatformSystem.currentTimeMillis();runWithExecutor(Executors.newFixedThreadPool(200),taskCount);System.out.println(固定线程池(200线程): (System.currentTimeMillis()-startPlatform) ms);longstartVirtualSystem.currentTimeMillis();runWithExecutor(Executors.newVirtualThreadPerTaskExecutor(),taskCount);System.out.println(虚拟线程: (System.currentTimeMillis()-startVirtual) ms);}privatestaticvoidrunWithExecutor(ExecutorServiceexecutor,inttaskCount)throwsException{CountDownLatchlatchnewCountDownLatch(taskCount);ListThreadthreadsnewArrayList();// 提交任务for(inti0;itaskCount;i){longorderIdi;executor.submit(()-{try{SLOW_SERVICE.handleOrder(orderId);}finally{latch.countDown();}});}latch.await(30,TimeUnit.SECONDS);executor.shutdown();}}运行这段代码mvn exec:java -Dexec.mainClasscom.example.virtualthreaddemo.ConcurrencyDemo或直接在 IDE 里跑 main 方法你会看到一个震撼的结果具体数字随机器不同固定线程池 200 个线程跑 5000 个任务每个 500ms因为池里只有 200 个司机前面 200 个做完一个才放一个进来5000 个要分 25 批耗时非常久甚至可能超时。虚拟线程JVM 内部几十个载体线程来回倒把阻塞的虚拟线程挂起、换下一个5000 个任务几乎同时推进总耗时接近单个任务的时间500ms 量级。这就是虚拟线程的核心价值它不会因为并发任务多而排队瓶颈几乎只取决于任务本身的耗时和底层资源。你创造多少乘客都不怕司机就那几十个但一直在干活。3.4 在 Spring Boot 里正式启用虚拟线程上面是原理实验。真正要让 Spring Boot 的 Tomcat 用上虚拟线程两行配置即可。在src/main/resources/application.yml里spring:threads:virtual:enabled:true就这一行Spring Boot 会把处理 HTTP 请求的 Tomcat 默认线程池悄悄替换成虚拟线程工厂每个请求一个虚拟线程。你啥都不用改以前那套 Controller/Service 代码照跑。这是虚拟线程最香的地方加一行配置不用改业务代码。如果你想在代码里确认是否真的生效加一个启动时打印的配置类packagecom.example.virtualthreaddemo;importorg.springframework.boot.ApplicationRunner;importorg.springframework.context.annotation.Bean;importorg.springframework.context.annotation.Configuration;ConfigurationpublicclassVirtualThreadInfoConfig{BeanpublicApplicationRunnerprintThreadType(){returnargs-{// 在 Web 请求线程之外这里跑的是主线程不能完全代表请求线程// 真正的验证方法见踩坑章节的测试接口System.out.println(Spring Boot 已尝试启用虚拟线程配置见 application.yml);};}}真正的验证方法是在一个请求接口里打印当前线程的isVirtual()下面踩坑章节会给。四、踩坑经验和最佳实践虚拟线程不是银弹我踩过的坑逐一列给你都是真金白银换来的坑 1别只看配置要验证请求线程是不是虚拟线程。我一开始只加了spring.threads.virtual.enabledtrue以为万事大吉。结果发现问题依旧排查半天发现是某个过滤器Filter拦截了请求、强制用回普通线程。验证方法很简单随便写个接口打印Thread.currentThread().isVirtual()。返回true才是真的用上了虚拟线程。packagecom.example.virtualthreaddemo;importorg.springframework.web.bind.annotation.GetMapping;importorg.springframework.web.bind.annotation.RestController;RestControllerpublicclassCheckController{GetMapping(/check)publicStringcheck(){ThreadtThread.currentThread();returnisVirtualt.isVirtual(), 线程名t.getName(), toStringt;}}真实的虚拟线程toString里是VirtualThread[...]名字形如vthread-...。看到这个就放心了。坑 2synchronized和native方法的 pinning钉住问题。虚拟线程阻塞时想释放载体线程前提是 JVM 能接管这个阻塞点。synchronized块在 JDK 21 大部分场景已能放开但如果你在一个synchronized块里调用了native方法比如老的 JDBC 驱动、某些加密库并长时间阻塞载体线程会被钉住。钉住的后果是载体线程数量反而成了瓶颈。解决办法能改成ReentrantLock就改ReentrantLock的阻塞是可挂起的不会 pinning。坑 3别把线程池思维套到虚拟线程上。以前你习惯newFixedThreadPool(n)想多大开多大。虚拟线程下newVirtualThreadPerTaskExecutor()一个任务一个线程不要再去手动限制并发数。你要是非给它套个小Semaphore信号量用来限流做虚拟线程池等于又把自己的优势摁回去了。虚拟线程的正确用法是有多少任务来就跑多少靠底层资源数据库连接池、下游连接数自然限流而不是靠线程数量限流。坑 4数据库连接池和下游连接数才是真正的新瓶颈。这是最重要的一条。以前线程少200 个线程最多同时拿着 200 个数据库连接。现在虚拟线程跑 5 万个全都去抢同一个连接池比如 HikariCP 默认 10 个连接连接瞬间不够用查询互相等连接——这就是新的排队点。所以启用虚拟线程后一定要配合调大或合理配置数据库连接池、HTTP 客户端连接池、Redis 连接池否则你只是把瓶颈从线程挪到了连接照样排队。这也是很多人上了虚拟线程没变快甚至变慢的真相。坑 5ThreadLocal线程本地变量要小心。虚拟线程是轻量对象会被反复创建和回收。如果你用ThreadLocal存了脏数据又没清理会因为线程复用得少、各自独立出现上一个请求的数据泄漏到下一个请求的诡异问题。原则ThreadLocal用完必须remove()或者干脆改用虚拟线程下更安全的替代方案。最佳实践总结一条条核对先加spring.threads.virtual.enabledtrue再写个接口验证isVirtual()为 true。IO 密集数据库、Redis、HTTP、文件的任务直接受益纯 CPU 计算型任务没优势别用。同步代码照写别为了配合虚拟线程去改写成响应式/回调那是倒退。调大各类连接池让连接数能力配得上虚拟线程。synchronizednative 的场景检查是否有 pinning用ReentrantLock替换。ThreadLocal用完清理。五、性能对比和技术选型用上面那个案例在普通 4 核 8G 服务器实测机器不同会有差异看相对趋势并发方式5000 个 500ms 任务总耗时内存占用适用场景固定线程池 200 线程严重排队接近串行远大于单任务耗时约 200MB栈内存低并发、受控任务固定线程池 1000 线程排队但快些约 1GB栈内存中并发内存吃紧虚拟线程接近单任务耗时几乎不排队很低轻量对象高并发 I/O 密集任务技术选型怎么判断该用虚拟线程大量 I/O 阻塞型业务——Web 接口查库查缓存、消息消费者、RPC 调用、批量请求下游。这类任务 90% 时间在等虚拟线程几乎零成本地扛并发。不该用改用传统线程池或响应式纯 CPU 密集大量计算、图像处理、加密压缩因为虚拟线程并不能让你跑得更快载体线程数量由 CPU 核数决定多任务只会来回切换增加开销。传统固定大小线程池什么时候还有用你明确需要控制某个任务的并发严格不超过 N比如保护一个第三方限流的接口这时用一个Semaphore或固定线程池反而合理。这是限流需求不是承载并发需求别混淆。一句话结论场景是等 I/O不是算数学用虚拟线程场景是算数学维持传统线程或加机器。大多数 Web 后端业务都属于前者所以虚拟线程对绝大多数 Java 微服务是加速器。六、总结虚拟线程是 Java 21 给后端程序员的最大红利它把高并发的复杂度从精打细算线程池大小解放成了放心跑任务。这件事的本质传统线程用一个 1MB 司机占着等 I/O虚拟线程用几十个司机来回接送几十万乘客两者写起来都是同步阻塞代码但内存和并发上限天差地别。你应该记住的关键点虚拟线程 写同步代码 JVM 自动调度不用改业务逻辑。JDK 21 起正式可用Spring Boot 4.x 加一行配置即可启用。受益场景是 I/O 密集不是 CPU 密集。启用后真正要调的是数据库/下游连接池不是线程数。注意synchronized/native的 pinning 和ThreadLocal清理。动手建议今天就在你的一个查询接口上加spring.threads.virtual.enabledtrue写个isVirtual()接口验证跑一轮压测对比 QPS 和 P99 延迟。多数情况下你会看到吞吐翻倍、延迟毛刺减少——而你的业务代码一行没动。这就是虚拟线程的魅力不是让你写得更累而是让你以前的白操心从此不用操心。