Java 结构化并发怎样处理子任务失败

Java 结构化并发处理子任务失败的关键，不是给每个 Callable 单独套一层 try-catch，而是让作用域所有者统一决定失败传播策略。JDK 25 的 StructuredTaskScope 仍属于预览 API：默认作用域中任一子任务失败时，会取消尚未完成的兄弟任务，join() 抛出 StructuredTaskScope.FailedException，其原因可从 getCause() 取得。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html

先把失败传播链路分清楚

fork() 只负责启动子任务，真正等待和汇总发生在所有者线程调用 join() 时。默认的 StructuredTaskScope.open() 等待所有子任务成功；一旦有一个失败，作用域进入取消状态，其他未完成任务收到中断，join() 抛出包装后的 FailedException。因此，不能只检查某个 Subtask 的状态来判断整个请求是否成功。

如果需要“任一成功即可返回”或“收集全部结果”，应使用对应的 Joiner，不要把默认策略误用到容错聚合场景。本文只聚焦默认的失败即取消，适合要求多个子任务共同完成的请求。

在所有者线程统一转换异常

异常处理应放在 try-with-resources 外层，既能接住 join() 的失败，也能让作用域自然关闭。下面的示例模拟同时读取用户资料和账单摘要；任一读取失败时，对外返回统一的业务异常，内部原因只写入带请求标识的日志。

import java.util.concurrent.StructuredTaskScope;

record Summary(String user, String billing) {}

static Summary loadSummary(String requestId) throws InterruptedException {
    try (var scope = StructuredTaskScope.open()) {
        var user = scope.fork(() -> loadUser(requestId));
        var billing = scope.fork(() -> loadBilling(requestId));

        // join 统一等待；任一子任务失败时会取消未完成的兄弟任务。
        scope.join();

        // join 成功后再读取结果，不要在等待前调用 get。
        return new Summary(user.get(), billing.get());
    } catch (StructuredTaskScope.FailedException ex) {
        // 只把原始原因写入内部日志，避免把数据库或网络细节返回给调用方。
        Throwable cause = ex.getCause();
        logFailure(requestId, cause);
        throw new IllegalStateException("并行资料读取失败", cause);
    }
}

static String loadUser(String requestId) throws Exception {
    // 真实实现应让底层客户端在收到中断时尽快结束。
    return "user:" + requestId;
}

static String loadBilling(String requestId) throws Exception {
    return "billing:" + requestId;
}

这里的 getCause() 才是子任务抛出的原始异常，FailedException 是作用域对外的失败信号。若直接把 cause 的消息返回 HTTP 响应，可能泄露数据库地址、上游响应或内部路径；更稳妥的做法是记录 requestId、任务名、失败类型和取消状态，再对外返回稳定错误码。

取消能否生效，取决于子任务是否尊重中断

作用域取消会中断未完成的子任务，但 Java 中断本身只是协作信号。循环应主动检查中断；阻塞调用应使用可中断 API，或在捕获 InterruptedException 后恢复中断状态并结束任务。否则 close() 仍会等待该线程，外层请求就可能在“已经失败”后继续占用资源。

实践中至少保留三类检查：子任务是否会因中断退出；连接、文件和响应体是否在子任务内部关闭；失败后是否能区分“首个失败原因”和“被取消的兄弟任务”。被取消的任务通常不应覆盖首个失败原因，否则排障日志会被次生中断淹没。

Java 结构化并发失败处理清单

编译和运行示例需要显式开启预览特性，例如使用 javac --enable-preview --release 25 与 java --enable-preview。生产采用前还应确认目标 JDK 的预览 API 生命周期，因为预览特性可能在后续版本改变或移除。

相关问题

FailedException 是不是每个子任务异常都会各抛一次？

不是。作用域所有者的 join() 抛出一次失败信号，具体 cause 由 Joiner 和完成顺序决定；需要多错误汇总时应选择相应 Joiner 或在子任务内部显式收集结果。

子任务捕获异常后返回默认值可以吗？

可以，但这会把“失败”转换成“成功结果”，只有业务确实允许降级时才这样做，并在结果中保留降级标记。

为什么 catch 之后请求仍然变慢？

通常是兄弟任务没有响应中断，或者底层调用不可中断。先检查子任务的阻塞点和资源关闭，再调整超时或替换为可中断调用。