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

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

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

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

自2007年加入OpenJDK项目以来，RedHat持续为上游OpenJDK社区做出贡献，并将OpenJDK打包进了RedHatEnterpriseLinux中。RedHat曾在2013年领导OpenJDK6的开发(支持到2016年)，并在2015年接管了OpenJDK7的管理权。AndrewHaley在RedHat开发者博客的这篇文章中详细介绍了我们接管的工作。

和OpenJDK7一样，OpenJDK6被打包进了RedHatEnterpriseLinux5、6和7当中。RedHatEnterpriseLinux6和7还支持OpenJDK8。RedHatEnterpriseLinux7.6支持OpenJDK11。除了为一系列RedHatEnterpriseLinux版本提供支持外，我们还一直为OpenJDK发行版提供全生命周期支持。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

达内Java免费训练营课程专门为初学者答疑解惑，帮你了解Java的前世今生，看准Java的未来发展形势，并且找到0基础学Java最有效的学习路径，让你通过学Java实现自己升职加薪的梦想。

课程内容都有一线的技术专家亲自授课讲解，能给你带来不一样的启发、收获。

英文原文：https；//#/news/2018/11/red-hat-openjdk-gc-Nov18

*版权声明：转载文章和图片均来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。