Hotspot CMS 垃圾收集器要退休了？

取得授权转载本文，请联系Dr. Tao Mao邮箱（yiyeguhu@gmail.com）。

日前，Hotspot JVM开发者小组召开了一次视频会议来讨论CMS 垃圾收集器的“退休”事宜（ http://openjdk.java.net/jeps/291）。此次会议是Hotspot开发者小组在邮件列表里线上讨论的延伸，主要的参与方是来自甲骨文、谷歌、RedHat、SAP、推特等公司的工程师们。会议总结如下：

JEP 291（废弃CMS 垃圾收集器）的目的

Oracle工程师Jon表示：G1 垃圾收集器在很多应用中的表现越来越好；希望跑在CMS上的应用能够迁移到G1垃圾收集器上来。Oracle很可能在JDK9 中宣布废弃（deprecate）HotspotCMS，并在JDK10 或 JDK 11时停止支持它。其中JDK9可能将于2017年3月发布。

希望继续使用和支持CMS 垃圾收集器的理由

来自谷歌和jClarity的工程师均表达了G1 垃圾收集器在有些应用上的表现不如CMS垃圾收集器。特别是它在CPU资源方面会带来10%－20%的额外消耗，这在数据中心的使用中不能让人满意。谷歌工程师Jeremy认为，性能测试显示是G1的writebarrier引起了额外CPU消耗。甲骨文工程师Jon则表示G1开发者会进一步在这些方面改进它。 

将来继续开发CMS 垃圾收集器的各方兴趣

谷歌、推特、SAP等公司均表示了不同程度的继续开发、支持CMS 垃圾收集器的兴趣，使其将来以某种独立于HotspotJVM实现的方式继续存在。各方讨论了继续使用原有Hotspot开发、测试平台的可能性。最终，讨论重点聚焦到如何将CMS垃圾收集器代码从Hotspot代码中分离出来，其中提到需要进一步研究Shenandoah垃圾收集器（RedHat正在开发的超低延时垃圾收集器 http://openjdk.java.net/jeps/189）的代码结构，以期望能与CMS垃圾收集器代码分离的工作相结合。

大家决定，会后研究CMS 垃圾收集器代码分离的工作量，以及其与Shenandoah垃圾收集器工作结合的问题。大家将在2016年9月的第二次视频会议和Java One年会的研讨会上继续讨论。看来，Hotspot JVM中的CMS 垃圾收集器在不久的将来要退出历史舞台，那它又将以另一种面貌继续存在吗？国内的阿里、京东等Java大厂要关注一下嚒？