红帽高级总监谈 OpenJDK 的未来：Java 的未来从未如此光明

随着 Java 11 的发布，Java 最终完成了到 OpenJDK 一等项目的过渡。使用专有 OracleJDK 二进制文件的日子已经结束了。对 Java 开放性和免费的关注自然而然将 Oracle 以外的公司的贡献带入到了聚光灯下。最近，InfoQ 采访了 Red Hat 中间件产品管理高级总监 Rich Sharples，讨论了 OpenJDK 和 Red Hat 的参与情况。

InfoQ：在很早之前，Red Hat 就一直是 OpenJDK 的贡献者。你能谈谈你和这个项目之间的历史渊源吗？

Rich Sharples：Red Hat 于 2007 年 11 月 5 日宣布与 Sun Microsystems 达成广泛的贡献者协议。这项协议包括了 Red Hat 工程师参与 Sun 领导的所有开源项目。同时，Red Hat 签署了 Sun 的 OpenJDK Community TCK 许可协议，成为第一家签署该协议的主要软件供应商。Red Hat 还与 Sun 分享开发人员的贡献，共同创建 OpenJDK 社区以及促进创新。Red Hat 是继 Oracle 之后 OpenJDK 的最大贡献者之一。

Red Hat 通过上述举措深度参与 Java 生态系统，这在 Red Hat 收购 JBoss 之后的时期起到了非常重要的作用。2009 年，Sun 被 Oracle 收购，Sun 和 Red Hat 之间已经建立起来的关系在 Oracle 眼皮底下继续发展。

自 2007 年加入 OpenJDK 项目以来，Red Hat 持续为上游 OpenJDK 社区做出贡献，并将 OpenJDK 打包进了 Red Hat Enterprise Linux 中。Red Hat 曾在 2013 年领导 OpenJDK 6 的开发（支持到 2016 年），并在 2015 年接管了 OpenJDK 7 的管理权。Andrew Haley 在 Red Hat 开发者博客的这篇文章中详细介绍了我们接管的工作。

和 OpenJDK 7 一样，OpenJDK 6 被打包进了 Red Hat Enterprise Linux 5、6 和 7 当中。Red Hat Enterprise Linux 6 和 7 还支持 OpenJDK 8。Red Hat Enterprise Linux 7.6 支持 OpenJDK 11。除了为一系列 Red Hat Enterprise Linux 版本提供支持外，我们还一直为 OpenJDK 发行版提供全生命周期支持。

最近，OpenJDK 7 的生命周期被延长至 2020 年 6 月，OpenJDK 8 被延长至 2023 年 6 月，旨在为用户提供足够的时间将工作负载迁移到 OpenJDK 11。

除了为 Red Hat Enterprise Linux 上的 OpenJDK 提供发行和生命周期支持外，Red Hat 的开源 Java 中间件产品也支持 Red Hat Enterprise Linux 的 OpenJDK，让户能够从单个供应商获得从操作系统到应用程序服务的完整技术栈支持。其他的 Red Hat 产品也运行在 OpenJDK 上。我们是一个为全球依赖开源软件运行应用程序工作负载的客户提供支持的领先厂商。

InfoQ：我们来谈谈目前的状况。目前看来，Red Hat 有多少工程师正在参与 OpenJDK 的工作（全职和兼职）？主要参与哪些方面的工作？

Sharples：出于政策方面的考虑，我们不方便公开 Red Hat 在特定项目上的投入情况。

Red Hat Java 平台团队首席工程师 Andrew Haley 多年来一直是 OpenJDK 管理委员会的成员，同时也是 AArch64 移植项目的负责人。此外，Andrew 还是 JDK 7 项目的负责人，并打算在 Oracle 支持周期结束后申请负责 OpenJDK 8 和 11 的开发。

InfoQ：在具体技术方面，你认为 Red Hat 在哪些领域做出了最大的贡献？哪些技术组件可以体现 Red Hat 的强大领导力？

Sharples：Red Hat 领导了 64 位 ARMv8 的移植，即 OpenJDK 的 AArch64 项目，并将它并入上游的 OpenJDK 项目中。目前，我们正在与 OpenJDK 社区合作开发一个新的超低停顿时间的垃圾回收器，名字叫作 Shenandoah，它处于 OpenJDK 主线之外——但在 Red Hat Enterprise Linux 7 中得到完整的支持。这项工作计划在 OpenJDK 12 中并入主线。

InfoQ：目前，OpenJDK 垃圾回收方面的情况非常有意思。例如，截止 JDK 11，G1 最终成为一个成熟的垃圾回收器。Red Hat 有 Shenandoah，而 Oracle 一直在开发 ZGC。你能评论一下 Red Hat 在 GC 方面的参与情况吗，特别是关于 G1？你如何对比 Shenandoah 和 ZGC？你能否估计一下 Red Hat 认为 Shenandoah 会在什么时候成为一个生产就绪的垃圾回收器？

Sharples：目前，我们主要参与的仍然是 Shenandoah GC。此外，在 Hotspot 的 GC 接口开发方面（尽管对用户不可见）也进行了非常重要的协作，Red Hat 正积极参与其中。

过去，GC 代码与 Hotspot 代码交杂在一起，但现在每个 GC 的代码都很好地分离出来了。Shenandoah 与 G1 共享了一些代码，所以需要做一些改进和 bug 修复。值得注意的是，G1 采用了最初出现在 Shenandoah 中的一些特性，例如多线程 Full GC，以及最近的空闲未提交堆（heap uncommit on idle）。

ZGC 和 Shenandoah 的目标非常相似（减少收集大堆的停顿时间），但它们遵循的是非常不同的实现策略——Shenandoah 使用 Brooks Pointers，而 ZGC 使用彩色指针和多内存映射。

ZGC 在吞吐量和停顿时间方面做得更好，而 Shenandoah 具有更好的人体工程学，这意味着它在一些恶劣的情况下（例如满堆或堆分配激增）会运行得更好。ZGC 不能（按照设计）使用压缩的 oops，这意味着它在中型（<32GB）的堆上有一定的弱势。此外，Shenandoah 在小堆上运行良好，这让它有可能会成为增长型应用程序的理想 GC，但并不保证会这样。

据我们所知，Shenandoah 已经是 JDK-8u 发行版（Red Hat Enterprise Linux >= 7.5）的一部分。我们目前正在努力让 Shenandoah 进入上游（JDK 12）。如果我们做到了，它将成为一个实验性特性。我们现在还不敢说这个实验性标志什么时候将从上游 OpenJDK 发行版中移除。

InfoQ：显然，最近的一个重大新闻是 Red Hat 被 IBM 收购。这将给 Red Hat 与 OpenJDK 之间的关系带来什么样的影响？

Sharples：关于与收购有关的内容请参阅我们发布的新闻和 Jim Whitehurst 的博文。

InfoQ：你认为 OpenJDK（以及 Java/JVM 生态系统）最激动人心的部分是什么？你认为哪些技术是我们的读者在未来 12 到 18 个月内最应该关注的？

Sharples：Java 必须超越当前的位置，也就是作为大规模关键业务应用程序的可扩展语言运行时，并与更轻量、更灵活的语言和运行时展开竞争——特别是在内存占用和延迟非常敏感的云原生环境中。

Java 社区继续在 JVM 层面进行创新。除此之外，Graal 和 Substrate VM 已经认识到，在容器和 DevOps 环境中，JVM 的平均运行寿命要短得多。单体应用程序一次在 JVM 上可以运行数月，而持续交付环境中的容器化微服务可能一次只运行数天或数小时，而在无服务器环境中，它们可能只运行几秒（甚至几毫秒）。

值得注意的是，不仅仅是 JVM 令人感到兴奋，更广泛的 Java 生态系统也正极力追赶。除了优化 JVM 本身以及不断引入像 Thorntail 这样的新的轻量级和灵活的运行时之外，Eclipse MicroProfile 及其规范也有助于将开发传统单体应用程序的 Java EE 开发人员带入轻量级微服务领域。

Red Hat，以及 Fabic8 Maven Plugin 和 Spring Cloud Kubernetes 等工具，一直在引领 Kubernetes、Istio 和 OpenShift 原生 Java 应用程序的开发。这极大简化了微服务架构，而在几年前，它们需要很多单独管理的独立基础设施服务。整个 Java 生态系统在持续快速地向前发展。

我们也在考虑针对专门工作负载（如 AI 和机器学习）的芯片架构（如 ARM 和 GPU）和云架构的新元素，如边缘设备、网关、移动设备和可穿戴设备。

InfoQ：还有其他想对我们读者说的吗？

Sharples：人们对 Java 兴趣程度从未如此强烈，Java 的未来也从未如此光明。

查看英文原文：

https://www.infoq.com/news/2018/11/red-hat-openjdk-gc-Nov18