StructuredTaskScope 是 Java 21 引入的结构化并发核心 API，本质是显式建模任务生命周期边界，强制子任务在父作用域内完成或取消，避免逃逸和资源泄漏；而普通线程池（如 ExecutorService）提交的任务脱离调用栈控制，无自动生命周期约束。

StructuredTaskScope 是什么，它和普通线程池有什么本质区别 StructuredTaskScope 是 Java 21 引入的结构化并发（Structured Concurrency）核心 API，不是线程池替代品，而是对“任务生命周期边界”的显式建模。它强制子任务必须在父作用域内完成或取消，避免任务逃逸、资源泄漏和孤儿线程。 普通 ExecutorService 提交的任务一旦启动，就脱离调用栈控制；而 StructuredTaskScope 的每个 fork() 都绑定到当前作用域生命周期——作用域关闭时，未完成子任务会被自动中断（可配置策略），且 close() 会阻塞等待所有子任务终止（或超时）。 常见错误现象：用 ExecutorService + Future.get() 手动管理多个异步调用，但忘记处理异常导致部分 Future 挂起，或未 shutdown 导致线程泄露。

使用场景包括：并行调用多个微服务接口、批量文件解析、分片数据库查询等需要「全成功才继续，任一失败即中止」或「取最快结果」的协同任务。

如何正确创建和使用 StructuredTaskScope StructuredTaskScope 是抽象类，需选择具体子类：

• StructuredTaskScope.ShutdownOnFailure：任一子任务抛异常或返回 null，立即中断其余运行中任务，并在 close() 时抛出第一个异常 —— 适合「全有或全无」场景
• StructuredTaskScope.ShutdownOnSuccess：首个子任务成功返回，立刻中断其余任务 —— 适合「取最快响应」，如多 CDN 择优下载
• StructuredTaskScope.ShutdownOnFailure 和 ShutdownOnSuccess 都支持自定义中断策略和超时

关键实操建议：

• 必须用 try-with-resources 保证 close() 被调用，否则子任务可能永远挂起；不能手动调用 close() 多次
• 子任务必须通过 scope.fork(() -> {...}) 启动，不能直接 new Thread 或 submit 到外部 Executor
• 不要在 fork 的 lambda 中捕获并吞掉 InterruptedException，否则会破坏结构化中断传播
• 示例：

  try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
      var future1 = scope.fork(() -> fetchFromDB());
      var future2 = scope.fork(() -> callExternalAPI());
      scope.join(); // 等待全部完成或首个失败
      scope.throwIfFailed(); // 抛出首个异常（若存在）
      return List.of(future1.get(), future2.get());
  }

为什么 join() 后还要调用 throwIfFailed() join() 只是同步等待所有子任务结束（正常完成、异常退出或被中断），但它不主动抛异常 —— 它把异常“存起来”，等你显式检查。这是有意设计：允许你在 join 后做状态判断，比如只在特定条件下才失败回滚。 容易踩的坑：

• 忘记调用 throwIfFailed()，导致子任务已抛 IOException，但主流程静默继续，后续逻辑用到 null 结果而 NPE
• 在 join() 前就调用 throwIfFailed()，此时子任务可能还在跑，方法直接返回 false，不抛异常
• throwIfFailed() 抛出的是封装后的 ExecutionException，其 cause 才是原始异常，日志里不 unwrap 就看不到真实错误源

性能影响：相比裸线程，结构化并发有极小的上下文跟踪开销（ThreadLocal + Scope 栈帧），但换来的是可预测的生命周期和调试能力 —— 在高并发服务中，这点开销远低于排查一个漏掉的 shutdown 或孤儿线程的成本。

与虚拟线程配合使用的注意事项 StructuredTaskScope 默认使用当前线程的 CarrierThread（即平台线程）执行子任务，但你可以传入虚拟线程工厂：

Thread.ofVirtual().factory()

这样 fork 出的任务会在虚拟线程上运行，大幅提升吞吐量。但要注意：

• 虚拟线程不可打断（interruptible 为 false），所以 ShutdownOnFailure 的中断机制对它们无效 —— 实际触发的是 Thread.stop() 级别协作式取消（依赖任务自身检查 Thread.currentThread().isInterrupted()）
• 若子任务阻塞在传统 I/O（如 SocketInputStream.read()），虚拟线程会被挂起，但 StructuredTaskScope 仍能正常超时中断该虚拟线程（JVM 层面支持）
• 不要在 fork 的 lambda 中调用 Thread.sleep() 或长时间忙循环，这会浪费虚拟线程调度资源；应改用 CompletableFuture.delayedExecutor() 或异步 I/O

最易被忽略的一点：结构化并发的价值不在“更快”，而在“可推理”。当你看到一段代码用了 StructuredTaskScope，你就知道它的并发边界是清晰的、异常是收敛的、超时是统一的 —— 这比任何性能数字都更影响长期维护成本。