虚拟线程与结构化并发实战

传统高并发公式：
  连接数 × 每个请求的线程占用 ≈ 内存上限
  所以大家用 NIO + 线程池 + 异步回调，把"一个连接一个线程"压成"少量线程"

虚拟线程时代：
  连接数 ≈ 线程数，不需要异步化，回归简单的阻塞式代码

// 一个非常直观的对比：创建一万个线程
// 平台线程版（可能 OOM 或巨慢）
for (int i = 0; i < 10_000; i++) {
    new Thread(() -> { sleep(1000); }).start();
}

// 虚拟线程版：轻松创建，资源占用极小
for (int i = 0; i < 10_000; i++) {
    Thread.ofVirtual().start(() -> { sleep(1000); });
}

// 方式一：ofVirtual()，可命名、设置异常处理器
Thread vt = Thread.ofVirtual()
        .name("worker-", 0)
        .uncaughtExceptionHandler((t, e) -> System.err.println(t + " 异常: " + e))
        .start(() -> System.out.println("hello"));

// 方式二：Executors 工厂
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<?> f = executor.submit(() -> doTask());
}

// 方式三：Thread.startVirtualThread 便捷静态方法
Thread t = Thread.startVirtualThread(() -> System.out.println("快捷创建"));

阻塞时 JVM 自动执行的三个动作：
  1. 当前虚拟线程被卸载（unmount），状态存入堆
  2. 载体线程从就绪队列拉取下一个虚拟线程运行
  3. 阻塞结束后虚拟线程重新装载（mount）到某个空闲载体

对开发者完全透明，你写的还是同步代码

// 关键概念：不需要自己调度，JVM 帮你做
// 但要注意：synchronized 块内虚拟线程不会让出载体（锁不参与 unmount）
synchronized (lock) {
    // JVM 不在此处做调度让出，可能阻塞整个载体线程
}

Pin 检测：
  -XX:+PrintVThreadEvents 可打印虚拟线程挂载/卸载日志
  -Djdk.tracePinnedThreads=full 会输出被钉住的线程栈

避免 Pin 的手段：
  1. 用 ReentrantLock 代替 synchronized
  2. 把 IO 移出 synchronized 块
  3. JDK 24 起 synchronized 已支持卸载，此问题逐步缓解

// 排查 Pin：jcmd 线程转储时看是否有 pinned 标记
// jcmd <pid> Thread.dump_to_file -format=json threads.json
// 虚拟线程状态中若出现 carrierThread 一直被占用，说明存在 Pin

// JDK 21：StructuredTaskScope 让并发任务有"作用域"
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<String> user  = scope.fork(() -> fetchUser());
    Future<Order> order = scope.fork(() -> fetchOrder());

    scope.join();            // 等待所有子任务
    scope.throwIfFailed();   // 任一失败则抛出第一个异常

    String userResult = user.resultNow();   // 不阻塞，直接取结果
    Order orderResult = order.resultNow();
}
// 离开 try 块自动 join + 取消未完成任务，生命周期清晰

// 反模式：用固定线程池执行 IO 密集任务，池小则整体吞吐受限
ExecutorService pool = Executors.newFixedThreadPool(200);
pool.submit(() -> ioCall());   // 200 个并发之外的请求只能排队

// 虚拟线程模式：不需要池，来一个起一个
try (var pool = Executors.newVirtualThreadPerTaskExecutor()) {
    pool.submit(() -> ioCall());  // 百万并发也没问题
}

一个典型的 IO 密集基准（每秒请求数）：

平台线程（200 线程池）    ≈ 2000 req/s   上限被池大小锁死
Netty 异步回调           ≈ 12000 req/s   代码复杂度高
虚拟线程（阻塞式代码）     ≈ 11000 req/s   代码与同步版无异

结论：虚拟线程能以同步代码拿到接近异步框架的吞吐。

// 最佳实践：虚拟线程要配合"短栈帧"的阻塞点才高效
// 好的写法：阻塞点集中在少数方法里，调用栈浅
String result = httpClient.send(req, BodyHandlers.ofString()).body();

// 坏的写法：在递归/深栈里做 IO，栈增长 + GC 压力大

CompletableFuture 异步编排的问题：
  1. 组合越多，回调嵌套越深，调试越难
  2. 异常栈丢失上下文，线上定位困难
  3. 默认使用 ForkJoinPool.commonPool，池小则排队

虚拟线程 + StructuredTaskScope 替代：
  还是同步代码，顺序自然，栈完整

// 异步版（编排链）
CompletableFuture.supplyAsync(() -> fetchA())
    .thenCombine(CompletableFuture.supplyAsync(() -> fetchB()), (a, b) -> a + b)
    .thenAccept(System.out::println);

// 虚拟线程版（同样的并发，同步写法）
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<String> fa = scope.fork(() -> fetchA());
    Future<String> fb = scope.fork(() -> fetchB());
    scope.join();
    System.out.println(fa.resultNow() + fb.resultNow());
}

// 推荐：IO/阻塞操作放在锁外，或用 ReentrantLock 代替 synchronized
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // 临界区只放内存操作，别放 IO
} finally {
    lock.unlock();
}

// ScopedValue：结构化、只读、随作用域传递
private static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();

String result = ScopedValue.callWhere(REQUEST_ID, "req-123",
        () -> handleRequest());   // 作用域内可见，子任务自动继承

void handleRequest() {
    String id = REQUEST_ID.get();   // 在并发子任务中也能读到
    // 只读，不随线程池复用而串值
}

1. 找出 IO 密集型阻塞代码（HTTP、DB、MQ、文件）
2. 把 ExecutorService.submit(...) 换成 newVirtualThreadPerTaskExecutor
3. 如果用了 CompletableFuture 做编排，改用 StructuredTaskScope
4. 排查 synchronized 与 ThreadLocal，替换为 ReentrantLock / ScopedValue
5. 压测对比吞吐与 GC，确认无栈内存暴涨

// Spring Boot 3.2+：一行配置启用虚拟线程
// spring.threads.virtual.enabled=true