通过增量式集成 Rust 来加速性能

Lily Mara 解释了如何通过增量式 FFI 重构避免高风险的软件重写。她分享了工程团队如何借助 PyO3 用 Rust 替换 Python 瓶颈，并演示如何在不引入微服务开销的情况下实现显著的函数级加速、无缝集成测试以及可观的基础设施成本节约。

[LOADING...]

开发领域全部内容关注主题

架构与设计

架构与设计领域精选

从微服务到智能体：分布式系统的下一次演进

本文探讨分布式系统中从微服务向智能体 AI 架构的转变。微服务支持功能分解，而智能体系统侧重于决策分解。这一转变在可观测性、可靠性和系统设计方面引入了新的复杂性，凸显出更新架构模式与实践的必要性。

[LOADING...]

架构与设计领域全部内容关注主题

AI 基础设施

AI、机器学习与数据工程领域精选

Web 应用的未来：AI 智能体会即时生成 UI 吗？

前 React 核心团队成员 Rachel Lee Nabors 深入探讨本地优先应用背后的架构与理念，探索直接在设备上运行的小语言模型（SLM）如何提供注重隐私、低延迟且成本高效的方案，作为云端托管 LLM 包装器的替代选择。

[LOADING...]

AI、机器学习与数据工程领域全部内容关注主题

文化与方法论

文化与方法论领域精选

最小可行管理者：建立信任、反馈与对齐

在本期播客中，文化与方法论栏目主编 Shane Hastie 与 Built 创始人、《最小可行管理者》作者 Matt Gjertsen 对话，讨论每位首次担任管理者的人都需要的三项基础技能、如何建立信任并给出有效反馈，以及在 AI 时代为何人类领导力技能更加重要。

[LOADING...]

文化与方法论领域全部内容关注主题

DevOps

DevOps 领域精选

GPU 爆炸式增长与 AI 基础设施挑战

Andrew Martin 讨论了为什么 AI 安全从根本上与 Kubernetes 安全紧密相关。他分享了对不断演变的 AI 威胁态势的见解，涵盖非确定性智能体行为、GPU 供应链漏洞、共享计算风险，以及从提示词防火墙到智能体身份等实用防御策略，帮助在生产环境中保护云原生 AI 工作负载。

[LOADING...]

DevOps 领域全部内容关注主题

活动

实用链接

选择语言

2026年11月17日高绩效团队认证与经验丰富的实践者比较团队设计、交付流程、AI 角色和指标。线上。立即注册。

2027年1月22日架构师认证分布式系统、去中心化决策、平台工程和 AI 架构。线上。立即注册。

2026年12月15-16日 QCon AI 纽约来自构建生产级 AI 的资深工程师，涵盖智能体、上下文、评估、安全和基础设施。注册。早鸟票 11 月 10 日截止。

2027年4月13-16日 QCon 伦敦早期采用团队已在生产环境中验证的内容，涵盖 15 个工程专题。注册。早鸟票 11 月 10 日截止。

InfoQ 首页新闻JEP 543 在 JDK 28 中最终确定结构化并发，结束七轮预览 Java 线上 InfoQ AI 安全与隐私工程认证（10 月 26 日）：在受监管环境中交付 AI？

JEP 543 在 JDK 28 中最终确定结构化并发，结束七轮预览

2026年10月19日 4 分钟阅读作者

[LOADING...]A N M Bazlur Rahman

关注 Java Champion 兼软件工程师

关注我们

Youtube 23.2 万关注者 Linkedin 2.6 万关注者 Instagram 新 RSS 1.9 万读者 X 5.71 万关注者 Facebook 2.1 万点赞 Bluesky 新

登录以收听本文

正在加载音频

音频 2

0:00 0:00

正常 1.25x 1.5x

阅读列表

JEP 543，结构化并发，已集成到 JDK 28，使 java.util.concurrent 中的 StructuredTaskScope API 达到最终状态，且与 JDK 27 的第七轮预览相比没有 API 变更。对于已经使用 JDK 27 的代码库，迁移只需在不带 --enable-preview 的情况下重新编译。最终确定结束了 Project Loom 所有特性中最长的预览周期。结构化并发最初作为孵化器 API 在 JEP 428（JDK 19）和 JEP 437（JDK 20）中亮相，随后经历了七轮预览：JEP 453（JDK 21）、JEP 462（JDK 22）、JEP 480（JDK 23）、JEP 499（JDK 24）、JEP 505（JDK 25）、JEP 525（JDK 26）和 JEP 533（JDK 27）。在每一次迭代中，核心目标都是将运行在不同线程中的一组相关子任务视为单一工作单元，确保某个子任务失败时取消其他子任务，并且父作用域在所有子线程终止之前不能退出。传统的 ExecutorService 和 Future 流水线不强制这些边界：父方法可以在子任务仍在后台运行时返回，而子任务失败只有在调用方最终调用 Future.get() 时才会暴露。

该 API 以 StructuredTaskScope 为核心，这是一个密封接口，通过静态工厂方法而非公共构造器打开。无参 open() 工厂返回的作用域，其 join() 方法会等待所有子任务成功，在首个失败时取消其余任务，并抛出 ExecutionException：

$ java

Response handle() throws ExecutionException, InterruptedException {
    try (var scope = StructuredTaskScope.open()) {
        Subtask user = scope.fork(() -> findUser());
        Subtask order = scope.fork(() -> fetchOrder());

        scope.join(); // throws ExecutionException if either subtask fails

        return new Response(user.get(), order.get());
    }
}

默认情况下，每次 fork() 调用都会启动一个虚拟线程；join() 是所有者线程等待结果的唯一位置；而 try-with-resources 块末尾的 close() 会取消任何未完成的子任务，并等待这些线程终止。完成策略通过 Joiner 接口定义：Joiner.awaitAllSuccessfulOrThrow() 对应上面的默认策略；对于同构子任务，Joiner.allSuccessfulOrThrow() 直接从 join() 返回一个 List；Joiner.anySuccessfulOrThrow() 返回第一个成功结果并取消其余任务；Joiner.allUntil(Predicate) 在谓词匹配后取消作用域。

最终确定的 API 保留了 JDK 27 中确立的精确形态。JEP 533 引入了第三个类型参数 R_X，使 join() 声明其 Joiner 可以抛出的特定异常类型，而不是抛出预览版专用的 FailedException。在内置的抛异常 Joiner 下，join() 抛出 ExecutionException，这与 Future.get() 长期使用的包装异常相同。从 JDK 26 迁移过来的团队需要做更多修改。他们会看到 FailedException 被 ExecutionException 取代，并且自定义 Joiner 签名中新增了 R_X。此外，StructuredTaskScope.TimeoutException 已被移除，改为通过 CancelledByTimeoutException 原因报告超时；Joiner.awaitAll() 不再可用；onTimeout() 回调已被抽象的 timeout() 方法取代。

自定义策略正是第三个类型参数发挥作用之处。例如，一个等待副本读取达到 quorum 的 Joiner 可以抛出自己的受检异常：

$ java

class QuorumJoiner implements Joiner<Object, QuorumException> {
    private final int quorum;
    private final Queue<Object> results = new ConcurrentLinkedQueue<>();

    QuorumJoiner(int quorum) {
        this.quorum = quorum;
    }

    @Override
    public boolean onComplete(Subtask<? extends Object> subtask) {
        if (subtask.state() == Subtask.State.SUCCESS) {
            results.add(subtask.get());
        }
        return results.size() >= quorum; // true cancels the remaining reads
    }

    @Override
    public List<Object> result() throws QuorumException {
        if (results.size() < quorum) {
            throw new QuorumException(results.size(), quorum);
        }
        return List.copyOf(results).subList(0, quorum);
    }

    @Override
    public List<Object> timeout() throws QuorumException {
        throw new QuorumException(results.size(), quorum, new CancelledByTimeoutException());
    }
}

try (var scope = StructuredTaskScope.open(new QuorumJoiner<>(2))) {
    replicas.forEach(r -> scope.fork(() -> r.read(key)));
    List<Object> values = scope.join(); // throws QuorumException
}

由于该 Joiner 将应用定义的受检异常 QuorumException 声明为其 R_X，join() 会直接抛出它，而不是将其包装在 ExecutionException 中。timeout() 遵循 JDK 27 的约定，抛出同一异常并附带 CancelledByTimeoutException 原因。

超时和配置语义也保持不变。向 open() 传入一个 UnaryOperator，可配置用于可观测性的作用域名称、自定义 ThreadFactory，或在 join() 之前或期间到期时取消该作用域的截止时间：

$ java

try (var scope = StructuredTaskScope.open(
        cf -> cf.withTimeout(Duration.ofSeconds(2)).withName("profile-page"))) {
    Subtask user = scope.fork(() -> findUser());
    Subtask order = scope.fork(() -> fetchOrder());

    scope.join();

    return new Response(user.get(), order.get());
} catch (ExecutionException e) {
    return switch (e.getCause()) {
        case CancelledByTimeoutException _ -> handleTimeout();
        case IOException ioe -> handleIo(ioe);
        default -> throw e;
    };
}

该 API 对结构同样要求严格。只有打开作用域的线程才能调用 fork() 和 join()，结果只能在 join() 返回后通过 Subtask.get() 读取；而结构性误用，例如不按顺序关闭作用域，会通过 StructureViolationException 快速失败，而不是泄漏线程。对于上下文传播和调试，子任务会继承 ScopedValue 绑定（JEP 506），并在 JSON 线程转储中出现在其父任务之下。有一个细节被有意保持开放：如果多个子任务同时失败，API 并未说明 join() 会报告哪一个失败。Viktor Klang 在代码审查期间提出了这个问题，而该 JEP 在 Oracle 的负责人 Alan Bateman 修改了 Javadoc 的措辞，仅承诺异常来自某个失败的子任务。对于使用 JDK 27 的团队而言，迁移到最终 API 是构建层面的变更，而非代码变更。最终定稿提交仅移除预览注解，不更改任何方法签名，因此团队可以从 javac、测试运行器和启动脚本中移除 --enable-preview，然后在包含该变更的 JDK 28 早期访问构建上重新编译。JDK 28 计划于 2027 年 3 月正式发布。更大的转变在于库和框架的维护者，他们现在可以基于结构化并发进行构建，而无需强迫用户使用预览标志。velo/structured-concurrency 项目已将 JEP 543 API 向后移植到 JDK 25，并提供了在升级后迁移到 JDK 类的迁移方案。

关于作者

[LOADING...]

A N M Bazlur Rahman

A N M Bazlur Rahman 是一位 Java Champion，也是 Hammerspace 的资深主任软件工程师，专注于 Java 及现代 Java 相关技术。除了日常工程工作之外，Bazlur 还以导师、作者、演讲者和开源贡献者的身份深度参与全球 Java 社区。他创立并目前主持孟加拉国 Java 用户组（JUGBD），自 2013 年以来一直组织聚会和会议以推广 Java 知识。Bazlur 还是 InfoQ 的特约编辑和 Foojay.io 的编辑，这两个平台是全球 Java 专业人士最受尊敬的平台之一。他撰写了多本关于 Java 编程的孟加拉语书籍，包括畅销书《Java Programming》，这些书帮助成千上万的开发者用母语学习这门语言。他的最新英文著作《Modern Concurrency in Java》（O'Reilly Media）探讨了 Java 不断演进的并发模型，包括虚拟线程和结构化并发。

显示更多显示更少