面经策

什么是结构化并发？它解决传统线程编排的什么问题？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

结构化并发（Structured Concurrency，JDK 21 预览/JEP 453 起，21~25 持续演进）是把"一组并发任务"当作"一个工作单元"管理的编程模型：用 StructuredTaskScope 把子任务的生命周期绑定到父作用域——父块不结束，子任务不遗留；一个失败，兄弟任务自动取消。

它解决传统线程编排的什么问题，我按业务事故来讲最直观：

  1. 线程泄漏：传统 executor.submit() 提交后任务就"撒手"了——父请求超时返回，子任务还在后台跑，占用资源、可能重复执行副作用（比如取消订单的请求返回了，退款任务还在跑）。结构化并发保证"请求结束=相关任务全部终结"，泄漏与幽灵任务从机制上消除；
  2. 取消传播混乱：手动管理取消标志、中断信号的传递，代码又长又容易漏；结构化作用域内取消自动传播到全部子任务；
  3. 异常聚合与归属：子任务异常丢进 Future 常常被吞（没人 get）——线上"任务莫名没执行"的经典根因；作用域统一收集异常，fail-fast 或聚合上报；
  4. 可观测性：线程转储里父子关系清晰可见，排障不用猜"这个线程是谁派来的"。

与虚拟线程是天作之合：任务廉价（虚拟线程）+ 生命周期可控（结构化并发），才是完整的并发故事。

业务价值：并发编排的正确性从"靠程序员自觉"变成"语言机制保证"——减少的是线上事故与排障工时，这类隐性成本在金融、交易类系统里往往比开发效率更值钱。建议在 Java 21+ 的并行调下游场景（聚合查询、并行风控）优先采用。

🏗 系统架构师 ​

结构化并发（Structured Concurrency，JDK 21 预览、21→25 演进）= 并发任务的生命周期与代码块作用域绑定：子任务在作用域内创建，作用域结束前必须全部完成——并发结构像"结构化控制流"一样有层级。

java
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Subtask<User> u = scope.fork(() -> queryUser(id));
    Subtask<Order> o = scope.fork(() -> queryOrder(id));
    scope.join().throwIfFailed();   // 等全部，任一失败则取消其余
    return new Detail(u.get(), o.get());
}

解决传统线程编排的什么问题：

  • 泄漏（孤儿任务）：executor.submit 的任务"发射后不管"——异常路径提前返回时子任务还在跑，浪费资源且可能产生错乱写；结构化并发 scope 结束 = 子任务全部终止（成功/取消），生命周期封闭无泄漏；
  • 错误传播混乱：传统 Future 要手工聚合异常、逐个 cancel（还经常取消不掉）；ShutdownOnFailure/ShutdownOnSuccess 策略内置"一败俱败/成功即取"语义——像同步代码一样 try-catch；
  • 取消传播：父线程被中断（如请求超时）自动级联取消全部子任务——传统方案要自己维护取消链；
  • 可观测性：任务树结构天然映射到线程 dump/trace——"这个请求的三个子任务"是树上一条路径，排查不再需要在几千个线程名里捞针。

架构师视角：这与虚拟线程是一对组合拳——廉价线程提供"并发自由"，结构化并发提供"并发纪律"；配合 ScopedValue 实现上下文安全传递。它是"Go errgroup / Kotlin coroutineScope"思想的 Java 化，服务化架构里的并发编排（多下游聚合、扇出查询）应当全面迁移。

💻 全栈开发专家 ​

结构化并发（Structured Concurrency，JDK 21 preview / JDK 25 JEP 505 转正）核心理念：并发任务的生命周期必须嵌套在创建它的代码块作用域内——父任务等齐所有子任务，异常和取消自动传播。

解决传统线程编排的老问题：

  1. 任务泄漏：executor.submit 后没人管子任务死活，异常被吞（Future.get 才炸）；
  2. 取消不传播：一个子任务失败，兄弟任务还在空跑浪费资源；
  3. 错误处理割裂：要手写 invokeAll/CountDownLatch/CompletableFuture 组合，样板代码多还易错。

新 API（JDK 25）：

java
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Subtask<Order> order  = scope.fork(() -> orderService.get(id));
    Subtask<User>  user   = scope.fork(() -> userService.get(uid));
    Subtask<Logis> logis  = scope.fork(() -> logisService.track(no));

    scope.join()            // 等全部完成
          .throwIfFailed(); // 任一失败：取消其余，异常向上抛

    return render(order.get(), user.get(), logis.get());
}  // scope 关闭时保证无泄漏线程

和虚拟线程是天作之合：scope.fork 默认在虚拟线程上跑子任务——fork 几十个下游调用毫无压力；ShutdownOnFailure 给「任一失败就放弃」的扇出语义，还有 ShutdownOnSuccess（竞速取最先成功，跨区多活调用的经典需求）。

实战要点：作用域内不要提前 return（漏 join 导致 IllegalStateException 的隐式等待）；超时用 scope.joinUntil(deadline)；结构化并发管「一批任务的边界」，配合虚拟线程管「任务便宜地跑」——两者组合后，我写并发聚合代码的出错率肉眼可见地下降。