JEP 453,结构化并发(预览)已经从 JDK 21 的 Targeted 状态变更为 Integrated 状态。这个最初的预览特性来源于一个孵化 API,它根据前两轮的孵化纳入了一些改进,这两轮孵化分别是 JDK 19 交付的JEP 428,结构化并发(孵化)和 JDK 20 交付的JEP 437,结构化并发(第二轮孵化)。在当前提案中,唯一的显著变化是StructuredTaskScope::fork(...)方法返回一个[Subtask],而不是Future。这是一个预览特性。
JDK 21 中的结构化并发致力于引入结构化并发的 API 来简化并发编程。这种方法将在不同线程中运行的相关任务组视为一个工作单元,从而简化了错误处理和取消,提高了可靠性,并增强了可观测性。我们看一个样例:
这段代码创建了一个新的StructuredTaskScope,并使用它来创建了两个分支子任务,其中一个执行findUser()
,另一个执行fetchOrder()
。当这两个子任务均完成时,它会使用这两个子任务的结果创建一个新的Response
。
结构化并发是一个预览 API,默认是禁用的。要使用StructuredTaskScope
API,开发人员必须启用预览 API 来编译该代码,如下面的命令所示:
运行该程序也需要相同的标记:
但是,我们可以使用源码启动器(source code launcher)来直接运行它。在这种情况下,命令行如下所示:
使用jshell方案也是可以的,不过依然需要启用预览特性:
在实践中,使用StructuredTaskScope
时,大多数情况下都不会直接使用StructuredTaskScope
类,而是使用两个子类中的某一个,这两个子类均实现了关闭策略。这两个子类,即ShutdownOnFailure
和ShutdownOnSuccess
,分别支持在第一个子任务失败或成功时关闭作用域的模式。
结构化并发将在不同线程中运行的相关任务视为一个工作单元。这种方式简化了错误处理和取消,提高了可靠性,并增强了可观测性。开发者Ron Pressler是甲骨文公司技术员工的咨询成员,并且是 OpenJDK 的Loom项目的技术负责人,Alan Bateman是甲骨文公司 Java 平台组的工程师,他们意图消除与并发编程相关的常见风险,如线程泄露和取消延迟,并增强并发代码的可观测性。
这个新特性的目的并不是要取代java.util.concurrent包中的任何并发结构,如ExecutorService和Future。它的目的也不是为 Java 平台定义明确的结构化并发 API,或在线程间共享数据流的方法。
当前的并发编程模型,如ExecutorService
API,由于其不受限制的并发模式,引入了复杂性和风险。这些模型不会强制要求或跟踪任务和子任务之间的关系,使得并发任务的管理和可观测性很具挑战性。
结构化并发提出,任务结构应该反映代码结构。在单线程代码中,执行过程总是会强制保证任务和子任务的层次结构,每个子任务相对于其他子任务的生命周期是由代码的语法块结构来管理的。
新的StructuredTaskScope
为ExecutorService
提供了一个更简单、更安全地替代方案。这个 API 封装了一组应该一起完成的相关任务,任何子任务的失败都会导致其余子任务的取消。
有关这些变更的更多细节,包括代码示例和对该功能背后动机的全面讨论,请参阅OpenJDK的网站。
这个新的 API 是使并发编程更容易、更可靠和更具可观测性的重要一步。预计它对构建可维护的、可靠的和可观测的服务器应用尤为有利。对深入了解结构化并发感兴趣,或愿意学习其相关背景的开发人员可以收听InfoQ Podcast、Ron Pressler 的YouTube课程和Inside Java的文章。
原文链接:
Structured Concurrency in JDK 21: A Leap Forward in Concurrent Programming
相关阅读:
Java 近期新闻:JDK 21 进入 Rampdown 阶段、JEP 404、JDK 22 专家组、Jakarta EE 11 升级
评论 2 条评论