Oracle 提议将 G1 作为 Java 9 的默认垃圾收集器

  • Abraham Marín Pérez
  • 谢丽

2015 年 6 月 16 日

话题:JavaOracleJVMDevOps语言 & 开发架构

Oracle 正在考虑将JEP 248包含到Java 9 的 JEP 列表中,即在服务器配置中将 G1 作为默认垃圾收集器。该决定在 Java 社区引发了一些争论,许多人都认为并发标记和扫描(CMS)收集器可能更合适。

如果该决定付诸实施,那么 G1 将取代并行垃圾收集器成为服务器配置的默认选项。正如 Oracle 在内存管理白皮书中描述的那样,并行垃圾收集器的设计初衷是,通过不常发生(但可能时间比较长)的 Stop-The-World(STW)中断最大化应用程序吞吐量。并行垃圾收集器将消耗的总计算时间最小化,长远来看,其破坏性更小,因此可以提供更好的整体性能。该收集器非常适合对响应时间要求不高的应用程序,比如,批处理。

另一方面,正如前 G1 性能负责人 Monica Beckwith先前在 InfoQ 上阐述的那样,Garbage First(G1)的设计初衷是,以更高的计算成本为代价最小化 STW 中断时间。G1 更适合于低延迟应用程序,如 Web 服务器,这也体现了 Stefan Johansson 在 JEP 中所描述的动机:

通常来说,限制 GC 中断时间比最大化吞吐量更重要。对大部分用户而言,与面向吞吐量的收集器相比(如并行垃圾收集器),切换到中断时间短的垃圾收集器(如 G1),可以获得更好的整体体验。

这里出现了争议。HotSpot 因为同样的目的引入了 CMS,而实际上,按照Oracle 的描述,CMS“设计用于更希望缩短垃圾收集中断时间的应用程序,以及在运行时可以与垃圾收集器共享处理器资源的应用程序”。许多公开的基准测试都表明,在内存占用相对较小的应用程序中,CMS 的性能往往要胜过 G1,这与Oracle 对 G1 的描述一致,即 G1 适用于堆大小为 6GB 及以上的服务器应用程序。

在最近的一次交流中,性能专家 Kirk Pepperdine 特别指出,谷歌已经向 CMS 贡献了若干改进,但它们从没有出现在 HotSpot 中。他还补充说,虽然长远看 G1 可能是更好的选择,但 Oracle 的设计方案已经剥夺了社区从 CMS 获得更好体验的权力。

查看英文原文:Oracle Proposes G1 as the Default Garbage Collector for Java 9

JavaOracleJVMDevOps语言 & 开发架构