Java 结构化并发预览特性适合替代哪些任务编排

Java 结构化并发最适合替代的是“一个请求拆成几个并行子任务，父任务必须统一等待并一起结束”的编排。它不是消息队列，也不是后台任务调度器：如果子任务要脱离请求独立重试、跨进程持久化或长期运行，仍应使用队列、调度器或专门的执行服务。

判断标准很简单：子任务和父任务是否拥有同一生命周期？如果答案是“是”，可以优先考虑 StructuredTaskScope；如果答案是“否”，不要为了追求新 API 强行迁移。

哪些任务编排适合结构化并发

典型场景是请求聚合：用户详情、配额和权限可以并行查询，但接口只有在这些结果准备好后才能返回。父方法打开一个作用域，子任务在作用域内创建，结果在 join 后读取，生命周期自然形成一棵树。

最小写法：用 Joiner 表达编排策略

下面示例按 Java SE 26 预览 API 写法组织两个同类型结果。allSuccessfulOrThrow 表示全部成功才聚合；若只要首个成功结果，可以改用相应的“任一成功” Joiner，但其余任务仍要能处理中断。

import java.time.Duration;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.StructuredTaskScope;

static List loadProfile(String userId) throws InterruptedException {
    var tasks = List.of(
        (Callable) () -> queryUser(userId),
        (Callable) () -> queryQuota(userId)
    );

    try (var scope = StructuredTaskScope.open(
            StructuredTaskScope.Joiner.allSuccessfulOrThrow(),
            config -> config.withTimeout(Duration.ofSeconds(2)))) {
        // 只在作用域内并行启动属于本次请求的子任务
        tasks.forEach(scope::fork);
        // Joiner 决定全部成功、失败传播和最终返回形态
        return scope.join().map(StructuredTaskScope.Subtask::get).toList();
    } catch (StructuredTaskScope.FailedException ex) {
        // 保留首个失败原因，交给上层映射为业务错误
        throw new IllegalStateException("profile dependencies failed", ex.getCause());
    }
}

注意两个边界。第一，Subtask.get() 要在 join 之后读取；第二，示例的超时从打开作用域时开始计算，不是从每个 fork 单独开始。若依赖返回类型不同，可使用不返回聚合值的 Joiner，然后在 join 后分别读取各个 Subtask。

失败传播和取消为什么更容易收口

传统 Future 编排经常要分别保存 Future、轮询异常，再补一段取消逻辑。结构化并发把策略放进作用域：子任务失败时 Joiner 可以取消作用域，join 以 FailedException 暴露原始原因；超时则抛出预览的 TimeoutException。close 还会等待已启动的线程结束，所以“取消已发出”不等于“方法可以立即返回”。

因此底层调用不能吞掉中断后继续工作。捕获 InterruptedException 时通常应恢复中断标记并尽快返回；不可中断的阻塞操作也可能拖慢 close。这正是它比“提交任务后各自放飞”更可靠的地方，也是迁移前必须检查的代价。

上线前的预览开关和边界清单

预览特性会随 JDK 版本调整，示例不能直接当作永久 API 契约。用目标 JDK 的官方 API 文档确认方法名，再为编译和运行分别打开预览开关，例如 javac --enable-preview --release 26 Demo.java 与 java --enable-preview Demo。生产采用前至少检查：

• 子任务是否都属于当前请求，是否有脱离父任务继续运行的需求；
• 外部调用是否有总超时，取消后是否真正响应中断；
• 异常映射是否保留 FailedException.getCause()，日志是否能关联父任务和子任务；
• 升级 JDK 后是否重新阅读目标版本的预览 API，而不是只沿用旧示例。

常见问题

它能完全替代 ExecutorService 吗？

不能。它更适合有明确父子生命周期的并发工作；独立队列、长期任务和复杂调度仍需要其他执行模型。

一个子任务失败时，其他子任务一定会停止吗？

取决于 Joiner 策略；会取消的策略通过中断通知未完成子任务，但底层代码必须主动响应中断，不能把取消当作强制终止。

为什么要在 join 后才能调用 Subtask.get？

因为 get 读取的是已经完成的子任务结果。先读取会破坏作用域对结果和生命周期的统一管理。

预览 API 适合直接用于公共库吗？

要谨慎。预览 API 可能在后续 JDK 改名、调整或移除，公共库应隔离适配层并明确目标 JDK。