Java 结构化并发预览 API 怎么确保子任务一起结束

Java 里同时查用户资料和订单时，分别创建两个线程并不等于它们能被可靠收尾。更稳妥的做法是把任务放进 StructuredTaskScope：在 try-with-resources 中 fork 子任务，调用 join() 统一等待，最后由 close() 负责取消并等待未完成任务。这样子任务的生命周期不会跑出父任务的代码块。

想确保子任务“一起结束”，关键不是调用一次 join()，而是同时满足三个条件：作用域用 try-with-resources 管理；失败或超时能取消同组任务；子任务对中断信号尽快退出。

先把“并发完成”与“生命周期收口”分开

StructuredTaskScope 的价值不只是让两个任务并行执行，而是把它们登记为一个有边界的子任务集合。父任务负责 fork 和 join，子任务的结果或异常再回到父任务处理。当前 API 是预览能力，Java 25 示例需要 --enable-preview；后续 JDK 版本仍可能调整签名，因此上线前要按目标 JDK 的 API 文档编译。

用一个作用域等待两个子任务

下面的示例模拟一个页面需要同时读取资料和订单。open() 的默认语义适合“两个结果都必须有”的场景；如果任一任务失败，join() 会抛出 FailedException，另一个未完成任务也会被取消。

import java.util.concurrent.StructuredTaskScope;

record UserCard(String name) {}
record OrderSummary(int count) {}

static String loadDashboard(String userId) throws Exception {
    try (var scope = StructuredTaskScope.open()) {
        var profile = scope.fork(() -> loadProfile(userId)); // 并发读取用户资料
        var orders = scope.fork(() -> loadOrders(userId));   // 并发读取订单摘要

        scope.join(); // 等待全部成功，或在失败时结束等待
        return profile.get().name() + " / " + orders.get().count(); // join 后再取结果
    } catch (StructuredTaskScope.FailedException e) {
        // 统一处理子任务失败；具体原因在 cause 中
        throw new IllegalStateException("dashboard load failed", e.getCause());
    }
}

static UserCard loadProfile(String userId) throws InterruptedException {
    return new UserCard("user-" + userId); // 示例中省略外部服务调用
}

static OrderSummary loadOrders(String userId) throws InterruptedException {
    return new OrderSummary(3); // 示例中省略数据库查询
}

这里的 profile 和 orders 是 Subtask 句柄，不是已经完成的值。只有 owner 调用 join() 等待后，且对应子任务确实成功，get() 才能安全读取结果。把 get() 提前到 join() 之前，既违背 API 使用边界，也会让代码失去结构化并发的清晰约束。

失败传播并不等于强制杀线程

当资料任务抛出异常时，作用域会取消尚未完成的订单任务。取消的实现是中断执行子任务的线程，因此子任务应该在阻塞调用处保留中断语义：捕获 InterruptedException 后恢复中断状态或直接继续抛出，并释放自己的连接、文件和临时资源。

close() 的边界更容易被忽略。它会先取消作用域，再等待所有子线程完成，即便当前线程在等待过程中再次被中断，也会优先把子任务收完。因此，一个永远不检查中断标志、或卡在无法响应中断的外部调用上的子任务，可能让父任务退出变慢。结构化并发能约束生命周期，但不能替业务代码修复不可取消的依赖。

超时和版本边界要单独检查

需要时间上限时，应使用目标 JDK 提供的带配置 open 形式设置 timeout，让超时成为作用域的取消原因之一；不要只在父线程外层加一个计时器，却忘记通知子任务。超时、子任务异常和父线程被中断是三种不同结果，日志中应分别记录，排查时才知道是依赖慢、任务失败还是调用方取消。

部署前至少检查三件事：编译和运行命令都带 --enable-preview；生产依赖是否能在中断后及时返回；JDK 升级时 StructuredTaskScope、Joiner 和异常类型的签名是否变化。预览 API 适合验证并发模型，但不应被误写成已经稳定不变的公共契约。

相关问题

只调用 join，不使用 try-with-resources 可以吗？

不建议。join() 负责等待当前聚合结果，close() 才负责取消并等待作用域中的剩余任务；用资源语句能把收尾路径覆盖到异常分支。

子任务失败后另一个任务一定立刻停止吗？

不一定。取消会发出中断，但任务必须配合检查中断或从可中断阻塞中返回；忽略中断的代码仍可能继续运行一段时间。

为什么不能在子线程里调用 scope.join？

作用域由打开它的线程拥有，fork、join 和 close 都要求 owner 调用。子任务只负责执行工作和返回结果，不负责管理父作用域。