长期以来，并发编程一直是 Java 开发中的一个薄弱环节。虽然传统的并发工具在一定程度上满足了需求，但它们允许使用缺乏约束的编程模式，导致子任务可能比父任务存在更久、线程资源泄漏，以及取消机制难以有效实施。

ExecutorService

结构化并发的引入改变了这一局面。它将多个运行在不同线程中的相关任务视为一个统一的工作单元进行管理，从而显著简化了错误处理和任务取消的过程，同时增强了程序的可靠性与可观测性。

Future

非结构化并发带来的挑战

在传统模式中，常见的情形是：一个线程创建执行器，另一个线程提交任务，而实际执行任务的线程则与前两者无直接关联。例如，在某个线程提交工作后，完全由另一个不相关的线程来等待结果——只要持有相应的 Future 引用，任何代码都可以连接并获取结果，甚至跨线程进行操作。

ExecutorService

这种松散的组织方式引发了一系列问题：

• 当父任务未能正确终止其派生的子任务时，容易造成线程泄漏；
• 由于缺乏统一协调机制，无法高效地通知多个子任务进行取消，导致取消延迟；
• 任务与其子任务之间的层级关系在运行时未被明确记录，使得监控和追踪变得困难，影响系统的可观测性。

以下是一个典型的非结构化并发示例：

// 非结构化：任务关系隐式且脆弱
ExecutorService executor = Executors.newCachedThreadPool();
Future<User> userFuture = executor.submit(() -> fetchUser(id));
Future<Orders> ordersFuture = executor.submit(() -> fetchOrders(id));
// 如果 fetchUser 失败会发生什么？
// 谁负责关闭执行器？
// 忘记清理是否会导致线程泄漏？
    

Future

StructuredTaskScope：结构化并发的核心

Java 中结构化并发的关键组件是位于 java.util.concurrent 包下的 StructuredTaskScope 类。该类使开发者能够以协作方式统一管理一组并发子任务。通过它，可以在独立线程中“分叉”各个子任务，随后以统一的方式“汇合”，确保所有子任务完成之后主任务才继续执行。

java.util.concurrent

StructuredTaskScope

使用该 API 的典型流程包括以下几个步骤：

1. 利用 try-with-resources 语句创建一个 StructuredTaskScope 实例；
2. 将每个子任务定义为 Supplier 或可调用形式；
3. 通过 fork() 方法在独立线程中启动各子任务；
4. 调用 join() 进行汇合，等待所有任务结束；
5. 处理最终结果或异常情况。

StructuredTaskScope

Callable

下面是一个获取天气信息的实际应用示例：

WeatherReport getWeatherReport(String location)
throws ExecutionException, InterruptedException {
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
Supplier<Temperature> temperature =
scope.fork(() -> getTemperature(location));
Supplier<Humidity> humidity =
scope.fork(() -> getHumidity(location));
Supplier<WindSpeed> windSpeed =
scope.fork(() -> getWindSpeed(location));
scope.join()           // 等待所有子任务完成
.throwIfFailed(); // 若任一失败，则抛出异常
// 所有任务成功，整合结果
return new WeatherReport(
location,
temperature.get(),
humidity.get(),
windSpeed.get()
);
}
}

其中，try-with-resources 结构至关重要——它保证作用域在退出时被正确关闭，自动取消仍在运行的子任务，防止资源泄漏。

利用关闭策略实现短路控制

短路机制允许主任务在某些条件达成后立即中断那些不再需要的子任务，从而提升响应速度和资源利用率。结构化并发提供了两种内置的关闭策略来应对常见场景。

ShutdownOnFailure：全成功模式
当业务逻辑要求所有子任务都必须成功完成时，可使用 StructuredTaskScope.ShutdownOnFailure。一旦某个子任务失败，其余仍在运行的任务将被立即取消。

ShutdownOnFailure

示例代码如下：

Response handleRequest(String userId) throws Exception {
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
Subtask<User> user = scope.fork(() -> fetchUser(userId));
Subtask<Profile> profile = scope.fork(() -> fetchProfile(userId));
scope.join().throwIfFailed();
// 只有全部成功才继续
return new Response(user.get(), profile.get());
}

class AllSuccessesScope<T> extends StructuredTaskScope<T> {
    private final List<T> results =
        Collections.synchronizedList(new ArrayList<>());

    @Override
    protected void handleComplete(Subtask<? extends T> subtask) {
        if (subtask.state() == Subtask.State.SUCCESS) {
            results.add(subtask.get());
        }
    }

    public List<T> getResults() {
        return List.copyOf(results);
    }
}

// 使用示例
List<Data> collectAll() throws InterruptedException {
    try (var scope = new AllSuccessesScope<Data>()) {
        for (String source : dataSources) {
            scope.fork(() -> fetchData(source));
        }
        scope.join();
        return scope.getResults();
    }
}
StructuredTaskScope

在实际应用中，大多数情况下不会直接使用 StructuredTaskScope 基类，而是选择其两个内置子类之一来实现特定的关闭策略，或通过继承创建自定义策略。上述 AllSuccessesScope 示例展示了一种收集所有成功结果并自动忽略失败任务的实现方式。

String fetchFromMultipleSources(String key) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
        scope.fork(() -> fetchFromPrimaryDB(key));
        scope.fork(() -> fetchFromCache(key));
        scope.fork(() -> fetchFromBackup(key));
        scope.join();
        // 立即返回首个成功响应的结果
        return scope.result();
    }
}

该模式适用于对延迟敏感的场景，例如从多个数据源竞速获取数据。一旦任意子任务成功完成，作用域便会立即取消其余仍在运行的任务，从而避免资源浪费，提升响应速度。

Subtask<Settings> settings = scope.fork(() -> fetchSettings(userId));
scope.join().throwIfFailed();
// 若有任一任务失败，则不会执行到此处
return new Response(user.get(), profile.get(), settings.get());

fetchUser()

当某个任务抛出异常时，整个作用域会立即触发取消机制，中断仍在执行的 profile 和 settings 获取操作。这种方式确保了无多余工作被执行，也不会出现线程泄漏问题。

虚拟线程：结构化并发的理想配合

虚拟线程极大降低了创建高并发任务的成本，使得同时启动数万个任务成为可行方案。结合结构化并发模型，不仅能够安全协调这些轻量级线程，还能让监控和诊断工具以开发者易于理解的方式呈现调用关系。

// 启动 10,000 个并发任务现在是安全且高效的
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    for (int i = 0; i < 10_000; i++) {
        final int taskId = i;
        scope.fork(() -> processTask(taskId));
    }
    scope.join().throwIfFailed();
}

若使用传统平台线程实现类似逻辑，系统将面临严重的资源耗尽风险。而借助虚拟线程与结构化作用域的协同机制，此类高并发操作变得简洁、可控且具备良好的错误处理能力。

模块化环境下的注意事项

在基于模块化架构的应用中，Java 模块系统对反射访问施加了严格限制。默认情况下，只有在 module-info.java 中明确导出的包才能被外部访问，且反射仅能触及公共类中的公共成员，不再具备“突破封装”的能力。

module com.example.app {
    // 编译期可访问的标准导出

module-info.java

对于依赖反射机制的框架（如 Spring 或 Hibernate），必须显式声明对相关包的开放（opens）或导出（exports），否则运行时可能出现访问失败或初始化异常。因此，在采用结构化并发构建模块化服务时，合理配置模块描述符至关重要。

open module com.example.app {
    exports com.example.api;
    requires java.base;
}

在编译阶段，开放的模块包会被完全封装，如同相关指令并不存在；但在运行时，这些包中的类型可通过反射访问，能够自由地与所有成员（无论是否声明为公开）进行交互。若希望模块中所有包都具备完整的反射访问能力，可定义为开放模块：

opens

这种写法相当于将模块内的每一个包都显式使用 opens 指令导出给反射使用，虽然使用便捷，但会削弱模块的封装性。

可观测性与调试支持增强

结构化并发显著提升了程序的可观测性。在线程转储信息中，现在可以清晰展示任务之间的父子层级关系：

jcmd <pid> Thread.dump_to_file -format=json output.json

此外，生成的 JSON 格式输出能明确揭示

StructuredTaskScope

以及其在数组结构中分叉出的子任务，使得开发者更容易理解当前执行的任务流及其触发原因。相比传统扁平化、缺乏关联性的线程转储，这是一种根本性的改进。

发展历程与当前状态

结构化并发最初由 JEP 428 提出，并作为孵化 API 首次出现在 JDK 19 中，在 JDK 20 中继续孵化。随后通过 JEP 453 在 JDK 21 中进入预览阶段，并在 JDK 22 和 JDK 23 中重复预览。到 JDK 25 时，该 API 已进一步演进，采用静态工厂方法替代原有的公共构造函数设计，提升了封装性和使用安全性。

要在当前 JDK 版本中启用结构化并发功能，需开启预览特性：

# 编译
javac --release 21 --enable-preview MyApp.java
# 运行
java --enable-preview MyApp

基于大量实际应用反馈，这一 API 正逐步趋于稳定。实践证明，结构化并发是一种安全、表达力强且易于掌握的并发编程方式。此类模式最早由 Python 相关库提出，之后被 Kotlin 等语言采纳并推广。

使用建议与最佳实践

• 始终使用 Try-With-Resources：必须确保作用域被正确关闭，以避免线程资源泄漏。切勿手动管理

StructuredTaskScope

• 选择合适的执行策略：当需要等待所有结果完成时，使用

ShutdownOnFailure

• 在竞速场景下优先返回最快结果，则选用

ShutdownOnSuccess

• 也可根据具体需求实现自定义策略。
• 结合虚拟线程使用：结构化并发与虚拟线程搭配效果最佳，可在保持代码简洁的同时实现极高并发度。
• 避免共享可变状态：尽管结构化并发简化了任务协调，但对共享数据的线程安全责任仍需开发者自行保障。
• 考虑使用作用域值传递上下文：为了在任务树中高效传递上下文信息，推荐使用作用域值（由 JEP 481 引入），它相比

ThreadLocal

• 提供了更安全、更清晰的解决方案。

实战示例：用户数据聚合服务

以下是一个从多个服务源并行获取并整合用户信息的完整示例：

public class UserAggregator {
    record UserData(User user, List<Order> orders,
                    Stats stats, Recommendations recs) {}

    public UserData aggregate(String userId)
            throws ExecutionException, InterruptedException {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            Supplier<User> user =
                scope.fork(() -> userService.fetch(userId));
            Supplier<List<Order>> orders =
                scope.fork(() -> orderService.fetch(userId));
            Supplier<Stats> stats =
                scope.fork(() -> statsService.compute(userId));
            Supplier<Recommendations> recs =
                scope.fork(() -> mlService.recommend(userId));

            scope.join().throwIfFailed();

            return new UserData(
                user.get(),
                orders.get(),
                stats.get(),
                recs.get()
            );
        }
    }
}

该实现方式简洁、安全且高效。一旦任一子任务失败，其余任务将被立即取消；同时，try-with-resources 机制确保了资源的自动清理。配合虚拟线程，此模式可轻松支撑数千个并发请求的处理。

架构设计视角

Java 架构团队在设计时决定不从

fork

方法直接返回

Future

而是通过更可控的方式暴露结果，从而提升 API 的健壮性与使用安全性。

结构化并发标志着我们在编写并发程序时思维方式的根本性变革。与其像过去那样单独管理线程或 Future 对象，不如将并发任务以层次化的方式组织起来——这种组织方式类似于我们使用方法调用和循环来构建顺序执行的代码。

这种设计选择突出了结构化并发并非对传统模型的简单优化，而是一种全新的编程范式，旨在与旧有的并发机制明确区分开来，避免与非结构化的计算逻辑产生混淆。

根据 Rock the JVM 教程的观点，结构化并发为 Java 平台正式引入了长期以来其他 JVM 语言早已通过 Kotlin 协程、Scala Cats Effects Fibers 等库实现的能力，并且现在获得了官方平台级的支持，不再依赖第三方库。

其优势十分显著：彻底杜绝线程泄漏问题，实现准确的异常传递，支持统一的取消机制，并大幅提升系统的可观测性。当与虚拟线程结合使用时，Java 如今拥有了一个既高效又易于掌握的并发处理模型。

随着该 API 逐步趋于稳定并走向最终形态，预计将在各类框架和库中被广泛采纳。包括 Spring、Hibernate 在内的多个主流生态系统项目，目前已经在探索如何利用结构化并发来构建更加清晰、稳健的并发逻辑。