Java 25 StructuredTaskScope 预览并发聚合：open、join 与超时边界

商品详情接口经常不是查一次数据库就能搞定的：价格、库存、推荐位分别来自不同服务，串行调用会把三段耗时直接叠加，随手开线程又容易留下超时、异常未处理、资源没回收的隐患。Java 25 的 StructuredTaskScope 正好针对这类单次请求拆分多个并发子任务的场景，不过它目前仍是预览 API，不能直接把示例代码当成稳定版生产级实现的依据。

先把一次商品请求画成一棵并发树

假设 /api/product/detail 收到商品 ID 后，需要同时拉取价格、库存和推荐商品数据。最先要确认的不是要不要开三个线程，而是这三个结果是不是都属于同一个请求生命周期：请求结束时它们都应该同步终止，任一关键结果失败时，剩下的子任务工作是否还有继续执行的价值。

这就是结构化并发的核心边界：子任务不是脱离请求的游离后台任务，而是被一个 scope 完全包裹的关联单元。调用方只需要等待这棵并发任务树执行收敛，不用额外维护线程列表、Future 列表，也不用手写逐个取消的补丁逻辑。

open、fork、join 各自负责什么

Java 25 的 API 入口是静态工厂方法 open()，不是旧预览版本里常见的构造器写法。下面的示例把三个下游调用并行启动，在作用域内统一做等待收敛：

import java.util.concurrent.StructuredTaskScope;

record ProductView(Price price, Stock stock, Recommendations recommendations) {}

ProductView loadProduct(long productId) throws Exception {
    try (var scope = StructuredTaskScope.

fork 返回的是 scope 托管的 Subtask。读取结果前必须先执行 join；默认策略要求所有子任务都执行成功，否则聚合阶段直接抛出 FailedException。这里的 try 也不是多余的语法糖：离开代码块时自动关闭 scope，能让子任务生命周期完全跟着请求边界收拢。

超时不是一个参数，而是一条结果边界

聚合接口最容易漏掉的场景是：价格服务已经返回，库存服务卡在网络重试，推荐服务还没开始响应。Java 25 可以在打开 scope 时直接配置超时规则，超时起点是 scope 创建的时刻，而不是某个子任务 fork 的时刻。

try (var scope = StructuredTaskScope.

超时后的返回值要提前在业务上明确定义。如果库存是下单前的强约束，就应该返回明确的“库存暂不可用”提示，不能把过期的旧库存伪装成实时库存。如果推荐只是页面增强信息，可以在单独的 joiner 或者子任务内部把它降级为空列表。

Java 25 预览 API 的编译与上线检查

最小验证命令如下，编译和运行两个环节缺一不可：

javac --release 25 --enable-preview ProductAggregation.java
java --enable-preview ProductAggregation

预览 API 可能在后续版本中继续调整，甚至被移除。工程上建议把 JDK 版本、启动参数、CI 编译参数和回滚方案写进服务清单；不要只在本地 IDE 里勾选“启用预览”，却忘了配置容器的启动脚本。

常见问题

StructuredTaskScope 能替代所有 CompletableFuture 吗？

不能。它更适合单个请求内部的并发子任务树管理和生命周期收口；需要跨请求编排、运行长期流水线，或者依赖现有 CompletionStage 生态的场景下，CompletableFuture 仍然是更合适的选择。

为什么示例必须使用 --enable-preview？

因为 Java 25 官方文档仍将 StructuredTaskScope 标为预览 API。没有该参数，编译器和运行时都不会把这段代码当成普通稳定 API 来正常加载执行。

fork 后能直接调用 get 吗？

不建议这么写，也不要依赖这种调用顺序的行为。先调用 join，再根据子任务状态读取结果，才能让成功、失败和超时的执行路径保持完全一致。

超时后还能把已完成的价格返回给用户吗？

可以，但要结合产品规则判断，还要在响应里明确标注“实时价格”和“部分结果”的差异。对库存、权限这类关键字段，宁可明确返回降级提示，也不要返回看起来完整但实际已经过期的数据。

把并发收益和版本风险一起验收

StructuredTaskScope 的价值不只是把三次调用改成并行执行，而是让请求、子任务、失败传播和超时形成同一个可观测的边界。上线前至少要压测完整成功、关键下游失败、scope 超时三条路径，确认日志能关联商品 ID、scope 名称和首个失败原因。等预览 API 的版本策略完全明确后，再决定要不要把这段实现升级为长期使用的基础设施组件。