StructuredTaskScope 是防止孤儿线程的唯一有效边界，它通过作用域契约绑定子任务生命周期，要求必须用 try-with-resources 配合 ShutdownOnFailure/ShutdownOnSuccess，并确保子任务响应中断。
StructuredTaskScope 是防止孤儿线程的唯一有效边界
Java 中所谓“孤儿线程”，本质是子任务脱离了父上下文的生命周期管控，继续在后台运行、持有资源、无法被取消或追踪。而 StructuredTaskScope 不是工具类，它是 JVM 强制执行的**作用域契约**：只要子任务通过 scope.fork() 启动，它的生命周期就绑定到 scope 实例上——scope.close()（或 try-with-resources 自动关闭）那一刻，所有未完成的子任务都会收到中断信号并终止，无论它们跑在虚拟线程还是平台线程上。
必须用 try-with-resources + ShutdownOnFailure / ShutdownOnSuccess
直接 new 一个 StructuredTaskScope 而不配合 try-with-resources，等于放弃结构化保障。JVM 不会自动帮你 close，一旦忘记，照样泄漏。
-
StructuredTaskScope.ShutdownOnFailure：任一子任务抛异常，立即向其余子任务发送中断，适合“全成功才有效”的场景（如并行查用户+订单） -
StructuredTaskScope.ShutdownOnSuccess：任一子任务成功返回，立刻取消其余子任务，适合“取最快结果”的竞速场景（如多源查缓存） - 别用裸
StructuredTaskScope—— 它不自动传播异常也不自动取消，退化成 ExecutorService
子任务里必须响应中断，否则 scope.cancel() 白费
scope.join() 或 scope.close() 触发的是标准 Thread.interrupt()，但若子任务逻辑里没检查 Thread.currentThread().isInterrupted()，或没捕获 InterruptedException 并退出，线程就会继续跑下去，变成事实上的孤儿。
- 阻塞调用（如
Thread.sleep()、queue.take()、socket.read()）天然响应中断，但之后要主动退出循环或方法 - 计算密集型循环必须显式插桩：
if (Thread.currentThread().isInterrupted()) return; - 调用第三方库前，确认它是否支持中断；不支持的（如某些老版 JDBC 驱动），需包裹在
try { ... } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; }中
别把虚拟线程当“免死金牌”，Scope 才是安全阀
有人误以为用了 Thread.ofVirtual().start() 就不会泄漏——错。虚拟线程只是轻量，不是自动受管。10000 个裸虚拟线程并发启动又不加作用域，照样吃光内存、拖垮调度器、让监控看不到调用链。
- 所有异步子任务，只要属于同一业务逻辑单元（比如一次 HTTP 请求处理），就必须统一纳入同一个
StructuredTaskScope - Spring WebMvc 或 WebFlux 控制器中，不要在 @PostMapping 方法里直接 fork，应在 service 层封装好 scope 逻辑，控制器只负责传参和返回
- 日志、Metrics、Tracing 上下文必须用
ScopedValue，而非ThreadLocal——后者在虚拟线程切换时失效，导致 MDC 丢失、traceId 断裂，间接掩盖孤儿行为
真正容易被忽略的点是：结构化并发的防护能力完全依赖「作用域嵌套深度」与「中断响应完整性」的双重对齐。少写一行 isInterrupted() 检查，或漏掉一个 try-with-resources，整个防护链就断了——这不是配置问题，是代码契约的履行问题。
