Java StructuredTaskScope close 的线程归属与资源回收边界

使用 StructuredTaskScope 时，close() 不是“谁都能调用的清理方法”。它必须由创建并拥有这个 scope 的线程负责；关闭时会先取消仍未结束的子任务，再等待这些线程真正结束。把 scope 放在 try-with-resources 中，通常是最稳妥的做法。

官方地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html

StructuredTaskScope.close 为什么要由 scope owner 调用

结构化并发把一次并发操作限制在一个语法块里：父线程打开 scope、fork 子任务、等待结果，最后由父线程收口。这里的父线程就是 scope owner。官方 API 对 close() 的约束很明确：调用线程不是 owner 时会抛出 WrongThreadException。

因此，不要在子任务里写“任务失败就替父线程 close scope”的补救代码。子任务可以让自身失败、响应中断，或由 joiner 触发关闭策略；真正的资源收口仍应回到创建 scope 的线程。

关闭时未完成子任务如何中断并等待回收

close() 的语义可以拆成两步：先取消 scope，未完成子任务对应的线程会被中断；随后等待这些线程结束。如果 owner 在等待期间被中断，close 仍会继续等子任务完成，返回前再恢复当前线程的中断状态。这个设计保证了离开资源块时不会把仍在运行的子任务遗留在外面。

子任务必须把中断当作退出信号处理。只捕获 InterruptedException 却继续循环，会让 close 等待很久；阻塞 I/O、外部客户端或自定义等待也要有可取消路径。

import java.util.concurrent.StructuredTaskScope;

static String loadConfig() throws Exception {
    // owner 在线程块内创建并拥有 scope，离开 try 块时由 close 统一收口
    try (var scope = StructuredTaskScope.open()) {
        var config = scope.fork(() -> readRemoteConfig());
        var fallback = scope.fork(() -> readLocalFallback());

        // 先等待 joiner 处理子任务状态，再读取结果
        scope.join();
        return config.get();
    } // close：取消未完成任务，并等待它们结束
}

static String readRemoteConfig() throws Exception {
    // 阻塞调用应能响应中断，不能吞掉退出信号后继续工作
    return remoteClient.fetchConfig();
}

static String readLocalFallback() throws Exception {
    // 示例中的本地读取也应在中断时尽快结束
    return localStore.readConfig();
}

上例重点不在“远程优先还是本地优先”，而在生命周期：scope.join() 负责等待或传播结果，try-with-resources 负责最终关闭。若使用带 joiner 的 StructuredTaskScope.open(...)，仍要保留同样的 owner 和关闭边界。

把 close 放进 try-with-resources 的落地清单

排查时先问三个问题：当前线程是不是 owner，所有子任务是否都能响应中断，scope 是否仍处在创建它的结构化代码块内。不要只把异常捕获后重试；如果线程归属或嵌套结构错误没有修复，重试只会重复同一失败。

常见问题

close 会不会只发中断然后立刻返回？

不会。它会取消未完成子任务，并等待相关线程结束；这正是结构化资源边界的一部分。

子任务捕获 InterruptedException 后还能继续处理吗？

只有在业务明确允许继续时才可以。对需要尽快退出的任务，应清理资源并结束，不能把中断当作普通重试信号。

为什么 try-with-resources 仍可能出现结构违规？

如果 scope 在嵌套 scope 尚未关闭时被外层线程强行关闭，或 scope owner 与调用线程不一致，仍可能触发结构约束。保持创建、join、close 在同一结构化调用链内。