删除已弃用的CMS垃圾收集器的JEP草案

在2017年4月10日的文章“ Java垃圾收集器：G1GC何时将CMS强制退出？ ”，我讨论了JEP 291 （“弃用并发标记扫描（CMS）垃圾收集器”），并提供了一些赞成和反对弃用（并最终淘汰）并发标记扫描（CMS）垃圾收集器（GC）的反馈摘要。本月初，一个名为“ 删除并发标记扫描垃圾收集器 ”的JEP 草案已创建。

该JEP草案的“摘要”部分指出：“从可用的垃圾收集算法集中删除并发标记扫描（CMS）垃圾收集器。” 尽管此JEP的“草稿”状态意味着它不针对任何特定发行版，但“非目标”部分向我们保证，JEP草案并不打算在删除CMS的发行版之前从任何发行版中删除CMS。帖子“ RFC：JEP：删除并发标记扫描垃圾收集器 ”指出，当前计划是针对JDK 14的 CMS删除。

JEP草案在“风险和假设”部分中指出，如果另一个“社区中感兴趣的可信贡献者将加紧维护，则可能撤回删除CMS GC的草案”。但是，自JEP 291弃用CMS以来的2年多时间里，没有这样的“感兴趣的可靠贡献者”提出要维护CMS。 Thomas Schatzl的与此JEP相关的帖子对此进行了更好的描述：

社区中始终可以选择组织CMS维护，但是没有人甚至开始着手解决长期存在的已知小问题CMS（以使贡献者了解CMS代码并让我们有信心这些人可以接管这么大的组件的维护）。

删除CMS的JEP草案专门提到了三个建议的替代垃圾收集器：现在默认的垃圾优先（G1）， Oracle提供的 ZGC和Red Hat提供的 Shenandoah 。

在审查JEP 291时，有很多反对弃用CMS的意见，现在也有完全删除CMS的意见。柯克·佩珀代因（Kirk Pepperdine ）写道，他和其他人已经注意到“ CMS开销远不及G1所能看到的水平”，他们“现在建议客户考虑使用并行GC，因为它提供了比G1更好的体验。”

在即将发布的JDK版本中（甚至早在JDK 14中），CMS可能会作为垃圾回收选项被删除。正如Kirk Pepperdine在有关该主题的另一篇文章中表示的：“归根结底，如果我们想要CMS，我们将不得不加紧努力，并为此做些事情。” 到目前为止，似乎还没有人急需CMS来做些什么（这可能包括与他们首选的JDK提供者合作，以使其在该提供者的JDK中得到支持）。