在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中得到支持）。
翻译自: https://www.javacodegeeks.com/2019/08/draft-jep-remove-deprecated-cms-garbage-collector.html