Java · 虚拟线程 (Loom)

场景 1 · 阻塞式 Spring Boot 一行配置切 VT (与前提清单)

IO 密集的老服务, 200 线程池常年打满排队; JDK 21 + Boot 3.2 起一行配置把"每请求一线程"换成 VT:

// application.properties (JDK 21+, Boot 3.2+)
// spring.threads.virtual.enabled=true
// Tomcat: 每个请求一个虚拟线程, 替代 maxThreads=200 的平台池

// 开开关前的三件前提, 缺一个都白改:
// 1) @Async / 自定义 Executor 的地方不受该开关影响, 要单独换 VT executor
// 2) ThreadLocal 缓存大对象的代码先清理 (内存放大千倍)
// 3) synchronized 内做 IO 的老代码 → 先压测看 pinned, 见场景 5

只读接口灰度一周: P99 从 1.9s 降到 410ms, 机器没加一台。

场景 2 · 详情页三下游扇出: 每请求一个 VT, 告别 thenCombine 套娃

CompletableFuture 编排三层 thenCombine, 异常要在流里接; VT 化后就是三行同步代码:

try (ExecutorService vt = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<Info>  a = vt.submit(() -> infoClient.get(id));    // 阻塞调用放心写
    Future<Price> b = vt.submit(() -> priceClient.get(id));
    Future<Stock> c = vt.submit(() -> stockClient.get(id));
    return render(a.get(), b.get(), c.get());   // get() 阻塞的是 VT, 不烧内核线程
}
// 代码量 -40%, 异常回归普通 try/catch, 栈完整可调试
// executor 用完即关 (try-with-resources), 别做成全局静态常驻 — 见坑 7

场景 3 · 百万补偿任务: VT 不池化, Semaphore 限并发

大促后跑百万条补偿, 平台线程池 64 根跑三天; VT 一任务一线程, 但下游承不住无限并发 — 信号量是唯一闸门:

try (ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor()) {
    Semaphore rate = new Semaphore(200);          // 全局同时在飞 ≤200, 按下游容量定
    List<Future<?>> fs = new ArrayList<>();
    for (long id : ids) {
        fs.add(pool.submit(() -> {
            rate.acquire();                    // 排队等许可: 阻塞在 VT 上, 零内核占用
            try { compensate(id); }
            finally { rate.release(); }
        }));
    }
    for (Future<?> f : fs) f.get();          // 别忘 get: 不 get 异常照样静默 (老坑不变)
}

同样 8C 容器: 3 天 → 5 小时, 下游错误率零变化 (许可数对齐下游压测上限)。

场景 4 · JDBC 驱动在 VT 下的吞吐实验: 连接池才是新瓶颈

VT 化后 QPS 没涨? 阻塞 JDBC 在 VT 上没问题, 但连接池只有 10 — 排队从线程池挪到了池子里:

HikariConfig cfg = new HikariConfig();
cfg.setMaximumPoolSize(50);      // 池上限 = 新瓶颈: VT 百万也过不去这 50 个连接
// 压测数据示意 (8C 容器, 下游 SQL P99 50ms):
//   平台线程 200 + 池 10 →  8.2k QPS · P99 1.8s   (线程池排队)
//   VT + 池 10           →  9.0k QPS · P99 1.6s   (排队挪到连接池)
//   VT + 池 50           → 21.0k QPS · P99 420ms  (真瓶颈消除)
// 再往上是 DB 自己的极限 — 限流与熔断永远要配着加, VT 不豁免容量规划

场景 5 · pinned 排查: tracePinnedThreads 定位 synchronized, 换 ReentrantLock

灰度 VT 后吞吐反而降: 一段老代码在 synchronized 里查库, 把 carrier 全钉死了:

// 灰度 JVM 参数: -Djdk.tracePinnedThreads=full
// 日志: Thread[#67,ForkJonPool-1-worker-3] pinned due to:
//   com.x.OrderService.warmCache → synchronized (lockCache) { jdbc query... }

private final ReentrantLock lock = new ReentrantLock();  // 修复: 换锁
void warmCache() {
    lock.lock();                          // ReentrantLock 阻塞可 unmount
    try { warmWithDb(); } finally { lock.unlock(); }
}
// 修完 P99 410ms; 顺带把"锁内查库"这个老毛病也治了 — 锁内 IO 本就该移出去

场景 6 · 双活机房"谁先成功用谁": StructuredTaskScope 竞速

读多写少的配置查询, 主备机房同时发, 用先回的那份; 手写 Future 竞速要管取消, 结构化并发自动收尾:

try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
    scope.fork(() -> primary.get(url));    // 主机房
    scope.fork(() -> standby.get(url));    // 备机房, 两个 VT 同步竞速
    scope.join();                           // 阻塞的是"当前 VT", 不占内核线程
    return scope.result();               // 第一个成功的结果; 其余自动取消
}
// 注意: 结构化并发长期预览 (JEP 505 等), 包名/类名随版本核对, 生产锁死 JDK 版本再上

场景 7 · ThreadLocal 在百万 VT 下内存炸 → 换 ScopedValue 思路

链路上下文 512KB 缓存进 ThreadLocal, VT 一百万个就是 500GB; 平台线程池时代 200 份没问题, 现在量纲变了:

// 坏: 大对象 × 最大 VT 数 = 灾难
static final ThreadLocal<UserCtx> CTX = new ThreadLocal<>();   // 512KB × 1M

// 好: 上下文显式传参; 必须线程绑定时用有界作用域
private static final ScopedValue<UserCtx> CTX = ScopedValue.newInstance();
ScopedValue.where(CTX, userCtx).run(() -> handler.process(req));  // 用完即走

// 判定标准一句话: 这个对象 × 最大 VT 数, 还小吗?
// 小对象 (locale/traceId 几十字节) 照用 ThreadLocal, 不用过度设计

场景 8 · 爬虫网关万级长连接 VT 化: 一连接一线程, 事件循环全删

老网关用 Netty 写了三千行 pipeline, 新人接不住; 换 VT 后回到教科书写法:

try (ServerSocket server = new ServerSocket(8080);
     ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor()) {
    while (running) {
        Socket s = server.accept();
        pool.submit(() -> handle(s));       // 一连接一 VT, 万级也轻
    }
}
static void handle(Socket s) throws IOException {
    try (s; var in = new BufferedReader(new InputStreamReader(s.getInputStream()))) {
        for (String line; (line = in.readLine()) != null; )  // 阻塞 = unmount
            dispatch(line);                                // 闲连接零线程占用
    }
}

场景 9 · 压测对比: 平台线程池 vs VT (8C 网关, 数据示意)

同容器同下游 (P99 45ms), 只切线程模型, wrk -t8 -c2000 -d10m, 变量只有一个:

// 平台线程池 (max 200):  6.5k QPS · P99 2.1s · CPU 40%
//   → 大量上下文切换, 200 根线程在 8 核上来回踩
// 虚拟线程 (一请求一 VT): 18.7k QPS · P99 380ms · CPU 55%
//   → 切换消失 (mount/unmount 是用户态搬栈), IO 等待不占线程

// 边界验证 (重要): 同服务的 CPU 密集路由 (压缩+加密) 单独压 —
//   平台池 5.1k QPS vs VT 5.2k QPS: 原地踏步, CPU 密集零红利
// 结论模板: 收益只来自"阻塞等待占比", 压测报告必须分路由看

场景 10 · 灰度迁移: 双执行器并存, 配置中心一键回滚

直接全量切 VT 风险大 (pinning/内存放大都是压测才现形); 开关化灰度, 出事改一行配置回滚:

@Bean
ExecutorService jobExecutor(@Value("${jobs.virtual:false}") boolean virtual) {
    return virtual
        ? Executors.newVirtualThreadPerTaskExecutor()   // VT 通道
        : Executors.newFixedThreadPool(64);                 // 原通道兜底
}
// 灰度顺序: 只读接口 → 混部 5% 流量 → 全量; 每步观察:
//   QPS / P99 / pinned 计数 (jcmd Thread.dump_to_file) / 下游错误率 / 堆增长
// 别跳步: 场景 5 与 7 的两个坑, 都是 5% 流量跑了两天才现形的