StructuredTaskScope通过作用域边界统一管理虚拟线程生命周期，实现自动取消、异常聚合与资源清理，解决裸调用Thread.ofVirtual().start()导致的OOM、异常丢失和资源泄漏问题。
结构化并发不是“自动提升百万并发”的开关，它解决的是虚拟线程大规模调度下的生命周期管理、错误传播和资源泄漏问题——不加结构化，并发数上得去，但一出错就失控、一压测就 OOM。
为什么 Thread.ofVirtual().start() 不能直接用于生产级高并发请求
裸调用虚拟线程工厂看似简单，但每个 Thread 实例都携带独立的栈帧（堆上分配）、ThreadLocal 副本和中断状态。100 万次 start() 会瞬间创建 100 万个对象，若未显式 join() 或监控完成状态，JVM 无法及时回收其关联的栈内存和任务上下文，极易触发 GC 频繁或 OutOfMemoryError: Java heap space。
- 没有统一取消机制：某个请求超时，你无法批量中断它所属的一组虚拟线程
- 异常被吞没：子线程抛
RuntimeException，主线程默认收不到，日志里只看到“请求静默失败” - 资源未释放：比如数据库连接、文件句柄在虚拟线程中打开，但线程已结束而连接未 close，连接池迅速耗尽
StructuredTaskScope 是怎么把“百万线程”管住的
它提供作用域边界，让一组虚拟线程共享生命周期、异常聚合和自动清理语义。关键不在“并发多”，而在“可控地并发多”。
-
StructuredTaskScope.ShutdownOnFailure：任一子任务失败，立即中断其余所有运行中任务，并聚合所有异常 —— 适合强一致性场景（如分布式事务准备阶段） -
StructuredTaskScope.ShutdownOnSuccess：首个子任务成功即取消其余任务 —— 适合“找一个可用服务实例”的选主类逻辑 - 作用域退出时自动调用
close()，触发所有子线程中断 + 资源清理钩子（需配合try-with-resources）
示例：
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
scope.fork(() -> fetchFromCache());
scope.fork(() -> callDatabase());
scope.fork(() -> invokeExternalApi());
scope.join(); // 等待全部完成或首个失败
scope.throwIfFailed(); // 抛出聚合异常
}
与 ExecutorService 混用时最容易踩的坑
别把 Executors.newVirtualThreadPerTaskExecutor() 和 StructuredTaskScope 当成替代关系 —— 前者是线程复用层，后者是结构控制层。混用不当会导致作用域失效。
- 错误写法：
scope.fork(() -> executor.submit(task))：submit 返回Future，但scope管理的是外层 fork 的线程，不是 submit 内部新建的虚拟线程 - 正确做法：直接在
fork()中执行业务逻辑，或用scope.fork(() -> { ... task.run(); ... }) - 载体线程争抢：若多个
StructuredTaskScope实例同时启动大量子任务，仍可能挤占同一组载体线程（默认由ForkJoinPool.commonPool()提供），导致 I/O 阻塞任务排队 —— 此时需显式配置专用载体池
真正决定能否撑住百万请求的，其实是 I/O 层适配
虚拟线程再轻量，也改变不了底层 socket、数据库驱动、HTTP 客户端是否支持“挂起-恢复”语义。Project Loom 的调度优势只在阻塞点可识别时生效。
- JDK 21+ 的
java.net.Socket、FileChannel已原生支持虚拟线程挂起；但旧版 MySQL Connector/J（ - Spring Boot 3.1+ 默认启用虚拟线程感知的 Tomcat，但需显式配置
server.tomcat.threads.virtual.enabled=true - 手动写的
Thread.sleep()、synchronized块、JNI 调用，都会导致虚拟线程无法卸载，变成“伪并发”
结构化并发本身不加速单个请求，它只是让百万请求在崩塌前，还能被你看见、中断、归因 —— 这恰恰是压测和线上排障时最稀缺的能力。
