从 2023 年 9 月到今天，虚拟线程我们用了两年半 JDK 21 发布是 2023 年 9 月，我们当年 11 月就把一个内部服务切到了虚拟线程，算是比较早的一批。到今天两年半，虚拟线程跑在我们 14 个服务上，处理过峰值 4.7 万 QPS 的流量，也引发过两次 P2 故障。 这篇不写原理，只
5 万条评测数据，从 80 分钟压到 9 分钟 今年 1 月要做一次大模型效果评测：5 万条标注问题，分别跑三个候选模型，记录每条的输出、耗时和 token 数。总共 15 万次调用。 第一版脚本用 200 线程的固定线程池，跑了 82 分钟还没跑完（因为触发限流重跑了一批）。我花了一天改成虚拟线程
27 万个虚拟线程，把 4 核 8G 的容器拖死了 12 月 6 号凌晨，告警电话把我叫醒。AI 批处理服务的响应时间从正常的 300 毫秒涨到 30 秒以上，CPU 100%，但业务吞吐几乎归零。 # 监控截图里的数据 jvm_threads_live
做聚合服务时，要并发调三个下游再合并结果。最早我用 ExecutorService + Future，取消一个、异常处理、超时控制写得一团乱，线程泄漏还出了两次线上问题。JDK 23 的结构化并发（第五次预览，JEP 480）把这套"多任务协同"重新规范了一遍，值得认真看。 旧写法的乱 经典 Fut
去年用 JDK 21 虚拟线程接重构一个 HTTP 聚合服务，压测时吞吐死活上不去。翻 JFR 发现大量"虚拟线程被 pin 在载体线程上"的事件——罪魁是代码里随处可见的 synchronized。JDK 22/23 的改进，正好把这块骨头啃了下来。 Pin 是什么，为什么是性能杀手 虚拟线程的精
ThreadLocal 在虚拟线程时代水土不服 我们的链路追踪 ID 一直用 ThreadLocal 传。切到虚拟线程后，一个请求一个虚拟线程，数量可能上百万，ThreadLocal 的哈希表跟着膨胀，而且线程复用导致上下文串台——上一个请求的 traceId 漏到了下一个。Java 21 的预览特
等到了 Spring Boot 3.2 的虚拟线程开关 Spring Boot 3.2 把虚拟线程集成做进了自动配置，一个属性就能让 Tomcat 用虚拟线程处理请求。我在 3.2 RC 阶段就拉下来试了，把订单查询接口从平台线程池切过去，吞吐数据很说明问题。不过 RC 阶段 API 还有微调，正式
等了两年的正式版 JDK 21 在 9 月正式 GA，虚拟线程（Project Loom）终于从预览转正。作为常年和线程池、异步回调搏斗的人，我第一时间把内部一个 IO 密集的采集服务迁了过去。结果不算惊艳到颠覆，但确实把"一个请求一个线程"这种直观写法重新变可行了，迁移成本也比预期低。这里把原理、
毫无征兆的线程池打满 新上线的网关用 JDK 21 虚拟线程处理请求。压测到 8000 并发时，吞吐量突然从 1.2 万 req/s 跌到谷底，响应从 30ms 飙到 8 秒，CPU 却只有 40%——典型的"线程都在等，CPU 没事干"。jstack 一看，200 个平台线程（carrier）全卡
面试被问住：线程池里的异常去哪了 五月面试一个候选人，他反过来问我：「用 ExecutorService 提交了三个任务，其中一个抛异常，另外两个还在跑，怎么保证它们被取消？」我脱口而出「写个 Future 判断」，但细想发现，传统线程池里任务生命周期是散的，取消一个不影响其他——这恰恰是结构化并发
