1. 传统并发模型的三个死结线程太贵、阻塞太浪费、异步太难写在真正上手 Project Loom 之前我其实已经跟 Java 并发搏斗了很长时间。最早用裸线程后来用线程池再后来被各种异步回调、Future、CompletableFuture 折磨到怀疑人生。每次遇到高并发场景脑子里先蹦出来的问题永远是那句老台词线程池该开多大开小了任务排队开大了内存爆炸开得刚刚好又遇到下游超时把线程全部占住。这个问题困扰了我很多年直到虚拟线程出现我才意识到之前一直在错误的方向上硬扛。先说说传统线程为什么这么贵。一个平台线程也就是平常说的操作系统线程在 Linux 上默认栈空间是 1MB这还只是栈本身不算线程控制块、内核栈、调度数据这些额外的开销。我在某电商项目的压测环境里实际测过一台 4C8G 的容器线程数开到 800 左右 CPU 就已经开始剧烈抖动超过 1200 直接出现 OOM。换算下来一个线程占的内存轻松超过 1~2MB这种成本决定了你根本不可能为每个请求单独创建一个线程只能靠池化复用。线程池能解决一部分问题但它有个内伤池的大小是固定的。调小了高并发时请求排长队调大了低峰期白白占用系统资源最难受的是遇到下游服务变慢的情况线程一旦在 IO 等待那里阻塞住整个池子的线程都会被慢慢耗尽新的任务全部排队用户感知就是系统变慢了甚至卡死。我做过的压测里有个典型案例某个订单查询接口用了一个固定 200 线程的池子平时响应 20ms压测时模拟下游数据库慢查询把响应时间拖到 2 秒结果 200 个线程很快就全部卡在数据库连接上接口吞吐量直接归零。那时候我去看线程 Dump一排排的WAITING on java.sql.Connection心里特别绝望。异步编程解决阻塞浪费的思路是把线程还回去发一个非阻塞请求线程立刻返回线程池干活等数据回来了再通过回调继续处理。这套思路本身没毛病甚至很多框架靠它做到了超高吞吐但代价是代码变得极其反人类。一个本来顺序执行的三步逻辑写成异步之后嵌套了五层回调出个 Bug 查半天都不知道调用链走到哪一步了。后来有了 CompletableFuture 和响应式框架代码整洁了一些但心智负担依然很重。我在某支付项目里见过一段处理对账的逻辑正常的伪代码只有 8 行异步版本写了 60 多行还引入了两个状态机来处理超时和重试读代码的人没有一个不骂的。这就是我认为 Project Loom 真正革命的地方它没有让你换一种编程范式去迁就并发而是直接在平台层面把阻塞的成本降到了极低于是你大可以回到最原始的一个请求一个线程、代码顺序执行的写法同时还不用付出传统线程那种高昂的内存开销。通俗点说虚拟线程让世界上没有免费的午餐这句老话被打破了那么一点点——你可以用几乎免费的方式创建海量线程让每个任务都有自己独立的执行栈代码里写 Print 甚至 Debugger 单步跟踪都毫无压力。现在回头看之前学的各种异步技巧和响应式框架在大多数业务场景里其实是拿复杂度和可维护性换吞吐量而虚拟线程想让你两样都占住。2. 虚拟线程的底层面目用户态调度、载体线程与挂载卸载机制很多文章讲虚拟线程喜欢说它像 Golang 的 Goroutine这个类比方向是对的但如果你真的深入去理解 JVM 层面的实现会发现虚拟线程和 Goroutine 在细节上有不少差异。要真正用好它必须先把这几个核心概念吃透虚拟线程不是操作系统线程它由 JVM 自己调度虚拟线程必须运行在平台线程之上这个平台线程叫载体线程虚拟线程阻塞时会被卸载掉把载体线程让给别的虚拟线程用。2.1 JVM 怎么做到用一个载体线程跑成千上万个虚拟线程拿快递来类比应该是最直观的平台线程就是那辆货车虚拟线程就是一件快递。传统模式下送一件快递要用一整辆货车货多了只能买更多车成本极高。虚拟线程的模式是货车还是那么多辆但每件快递都特别小一件一件往上塞送完一单立刻回来装下一单。货车没闲过但快递也全都在流动。JVM 内部维护了一个调度器它负责决定哪个虚拟线程在哪个载体线程上跑。当一个虚拟线程被创建时它并不会立刻占用一个平台线程而是被挂到调度器的就绪队列里调度器自己维护了一套队列按需把虚拟线程分配到空闲的载体线程上。这套机制最核心的部分叫挂载和卸载。虚拟线程在一个载体线程上运行是挂载Mount状态当虚拟线程因为某个操作而阻塞比如等待锁、读 Socket、读数据库连接JVM 检测到这个阻塞不会影响载体线程上的其他工作就执行卸载Unmount把虚拟线程的执行栈和状态保存好腾出载体线程来运行队列里的下一个虚拟线程。注意这里有个非常重要的前提不是所有的阻塞都会被卸载也不是所有的挂载点都能被 JVM 自由调度。如果虚拟线程不小心跑到了某些有 JNI 边界或者 synchronized 块后面会讲的地方JVM 可能会选择钉住Pin住载体线程这时候阻塞就会退化成平台线程级别的阻塞。这算是我在实践中踩过的几个暗坑之一后面专门会写。2.2 调度策略work-stealing 与 ForkJoinPool 的配合虚拟线程的调度器默认是 ForkJoinPool它走的是 work-stealing 算法。简单解释一下每个载体线程工作线程有自己的队列任务进去之后谁有空谁拿自己的队列空了就偷偷去别人的队列里偷任务。这种设计在大学里学分布式系统的时候我就见过但真正在 JVM 里跑起来还是有点微妙的。默认的调度器线程数等于 CPU 核心数也就是说虚拟线程不会增加并行处理的 CPU 核心数量它做的是让阻塞不再占着茅坑不拉屎。所以如果你的任务是纯 CPU 密集型虚拟线程的收益几乎为零甚至因为调度开销还会慢一点点但如果是 IO 密集型虚拟线程能把等待时间里浪费的 CPU 白赚回来。CPU 密集和 IO 密集的区分我觉得可以给个更具体的判断标准任务里有没有长时间停顿等待外部资源。凡是读接口、读数据库、读文件、网络通信都是 IO 密集型。凡是纯计算、加解密、序列化、正则匹配部分都是 CPU 密集型。我在一次内部技术分享里就劝大家不要把虚拟线程吹成万金油CPU 密集场景用传统线程池手动调优反而更可控。2.3 虚拟线程的三个看起来像极了线程却完全不同的点虚拟线程有名字有 ID有优先级也有 Thread.State 状态看起来跟 Thread 没区别。但有几个地方跟传统线程是两个世界。第一个是 getStackTrace()虚拟线程的栈是 JVM 自己维护的拿到的轨迹会比平台线程浅而且它不参与操作系统层级的线程状态迁移。第二个是线程组ThreadGroup虚拟线程在执行时不属于任何线程组你在 dump 里看到的归属关系都是空的。第三个是 debugger 体验传统线程挂起会阻塞整个进程虚拟线程挂起只阻塞那一个虚拟线程其他虚拟线程照跑不误。这四个点我用一个表格整理过对比项平台线程虚拟线程创建成本1~2MB 内存起步创建耗时长几 KB 内存起步创建开销极小调度方操作系统内核调度器JVM 用户态 ForkJoinPool 调度器最大数量受内核资源和内存限制受堆内存限制百万级可轻松达到阻塞行为阻塞即占用线程资源可触发卸载载体线程继续执行其他任务适用场景CPU 密集、长期占用核心IO 密集、大量短任务、请求并发高这张表我自己写文档时反复用过基本把虚拟线程最核心的差异化说清楚了。再强调一次虚拟线程的关键不是多了个新线程而是线程变便宜到可以随便造以及阻塞变便宜到不用刻意回避。3. 一段真实的压测对比从 Executor 到 VirtualThread吞吐翻了多少倍讲原理容易飘落到代码才见真章。这一节我把自己在某模拟项目里的改造过程拆开来说包括怎么写出第一版虚拟线程代码、压测结果对比、以及那些只有跑起来才知道的细节问题。3.1 最基础的改造只用两行代码从固定线程池切到虚拟线程我当时的场景是一个短信网关的转发服务收到了请求之后要做几件事解析报文、查一下用户的渠道配置走 Redis、再调用下游短信供应商的 HTTP 接口最后回执入库。每一步都有网络等待典型的 IO 密集。旧代码用的线程池长这样ExecutorService pool Executors.newFixedThreadPool(200); pool.submit(() - handleRequest(request));改成虚拟线程的写法其实非常直白一行为核心ExecutorService pool Executors.newVirtualThreadPerTaskExecutor(); pool.submit(() - handleRequest(request));你没看错本质上就是换了工厂方法的名字剩下的业务代码一字未改。为了验证效果我在一个模拟环境里搭了压测模拟下游供应商平均响应 120ms请求量用工具从每秒 200 逐步加到每秒 2000。旧线程池版本在每秒 800 左右时线程数触顶出现排队和超时新虚拟线程版本在每秒 2000 时 CPU 还没占到 80%错误率几乎没有平均响应时间比旧版本低了 35%。当时一起做的同事直接愣住改一行代码吞吐量差了一个数量级代码可读性半点没降。3.2 更细一层虚拟线程池的超时、任务队列与关闭机制踩坑从固定线程池切到newVirtualThreadPerTaskExecutor()之后我遇到三个意料之外的问题。第一个是超时行为变化固定线程池用的invokeAll、submit带 Timeout 参数还能继续用语义没变但虚拟线程池里shutdownNow()的语义有点差异——它返回的是尚未开始执行的任务列表已经开始跑的任务中断信号会被发送但中断之后能不能及时退出取决于任务代码里对中断标志位的处理。我在另一个业务里写过一段任务线程里循环读一个队列做批次提交忘了处理 InterruptedException结果主线程 shutdown 之后任务仍跑了几十秒。这个不算虚拟线程的锅但切换之后大家都容易默认线程池行为完全一样实际需要重新验证。第二个是任务队列问题newFixedThreadPool默认用无界队列任务堆积多了会占满内存newVirtualThreadPerTaskExecutor则没有排队机制每个提交的任务直接创建一个虚拟线程执行。如果你的代码里有提交任务后靠队列背压的逻辑切换到虚拟线程池后逻辑会变需要有意识地引入信号量或限制并发量的机制不然突发流量会瞬间创建几十万虚拟线程GC 压力陡增。后来我给这个入口加了一个 Semaphore 限流信号量初始值设成下游连接池能承受的上限效果很好。第三个是关闭资源的问题虚拟线程池不强制要求关闭但它跟平台线程池一样如果你不关闭进程可能一直挂着。更值得留意的是虚拟线程里的 ThreadLocal 在没有关闭池子的情况下如果任务里往 ThreadLocal 写入了一个大对象会一直持有引用直到任务结束。本来虚拟线程便宜你可以疯狂地创建但老任务是存活着的连带 ThreadLocal 一起把堆占满。这里我采用的做法是凡是虚拟线程里跑的代码能不用 ThreadLocal 就不用非要用的话用 try-finally 在 finally 里手动 remove。关于这一点我在后面的踩坑小节里还会再敲一次黑板。3.3 测试自己的代码怎么判断阻塞是否真的被卸载了很多人看完原理会关心一个问题我怎么知道我的业务代码里的阻塞到底有没有触发虚拟线程卸载这里我提供一个非常朴素但有效的方法就是找阻塞点位自己打印线程状态和线程名。虚拟线程如果没有启用调试模式默认线程名是虚拟线程名称平台线程池线程名是一串类似pool-x-thread-y的名字。你可以在一个模拟的 IO 阻塞前打印当前线程名阻塞后立刻打印一次再看 Dump。如果虚拟线程阻塞后同一个载体线程又被拿去跑别的虚拟线程任务说明卸载生效了。更严谨一些的做法是看 JDK 提供的诊断参数。比如启动参数加-Djdk.tracePinnedThreadsfull会在虚拟线程被钉住Pin时打印完整的堆栈。全量输出可能刷屏生产上建议不要开但在压测和验证阶段非常有用。有一次我就是靠这个参数发现某个资源池里的锁把虚拟线程钉在了载体线程上排查和修复的过程在下一节里会展开。4. 高并发场景的调优手法从锁、连接池到结构化并发把虚拟线程用到极致虚拟线程并不是开箱即全部真正的高并发工程里连接池、锁、限流和代码组织方式如果不跟着改虚拟线程的收益会被稀释掉一大半。这一节我从四个方面讲都是我在实践里验证过的真实调优路径。4.1 synchronized 与 ReentrantLock 的钉住陷阱先说一个非常反直觉的细节。很多 Java 老手写并发锁优先用synchronized因为语法简单清晰。但在虚拟线程场景下synchronized的钉住问题很棘手。前面提到 JVM 在挂载/卸载时把执行栈保存下来但如果一个虚拟线程在synchronized块内发生阻塞JVM 为了保证同步语义不能随意卸载该线程卸载会导致临界区持锁期间线程与载体线程的解绑这个状态下如果又换到另一个载体线程锁的监视器状态会变得极其复杂。于是 JVM 保守一点钉住当前载体线程不做卸载。被钉住的载体线程要等 synchronized 块跑完才能被调度器拿去跑其他虚拟线程这等于平台线程被白白占住和传统线程阻塞没有区别。我在一个业务里就撞上过这个坑代码里有一处用synchronized (lock)包着的一次 Redis 写入写入时有几毫秒的网络等待。压测时发现虚拟线程数量上去了但 CPU 出现大量空转线程 Dump 显示一堆载体线程被钉住在那几个 synchronized 块里吞吐量卡在一个奇怪的瓶颈上。解决办法很简单把这个synchronized换成ReentrantLock因为ReentrantLock是基于 AQS 的用户态锁JVM 检测到虚拟线程在锁等待时能安全地卸载它。同理CountDownLatch、Semaphore、BlockingQueue这一系列java.util.concurrent里的同步工具在虚拟线程场景下基本都可安全卸载。这里我的建议很直接新代码里能不用synchronized就别用尽量用java.util.concurrent里的锁和信号量。4.2 连接池不是越大越好虚拟线程时代重新审视连接配置传统线程池时代你常听到的一句话是连接池大小不要开太大。这个说法的根源是每个连接背后是一个线程或一个网络 Socket连接池太大徒增资源和上下文切换。于是很多人把数据库连接池开成 20、30把 HTTP 连接池开成 200、300。虚拟线程出现之后有一个有趣的结论连接池的瓶颈不再来自连接本身而是来自后端服务的实际容量。虚拟线程可以批量创建它们排队等连接但真正能同时打进数据库的还看数据库能抗多少。所以虚拟线程时代调整连接池策略我更推荐小连接池配大并发量的组合。连接池大小该设多少应该以后端数据库、下游接口的真实容量为准而不是靠线程数CPU核数1之类的经验公式。我实测过一组数据同一个服务端MySQL 连接池从 200 降到 50配虚拟线程 500整体吞吐反而更高原因就是后端少了很多没意义的空闲连接和锁竞争。还有一点需要专门提醒连接池内部获取连接的等待区也非常关键。如果虚拟线程数千个并发同时向连接池要连接池内维护的等待队列会成为一个热点队列锁会变成瓶颈。建议使用支持公平锁或双队列的成熟连接池实现比如我在某模块里把获取连接的等待直接改成信号量分组把不同类型请求的优先级分开效果比单纯调大连接池更好。4.3 限流与背压虚拟线程不打爆资源的最后一个安全阀虚拟线程创建成本极低这是一个好到让人放松警惕的特性。我在内部系统里见过同事上来就把每个请求都开一个虚拟线程没有做任何限制结果某个上游接口超时几秒内积压了十几万虚拟线程堆直接被打到高水位Full GC 频繁最后服务接近假死。虚拟线程虽然便宜但不是免费的每多一个线程就多一份栈内存和执行元数据。真到了几十万虚拟线程同时存活的规模GC 的负载会显著上升。所以虚拟线程很便宜不等于可以无限不设防地创建。我给自己的项目定的规矩是这样入口处永远要有限流器信号量或者令牌桶都行。信号量这个工具尤其推荐因为它的等待语义天然适合虚拟线程——虚拟线程等信号量不会被钉住可以卸载掉去做别的事这样如果有 1000 个虚拟线程在等信号量它们消耗的资源极小一旦资源释放它们又能立刻跑起来。4.4 结构化并发让虚拟线程的关闭和异常传播不再失控用虚拟线程写了几个月之后我逐渐发现一个痛点管不住线程的生命周期。比如一个请求进来要并行调三个远程服务用传统ExecutorService写的话又要维护一组 Future还要处理其中一个失败时另外两个还在跑的问题。JDK 21 引入了结构化并发我用下来觉得这个 API 的价值被很多人低估了。它的设计思路其实和协程带来的结构化编程是一致的把并发任务放进一个作用域里作用域结束时所有子任务必须完成或被取消。举一个实际代码片段这是我在模拟项目里封装过的一种并行调用方式try (var scope new StructuredTaskScope.ShutdownOnFailure()) { FutureString user scope.fork(() - fetchUser(userId)); FutureString order scope.fork(() - fetchOrder(orderId)); scope.join(); scope.throwIfFailed(); return combine(user.resultNow(), order.resultNow()); }只用几行就把并行执行、有一个失败就快速失败、结束后强制清理其余子任务的逻辑表达出来了。相比之前手动收集 Future、在 catch 块里逐个 cancel 的日子这算是一个显著的可维护性提升。如果你的项目已经能升级到支持虚拟线程的稳定版本结构化并发 API 值得认真学一下它在编排大量子任务时的异常处理简洁得让人感动。想想我以前用 CompletableFuture 写了一堆allOf().exceptionally()的嵌套现在再看这种作用域式写法真有点恍如隔世。5. 半年实测后我改掉的旧习惯垃圾回收、线程局部变量与诊断工具虚拟线程用了一段时间踩过的坑攒了不少有几个如果不分享出来后来人大概率还要再踩一遍。这一节内容基本属于常规文档里不会写的东西但实战里非常关键。5.1 ThreadLocal 在百万虚拟线程下的内存放大效应ThreadLocal 在虚拟线程里是一个被反复提起的雷。原因很简单平台线程池的大小是可控的比如池子里 200 个线程每个线程身上的 ThreadLocal 最多也就 200 份副本。虚拟线程则不同每一个虚拟线程都可能有自己的一份 ThreadLocal 副本如果代码里用了带缓存的 ThreadLocal 存大对象比如连接信息、请求上下文、审计日志对象百万级虚拟线程一过内存就是百万份这些对象非常惊人。我自己的解决方案是三层防护。第一层尽量只在虚拟线程的入口和出口处传递上下文不往 ThreadLocal 里塞大对象用小对象或引用类型代替。第二层如果非要用 ThreadLocal放进 try-finally 里清理干净别指望线程结束后自动回收——虚拟线程结束后虽会清理一部分但长期存活的虚拟线程身上积累的 ThreadLocal 引用会非常顽固。第三层考虑用InheritableThreadLocal还是TransmittableThreadLocal前者在虚拟线程里基本等于无效后者需要额外引入依赖如果只是接口间传个 requestId直接用方法参数传递反而是最稳妥的。5.2 别在虚拟线程里跑 CPU 密集型任务一个压测失败后的顿悟我再强调一次虚拟线程是给 IO 密集型任务准备的不是给 CPU 密集任务准备的。有一个失败的压测案例我印象很深我把一个图片压缩的功能从线程池切到了虚拟线程池跑完一看吞吐不仅没涨反而下降了一截。后来分析原因压缩图片是纯计算任务没有阻塞虚拟线程在载体线程之间反复调度反而增加了额外开销且每个虚拟线程的执行栈还有额外内存成本。结论很清晰让虚拟线程去干并行计算是方法论上的根本误用。那如果任务里既有计算又有 IO该怎么办我的经验是拆成两段纯计算部分扔到传统的 ForkJoinPool 或固定线程池里并行跑IO 部分拆出去用虚拟线程。这种混搭模式一开始写起来有点别扭但纯计算多多线程调度、IO 部分靠虚拟线程无阻塞等待各司其职整体效果会特别均衡。5.3 诊断和排障虚拟线程的 Dump 怎么看、火焰图怎么做虚拟线程事故现场和传统线程最大的不同是线程数量多到难以置信随随便便就是几千条线程。传统的jstack打出来的文件直接几百兆人眼根本看不过来。我最常用的诊断手法是先看总数和状态分布再结合疑似热点过滤。一个可行的诊断路径是先对进程执行jcmd Thread.dump_to_file生成线程 Dump 文件再用脚本统计各状态的线程数。如果大量虚拟线程处于RUNNABLE状态且都在做网络 IO说明系统在空转要么是载体线程不够用要么是 Pin 了。如果大量虚拟线程处于WAITING状态且堆栈里有park和某个锁的等待那多半是资源池或锁竞争问题。对于火焰图我会用 async-profiler 生成 CPU 火焰图重点看jdk.internal、java.util.concurrent这些包下的调用栈占比。如果发现某个调用栈被大量虚拟线程共同执行那这个点位就是需要集中优化的热点。调试的时候有个非常有用的参数-Djdk.tracePinnedThreadsfull它能直接在控制台打印出 Pin 住载体线程的调用栈。我在一个业务里排查过一次神秘的吞吐量暴跌靠这个参数定位到是第三方 SDK 内部有 synchronized 阻塞最后通过改造调用方式绕开了那个阻塞点。这个参数的代价是性能开销和日志量只建议在测试环境开生产环境用短时采集的方式观察。5.4 遗留代码改造的策略不要一锅端从最痛的 IO 密集路径开始最后说说存量系统的改造。我的原则特别保守先改收益最大、风险最小的路径坚决不搞一锅端。具体操作分四步走第一步盘点系统里所有的线程池列出它们的核心参数、用途和当前负载情况。第二步挑出 IO 密集且瓶颈明显的线程池优先替换成虚拟线程常见目标是 HTTP 调用、数据库访问、文件读写、外部服务调用这一类任务入口。第三步替换之后跑一轮完整的压测重点看吞吐、响应时间、GC 变化、CPU 使用率特别是检查有没有 Pin 的警告日志出现。第四步把 ThreadLocal、synchronized 这些潜在雷区提前扫一遍再做切换。我记得有一个支付对账系统改了三四个线程池之后消息积压率直接降了六成而代码改动量控制在很小的范围。所以说虚拟线程的落地并不需要轰轰烈烈的重写它是一个精准打击的工具用对了具体路径收益立刻能看见。6. 我对虚拟线程的最终判断替换什么、不替换什么、以及下一个要学的方向如果你问我虚拟线程能不能完全替代平台线程我的答案是在绝大部分业务场景下可以但不是所有。替代掉那些等待太久的线程池任务收益立竿见影替代掉那些计算密集的任务不仅没收益还可能倒退。所以与其纠结要不要全面迁到虚拟线程不如回到问题的本质——看你的任务到底是等得多还是算得多。对于团队引入虚拟线程我有几条实践后的体会。第一先从最简单的入口替换开始用newVirtualThreadPerTaskExecutor()替换少量 IO 密集线程池观察运行情况和压测数据再逐步扩大范围不要一上来就全量切换。第二提前约定团队内部编码规范新代码统一优先使用ReentrantLock和 juc 工具ThreadLocal 做了明确规定synchronized 只能用在不需要卸载的细粒度临界区。第三把-Djdk.tracePinnedThreads集成进测试环境的启动参数每次发布前跑一遍冒烟压测盯住 Pin 日志有没有新增这样能提前知道有没有引入新的钉住点。说了这么多好话也想泼点冷水虚拟线程不是银弹它没有改变操作系统资源上限的事实也没有改变 CPU 密集型任务对并行核数的需求。它真正改变的是线程成本和阻塞成本这两个长期制约 Java 服务端吞吐的硬指标。在我个人的实践范围里这个改变足够大大到足以称它为革命性并发模型。最后再分享一个小建议。如果你准备在自己的项目里上虚拟线程建议先拿一个非核心、但 IO 密集且流量真实的任务做试点把压测前后的数据完整记录下来。我经历过几次以为自己在用虚拟线程、实际被 synchronized 钉住、性能还不如之前的尬场面重重踩过坑之后才摸索出这套相对稳妥的落地路线。希望这篇文章能帮你少走一点这些弯路。
1. 传统并发模型的三个死结线程太贵、阻塞太浪费、异步太难写在真正上手 Project Loom 之前我其实已经跟 Java 并发搏斗了很长时间。最早用裸线程后来用线程池再后来被各种异步回调、Future、CompletableFuture 折磨到怀疑人生。每次遇到高并发场景脑子里先蹦出来的问题永远是那句老台词线程池该开多大开小了任务排队开大了内存爆炸开得刚刚好又遇到下游超时把线程全部占住。这个问题困扰了我很多年直到虚拟线程出现我才意识到之前一直在错误的方向上硬扛。先说说传统线程为什么这么贵。一个平台线程也就是平常说的操作系统线程在 Linux 上默认栈空间是 1MB这还只是栈本身不算线程控制块、内核栈、调度数据这些额外的开销。我在某电商项目的压测环境里实际测过一台 4C8G 的容器线程数开到 800 左右 CPU 就已经开始剧烈抖动超过 1200 直接出现 OOM。换算下来一个线程占的内存轻松超过 1~2MB这种成本决定了你根本不可能为每个请求单独创建一个线程只能靠池化复用。线程池能解决一部分问题但它有个内伤池的大小是固定的。调小了高并发时请求排长队调大了低峰期白白占用系统资源最难受的是遇到下游服务变慢的情况线程一旦在 IO 等待那里阻塞住整个池子的线程都会被慢慢耗尽新的任务全部排队用户感知就是系统变慢了甚至卡死。我做过的压测里有个典型案例某个订单查询接口用了一个固定 200 线程的池子平时响应 20ms压测时模拟下游数据库慢查询把响应时间拖到 2 秒结果 200 个线程很快就全部卡在数据库连接上接口吞吐量直接归零。那时候我去看线程 Dump一排排的WAITING on java.sql.Connection心里特别绝望。异步编程解决阻塞浪费的思路是把线程还回去发一个非阻塞请求线程立刻返回线程池干活等数据回来了再通过回调继续处理。这套思路本身没毛病甚至很多框架靠它做到了超高吞吐但代价是代码变得极其反人类。一个本来顺序执行的三步逻辑写成异步之后嵌套了五层回调出个 Bug 查半天都不知道调用链走到哪一步了。后来有了 CompletableFuture 和响应式框架代码整洁了一些但心智负担依然很重。我在某支付项目里见过一段处理对账的逻辑正常的伪代码只有 8 行异步版本写了 60 多行还引入了两个状态机来处理超时和重试读代码的人没有一个不骂的。这就是我认为 Project Loom 真正革命的地方它没有让你换一种编程范式去迁就并发而是直接在平台层面把阻塞的成本降到了极低于是你大可以回到最原始的一个请求一个线程、代码顺序执行的写法同时还不用付出传统线程那种高昂的内存开销。通俗点说虚拟线程让世界上没有免费的午餐这句老话被打破了那么一点点——你可以用几乎免费的方式创建海量线程让每个任务都有自己独立的执行栈代码里写 Print 甚至 Debugger 单步跟踪都毫无压力。现在回头看之前学的各种异步技巧和响应式框架在大多数业务场景里其实是拿复杂度和可维护性换吞吐量而虚拟线程想让你两样都占住。2. 虚拟线程的底层面目用户态调度、载体线程与挂载卸载机制很多文章讲虚拟线程喜欢说它像 Golang 的 Goroutine这个类比方向是对的但如果你真的深入去理解 JVM 层面的实现会发现虚拟线程和 Goroutine 在细节上有不少差异。要真正用好它必须先把这几个核心概念吃透虚拟线程不是操作系统线程它由 JVM 自己调度虚拟线程必须运行在平台线程之上这个平台线程叫载体线程虚拟线程阻塞时会被卸载掉把载体线程让给别的虚拟线程用。2.1 JVM 怎么做到用一个载体线程跑成千上万个虚拟线程拿快递来类比应该是最直观的平台线程就是那辆货车虚拟线程就是一件快递。传统模式下送一件快递要用一整辆货车货多了只能买更多车成本极高。虚拟线程的模式是货车还是那么多辆但每件快递都特别小一件一件往上塞送完一单立刻回来装下一单。货车没闲过但快递也全都在流动。JVM 内部维护了一个调度器它负责决定哪个虚拟线程在哪个载体线程上跑。当一个虚拟线程被创建时它并不会立刻占用一个平台线程而是被挂到调度器的就绪队列里调度器自己维护了一套队列按需把虚拟线程分配到空闲的载体线程上。这套机制最核心的部分叫挂载和卸载。虚拟线程在一个载体线程上运行是挂载Mount状态当虚拟线程因为某个操作而阻塞比如等待锁、读 Socket、读数据库连接JVM 检测到这个阻塞不会影响载体线程上的其他工作就执行卸载Unmount把虚拟线程的执行栈和状态保存好腾出载体线程来运行队列里的下一个虚拟线程。注意这里有个非常重要的前提不是所有的阻塞都会被卸载也不是所有的挂载点都能被 JVM 自由调度。如果虚拟线程不小心跑到了某些有 JNI 边界或者 synchronized 块后面会讲的地方JVM 可能会选择钉住Pin住载体线程这时候阻塞就会退化成平台线程级别的阻塞。这算是我在实践中踩过的几个暗坑之一后面专门会写。2.2 调度策略work-stealing 与 ForkJoinPool 的配合虚拟线程的调度器默认是 ForkJoinPool它走的是 work-stealing 算法。简单解释一下每个载体线程工作线程有自己的队列任务进去之后谁有空谁拿自己的队列空了就偷偷去别人的队列里偷任务。这种设计在大学里学分布式系统的时候我就见过但真正在 JVM 里跑起来还是有点微妙的。默认的调度器线程数等于 CPU 核心数也就是说虚拟线程不会增加并行处理的 CPU 核心数量它做的是让阻塞不再占着茅坑不拉屎。所以如果你的任务是纯 CPU 密集型虚拟线程的收益几乎为零甚至因为调度开销还会慢一点点但如果是 IO 密集型虚拟线程能把等待时间里浪费的 CPU 白赚回来。CPU 密集和 IO 密集的区分我觉得可以给个更具体的判断标准任务里有没有长时间停顿等待外部资源。凡是读接口、读数据库、读文件、网络通信都是 IO 密集型。凡是纯计算、加解密、序列化、正则匹配部分都是 CPU 密集型。我在一次内部技术分享里就劝大家不要把虚拟线程吹成万金油CPU 密集场景用传统线程池手动调优反而更可控。2.3 虚拟线程的三个看起来像极了线程却完全不同的点虚拟线程有名字有 ID有优先级也有 Thread.State 状态看起来跟 Thread 没区别。但有几个地方跟传统线程是两个世界。第一个是 getStackTrace()虚拟线程的栈是 JVM 自己维护的拿到的轨迹会比平台线程浅而且它不参与操作系统层级的线程状态迁移。第二个是线程组ThreadGroup虚拟线程在执行时不属于任何线程组你在 dump 里看到的归属关系都是空的。第三个是 debugger 体验传统线程挂起会阻塞整个进程虚拟线程挂起只阻塞那一个虚拟线程其他虚拟线程照跑不误。这四个点我用一个表格整理过对比项平台线程虚拟线程创建成本1~2MB 内存起步创建耗时长几 KB 内存起步创建开销极小调度方操作系统内核调度器JVM 用户态 ForkJoinPool 调度器最大数量受内核资源和内存限制受堆内存限制百万级可轻松达到阻塞行为阻塞即占用线程资源可触发卸载载体线程继续执行其他任务适用场景CPU 密集、长期占用核心IO 密集、大量短任务、请求并发高这张表我自己写文档时反复用过基本把虚拟线程最核心的差异化说清楚了。再强调一次虚拟线程的关键不是多了个新线程而是线程变便宜到可以随便造以及阻塞变便宜到不用刻意回避。3. 一段真实的压测对比从 Executor 到 VirtualThread吞吐翻了多少倍讲原理容易飘落到代码才见真章。这一节我把自己在某模拟项目里的改造过程拆开来说包括怎么写出第一版虚拟线程代码、压测结果对比、以及那些只有跑起来才知道的细节问题。3.1 最基础的改造只用两行代码从固定线程池切到虚拟线程我当时的场景是一个短信网关的转发服务收到了请求之后要做几件事解析报文、查一下用户的渠道配置走 Redis、再调用下游短信供应商的 HTTP 接口最后回执入库。每一步都有网络等待典型的 IO 密集。旧代码用的线程池长这样ExecutorService pool Executors.newFixedThreadPool(200); pool.submit(() - handleRequest(request));改成虚拟线程的写法其实非常直白一行为核心ExecutorService pool Executors.newVirtualThreadPerTaskExecutor(); pool.submit(() - handleRequest(request));你没看错本质上就是换了工厂方法的名字剩下的业务代码一字未改。为了验证效果我在一个模拟环境里搭了压测模拟下游供应商平均响应 120ms请求量用工具从每秒 200 逐步加到每秒 2000。旧线程池版本在每秒 800 左右时线程数触顶出现排队和超时新虚拟线程版本在每秒 2000 时 CPU 还没占到 80%错误率几乎没有平均响应时间比旧版本低了 35%。当时一起做的同事直接愣住改一行代码吞吐量差了一个数量级代码可读性半点没降。3.2 更细一层虚拟线程池的超时、任务队列与关闭机制踩坑从固定线程池切到newVirtualThreadPerTaskExecutor()之后我遇到三个意料之外的问题。第一个是超时行为变化固定线程池用的invokeAll、submit带 Timeout 参数还能继续用语义没变但虚拟线程池里shutdownNow()的语义有点差异——它返回的是尚未开始执行的任务列表已经开始跑的任务中断信号会被发送但中断之后能不能及时退出取决于任务代码里对中断标志位的处理。我在另一个业务里写过一段任务线程里循环读一个队列做批次提交忘了处理 InterruptedException结果主线程 shutdown 之后任务仍跑了几十秒。这个不算虚拟线程的锅但切换之后大家都容易默认线程池行为完全一样实际需要重新验证。第二个是任务队列问题newFixedThreadPool默认用无界队列任务堆积多了会占满内存newVirtualThreadPerTaskExecutor则没有排队机制每个提交的任务直接创建一个虚拟线程执行。如果你的代码里有提交任务后靠队列背压的逻辑切换到虚拟线程池后逻辑会变需要有意识地引入信号量或限制并发量的机制不然突发流量会瞬间创建几十万虚拟线程GC 压力陡增。后来我给这个入口加了一个 Semaphore 限流信号量初始值设成下游连接池能承受的上限效果很好。第三个是关闭资源的问题虚拟线程池不强制要求关闭但它跟平台线程池一样如果你不关闭进程可能一直挂着。更值得留意的是虚拟线程里的 ThreadLocal 在没有关闭池子的情况下如果任务里往 ThreadLocal 写入了一个大对象会一直持有引用直到任务结束。本来虚拟线程便宜你可以疯狂地创建但老任务是存活着的连带 ThreadLocal 一起把堆占满。这里我采用的做法是凡是虚拟线程里跑的代码能不用 ThreadLocal 就不用非要用的话用 try-finally 在 finally 里手动 remove。关于这一点我在后面的踩坑小节里还会再敲一次黑板。3.3 测试自己的代码怎么判断阻塞是否真的被卸载了很多人看完原理会关心一个问题我怎么知道我的业务代码里的阻塞到底有没有触发虚拟线程卸载这里我提供一个非常朴素但有效的方法就是找阻塞点位自己打印线程状态和线程名。虚拟线程如果没有启用调试模式默认线程名是虚拟线程名称平台线程池线程名是一串类似pool-x-thread-y的名字。你可以在一个模拟的 IO 阻塞前打印当前线程名阻塞后立刻打印一次再看 Dump。如果虚拟线程阻塞后同一个载体线程又被拿去跑别的虚拟线程任务说明卸载生效了。更严谨一些的做法是看 JDK 提供的诊断参数。比如启动参数加-Djdk.tracePinnedThreadsfull会在虚拟线程被钉住Pin时打印完整的堆栈。全量输出可能刷屏生产上建议不要开但在压测和验证阶段非常有用。有一次我就是靠这个参数发现某个资源池里的锁把虚拟线程钉在了载体线程上排查和修复的过程在下一节里会展开。4. 高并发场景的调优手法从锁、连接池到结构化并发把虚拟线程用到极致虚拟线程并不是开箱即全部真正的高并发工程里连接池、锁、限流和代码组织方式如果不跟着改虚拟线程的收益会被稀释掉一大半。这一节我从四个方面讲都是我在实践里验证过的真实调优路径。4.1 synchronized 与 ReentrantLock 的钉住陷阱先说一个非常反直觉的细节。很多 Java 老手写并发锁优先用synchronized因为语法简单清晰。但在虚拟线程场景下synchronized的钉住问题很棘手。前面提到 JVM 在挂载/卸载时把执行栈保存下来但如果一个虚拟线程在synchronized块内发生阻塞JVM 为了保证同步语义不能随意卸载该线程卸载会导致临界区持锁期间线程与载体线程的解绑这个状态下如果又换到另一个载体线程锁的监视器状态会变得极其复杂。于是 JVM 保守一点钉住当前载体线程不做卸载。被钉住的载体线程要等 synchronized 块跑完才能被调度器拿去跑其他虚拟线程这等于平台线程被白白占住和传统线程阻塞没有区别。我在一个业务里就撞上过这个坑代码里有一处用synchronized (lock)包着的一次 Redis 写入写入时有几毫秒的网络等待。压测时发现虚拟线程数量上去了但 CPU 出现大量空转线程 Dump 显示一堆载体线程被钉住在那几个 synchronized 块里吞吐量卡在一个奇怪的瓶颈上。解决办法很简单把这个synchronized换成ReentrantLock因为ReentrantLock是基于 AQS 的用户态锁JVM 检测到虚拟线程在锁等待时能安全地卸载它。同理CountDownLatch、Semaphore、BlockingQueue这一系列java.util.concurrent里的同步工具在虚拟线程场景下基本都可安全卸载。这里我的建议很直接新代码里能不用synchronized就别用尽量用java.util.concurrent里的锁和信号量。4.2 连接池不是越大越好虚拟线程时代重新审视连接配置传统线程池时代你常听到的一句话是连接池大小不要开太大。这个说法的根源是每个连接背后是一个线程或一个网络 Socket连接池太大徒增资源和上下文切换。于是很多人把数据库连接池开成 20、30把 HTTP 连接池开成 200、300。虚拟线程出现之后有一个有趣的结论连接池的瓶颈不再来自连接本身而是来自后端服务的实际容量。虚拟线程可以批量创建它们排队等连接但真正能同时打进数据库的还看数据库能抗多少。所以虚拟线程时代调整连接池策略我更推荐小连接池配大并发量的组合。连接池大小该设多少应该以后端数据库、下游接口的真实容量为准而不是靠线程数CPU核数1之类的经验公式。我实测过一组数据同一个服务端MySQL 连接池从 200 降到 50配虚拟线程 500整体吞吐反而更高原因就是后端少了很多没意义的空闲连接和锁竞争。还有一点需要专门提醒连接池内部获取连接的等待区也非常关键。如果虚拟线程数千个并发同时向连接池要连接池内维护的等待队列会成为一个热点队列锁会变成瓶颈。建议使用支持公平锁或双队列的成熟连接池实现比如我在某模块里把获取连接的等待直接改成信号量分组把不同类型请求的优先级分开效果比单纯调大连接池更好。4.3 限流与背压虚拟线程不打爆资源的最后一个安全阀虚拟线程创建成本极低这是一个好到让人放松警惕的特性。我在内部系统里见过同事上来就把每个请求都开一个虚拟线程没有做任何限制结果某个上游接口超时几秒内积压了十几万虚拟线程堆直接被打到高水位Full GC 频繁最后服务接近假死。虚拟线程虽然便宜但不是免费的每多一个线程就多一份栈内存和执行元数据。真到了几十万虚拟线程同时存活的规模GC 的负载会显著上升。所以虚拟线程很便宜不等于可以无限不设防地创建。我给自己的项目定的规矩是这样入口处永远要有限流器信号量或者令牌桶都行。信号量这个工具尤其推荐因为它的等待语义天然适合虚拟线程——虚拟线程等信号量不会被钉住可以卸载掉去做别的事这样如果有 1000 个虚拟线程在等信号量它们消耗的资源极小一旦资源释放它们又能立刻跑起来。4.4 结构化并发让虚拟线程的关闭和异常传播不再失控用虚拟线程写了几个月之后我逐渐发现一个痛点管不住线程的生命周期。比如一个请求进来要并行调三个远程服务用传统ExecutorService写的话又要维护一组 Future还要处理其中一个失败时另外两个还在跑的问题。JDK 21 引入了结构化并发我用下来觉得这个 API 的价值被很多人低估了。它的设计思路其实和协程带来的结构化编程是一致的把并发任务放进一个作用域里作用域结束时所有子任务必须完成或被取消。举一个实际代码片段这是我在模拟项目里封装过的一种并行调用方式try (var scope new StructuredTaskScope.ShutdownOnFailure()) { FutureString user scope.fork(() - fetchUser(userId)); FutureString order scope.fork(() - fetchOrder(orderId)); scope.join(); scope.throwIfFailed(); return combine(user.resultNow(), order.resultNow()); }只用几行就把并行执行、有一个失败就快速失败、结束后强制清理其余子任务的逻辑表达出来了。相比之前手动收集 Future、在 catch 块里逐个 cancel 的日子这算是一个显著的可维护性提升。如果你的项目已经能升级到支持虚拟线程的稳定版本结构化并发 API 值得认真学一下它在编排大量子任务时的异常处理简洁得让人感动。想想我以前用 CompletableFuture 写了一堆allOf().exceptionally()的嵌套现在再看这种作用域式写法真有点恍如隔世。5. 半年实测后我改掉的旧习惯垃圾回收、线程局部变量与诊断工具虚拟线程用了一段时间踩过的坑攒了不少有几个如果不分享出来后来人大概率还要再踩一遍。这一节内容基本属于常规文档里不会写的东西但实战里非常关键。5.1 ThreadLocal 在百万虚拟线程下的内存放大效应ThreadLocal 在虚拟线程里是一个被反复提起的雷。原因很简单平台线程池的大小是可控的比如池子里 200 个线程每个线程身上的 ThreadLocal 最多也就 200 份副本。虚拟线程则不同每一个虚拟线程都可能有自己的一份 ThreadLocal 副本如果代码里用了带缓存的 ThreadLocal 存大对象比如连接信息、请求上下文、审计日志对象百万级虚拟线程一过内存就是百万份这些对象非常惊人。我自己的解决方案是三层防护。第一层尽量只在虚拟线程的入口和出口处传递上下文不往 ThreadLocal 里塞大对象用小对象或引用类型代替。第二层如果非要用 ThreadLocal放进 try-finally 里清理干净别指望线程结束后自动回收——虚拟线程结束后虽会清理一部分但长期存活的虚拟线程身上积累的 ThreadLocal 引用会非常顽固。第三层考虑用InheritableThreadLocal还是TransmittableThreadLocal前者在虚拟线程里基本等于无效后者需要额外引入依赖如果只是接口间传个 requestId直接用方法参数传递反而是最稳妥的。5.2 别在虚拟线程里跑 CPU 密集型任务一个压测失败后的顿悟我再强调一次虚拟线程是给 IO 密集型任务准备的不是给 CPU 密集任务准备的。有一个失败的压测案例我印象很深我把一个图片压缩的功能从线程池切到了虚拟线程池跑完一看吞吐不仅没涨反而下降了一截。后来分析原因压缩图片是纯计算任务没有阻塞虚拟线程在载体线程之间反复调度反而增加了额外开销且每个虚拟线程的执行栈还有额外内存成本。结论很清晰让虚拟线程去干并行计算是方法论上的根本误用。那如果任务里既有计算又有 IO该怎么办我的经验是拆成两段纯计算部分扔到传统的 ForkJoinPool 或固定线程池里并行跑IO 部分拆出去用虚拟线程。这种混搭模式一开始写起来有点别扭但纯计算多多线程调度、IO 部分靠虚拟线程无阻塞等待各司其职整体效果会特别均衡。5.3 诊断和排障虚拟线程的 Dump 怎么看、火焰图怎么做虚拟线程事故现场和传统线程最大的不同是线程数量多到难以置信随随便便就是几千条线程。传统的jstack打出来的文件直接几百兆人眼根本看不过来。我最常用的诊断手法是先看总数和状态分布再结合疑似热点过滤。一个可行的诊断路径是先对进程执行jcmd Thread.dump_to_file生成线程 Dump 文件再用脚本统计各状态的线程数。如果大量虚拟线程处于RUNNABLE状态且都在做网络 IO说明系统在空转要么是载体线程不够用要么是 Pin 了。如果大量虚拟线程处于WAITING状态且堆栈里有park和某个锁的等待那多半是资源池或锁竞争问题。对于火焰图我会用 async-profiler 生成 CPU 火焰图重点看jdk.internal、java.util.concurrent这些包下的调用栈占比。如果发现某个调用栈被大量虚拟线程共同执行那这个点位就是需要集中优化的热点。调试的时候有个非常有用的参数-Djdk.tracePinnedThreadsfull它能直接在控制台打印出 Pin 住载体线程的调用栈。我在一个业务里排查过一次神秘的吞吐量暴跌靠这个参数定位到是第三方 SDK 内部有 synchronized 阻塞最后通过改造调用方式绕开了那个阻塞点。这个参数的代价是性能开销和日志量只建议在测试环境开生产环境用短时采集的方式观察。5.4 遗留代码改造的策略不要一锅端从最痛的 IO 密集路径开始最后说说存量系统的改造。我的原则特别保守先改收益最大、风险最小的路径坚决不搞一锅端。具体操作分四步走第一步盘点系统里所有的线程池列出它们的核心参数、用途和当前负载情况。第二步挑出 IO 密集且瓶颈明显的线程池优先替换成虚拟线程常见目标是 HTTP 调用、数据库访问、文件读写、外部服务调用这一类任务入口。第三步替换之后跑一轮完整的压测重点看吞吐、响应时间、GC 变化、CPU 使用率特别是检查有没有 Pin 的警告日志出现。第四步把 ThreadLocal、synchronized 这些潜在雷区提前扫一遍再做切换。我记得有一个支付对账系统改了三四个线程池之后消息积压率直接降了六成而代码改动量控制在很小的范围。所以说虚拟线程的落地并不需要轰轰烈烈的重写它是一个精准打击的工具用对了具体路径收益立刻能看见。6. 我对虚拟线程的最终判断替换什么、不替换什么、以及下一个要学的方向如果你问我虚拟线程能不能完全替代平台线程我的答案是在绝大部分业务场景下可以但不是所有。替代掉那些等待太久的线程池任务收益立竿见影替代掉那些计算密集的任务不仅没收益还可能倒退。所以与其纠结要不要全面迁到虚拟线程不如回到问题的本质——看你的任务到底是等得多还是算得多。对于团队引入虚拟线程我有几条实践后的体会。第一先从最简单的入口替换开始用newVirtualThreadPerTaskExecutor()替换少量 IO 密集线程池观察运行情况和压测数据再逐步扩大范围不要一上来就全量切换。第二提前约定团队内部编码规范新代码统一优先使用ReentrantLock和 juc 工具ThreadLocal 做了明确规定synchronized 只能用在不需要卸载的细粒度临界区。第三把-Djdk.tracePinnedThreads集成进测试环境的启动参数每次发布前跑一遍冒烟压测盯住 Pin 日志有没有新增这样能提前知道有没有引入新的钉住点。说了这么多好话也想泼点冷水虚拟线程不是银弹它没有改变操作系统资源上限的事实也没有改变 CPU 密集型任务对并行核数的需求。它真正改变的是线程成本和阻塞成本这两个长期制约 Java 服务端吞吐的硬指标。在我个人的实践范围里这个改变足够大大到足以称它为革命性并发模型。最后再分享一个小建议。如果你准备在自己的项目里上虚拟线程建议先拿一个非核心、但 IO 密集且流量真实的任务做试点把压测前后的数据完整记录下来。我经历过几次以为自己在用虚拟线程、实际被 synchronized 钉住、性能还不如之前的尬场面重重踩过坑之后才摸索出这套相对稳妥的落地路线。希望这篇文章能帮你少走一点这些弯路。
