Java 结构化并发任务作用域的取消传播

我第一次把一组“同时查数据”的后端任务放进 Java 结构化并发作用域时，最容易误判的不是怎么启动子任务，而是取消之后谁负责收尾。Java 25 的 StructuredTaskScope 仍属于 preview API：作用域被取消时，未完成的子任务会收到中断，但 close() 还会等待这些线程真正结束。

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

把取消理解成“向作用域内未完成任务传播中断”，再把 join() 的异常结果与 close() 的资源收尾分开处理，代码就不容易把取消当成立即终止。

• 作用域取消：阻止新的子任务启动，并中断仍未完成的子任务。
• 结果判断：失败或超时可能让 join() 抛出 preview 异常，具体取决于 Joiner。
• 收尾边界：close() 会等待子任务结束，因此任务必须尽快响应中断。

取消传播先看作用域边界

StructuredTaskScope 的 owner 是打开作用域的线程，只有 owner 能调用 fork()、join() 和 close()。子任务在作用域内运行，Joiner 决定怎样观察它们的完成状态。这个关系更像一个有边界的任务树：取消发生在 scope 层，影响的是其中尚未完成的 Subtask，而不是把整个进程粗暴停掉。

默认的 open() 使用虚拟线程工厂，并等待所有子任务成功；如果某个子任务失败，作用域会取消其余未完成子任务，join() 以 FailedException 报告结果。使用其他 Joiner 时，取消也可能来自“已经拿到足够结果”的短路策略。

失败、超时和关闭分别怎么传下去

这几个词在代码里挨得很近，但含义不同。Joiner 产生异常结果时，join() 会以 FailedException 包装结果；配置了超时的作用域，在超时到达时取消并让 join() 抛出 TimeoutException。而 isCancelled() 只回答当前作用域是否已经取消或正在取消，不代表所有子线程已经退出。

close() 是 try-with-resources 的最后一道边界：它会先取消尚未取消的作用域，再中断未完成子任务，然后等待这些任务结束。如果子任务卡在不响应中断的阻塞调用里，关闭动作也会被拖住。换句话说，异常负责告诉 owner 发生了什么，close() 负责保证作用域内的线程不越过资源边界继续悬挂。

用一个最小实验处理 InterruptedException

下面的示例故意让两个子任务都具备中断响应点。代码展示的是 Java 25 preview API 的写法，重点不是业务返回值，而是被取消后立即恢复中断状态并结束当前任务。真实项目还应在 finally 中释放连接、文件或其他资源。

import java.util.concurrent.StructuredTaskScope;

public class CancelPropagationDemo {
    public static void main(String[] args) throws Exception {
        try (var scope = StructuredTaskScope.open()) {
            // 两个子任务共享作用域边界，任一失败时其余未完成任务会被取消。
            scope.fork(() -> load("profile"));
            scope.fork(() -> load("orders"));

            // owner 只在这里统一等待；join 只调用一次，并处理等待期间的中断。
            scope.join();
        } catch (StructuredTaskScope.FailedException ex) {
            // 先记录失败原因；try-with-resources 仍会负责关闭作用域。
            System.err.println("subtask failed: " + ex.getCause());
        }
    }

    static String load(String name) {
        try {
            // 示例等待代表可中断的网络或数据库等待，不代表真实运行结果。
            Thread.sleep(2_000);
            return name + "-ok";
        } catch (InterruptedException ex) {
            // 不能吞掉中断信号；恢复状态后尽快结束子任务。
            Thread.currentThread().interrupt();
            return name + "-cancelled";
        }
    }
}

编译和启动 preview 示例时，需要明确打开 preview 能力：

# 使用 JDK 25 编译 preview API；--release 与运行时版本保持一致。
javac --enable-preview --release 25 CancelPropagationDemo.java

# 运行时也必须开启 preview，否则 StructuredTaskScope 不能按示例加载。
java --enable-preview CancelPropagationDemo

这里没有把 InterruptedException 继续向上抛出，是因为子任务的策略是“取消后返回取消状态并结束”。如果业务无法安全返回默认值，可以在恢复中断状态后抛出包装异常，但不要捕获后继续执行原来的耗时循环。

项目里怎么判断这套写法合适

我会先看三个条件。第一，项目是否已经接受 Java 25 preview API 的发布和回滚成本；结构化并发不是普通稳定 API，未来版本可能调整。第二，子任务调用链是否能响应中断，尤其是数据库、HTTP 客户端和自定义锁等待。第三，close() 等待的资源是否有明确上限，不能因为“已经取消”就假设线程立刻消失。

如果只是把几个互不依赖的计算并行化，却无法让下层调用停止，那么取消传播只完成了一半：scope 已经标记取消，线程仍可能拖住关闭。相反，当任务天然属于同一个请求、失败后剩余结果没有意义，并且下层能正确处理中断时，作用域边界会比散落的 Future 更容易说明生命周期。

常见问题

取消作用域会立即杀掉子线程吗？

不会。取消会阻止新线程启动并中断未完成子任务，但子任务必须自己响应中断；close() 还会等待它们结束。

join 抛出异常后还需要 close 吗？

需要。推荐使用 try-with-resources，让 close 统一处理取消和等待；不要把 join 的异常当作资源已经释放的证明。

isCancelled 为 true 是否说明所有任务都已退出？

不是。它只表示作用域已取消或正在取消，未完成任务仍可能处于清理阶段。