从 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
去年用 JDK 21 虚拟线程接重构一个 HTTP 聚合服务,压测时吞吐死活上不去。翻 JFR 发现大量"虚拟线程被 pin 在载体线程上"的事件——罪魁是代码里随处可见的 synchronized。JDK 22/23 的改进,正好把这块骨头啃了下来。 Pin 是什么,为什么是性能杀手 虚拟线程的精
等到了 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)全卡
把线程池换成虚拟线程 我们有个网关聚合服务,每请求要并发调 5 个下游,原来用 200 个平台线程的池子,峰值打满就排队。用户多的时候,线程池耗尽,请求在队列里干等,RT 从 200ms 飙到 2 秒。听说 JDK 19 的虚拟线程能把"一个任务一个线程"做到近乎免费,就拿来做了对照实验,想看看是不
「线程数加到 800 了,还是上不去」 1 月中旬看压测报告,开放平台那个网关服务的并发一直卡在 4000 左右。压测的同学在群里说:「Tomcat 线程数已经从 200 加到 800 了,加不动了,再加 Full GC 就开始频繁。」 这个症状太典型了——线程成了并发的天花板。我把之前攒的 Loo