在针对JDK 9（2017/4/4）提出的JEP中 ， Mark Reinhold写道JEP 291 （“弃用并发标记扫描（CMS）垃圾收集器”）是“已被放入“建议的在讨论和审查后，由所有者将其定位为目标”。 如果JEP 291一切顺利，它将针对JDK 9。

Reinhold在此消息中解释了为何在相对较晚的日期仍然可以将JEP 291定位到JDK 9：“ JEP 291仅需要微小的代码更改即可发出建议的警告消息。 首先，这是一个JEP，不是因为这是一个冒险的更改，而是要从长远来看使计划具有可见性，以删除CMS收集器。” 正如这些语句所指出的那样，JDK 9的针对性操作只是将并发标记扫描（CMS）收集器标记为已弃用，其想法是“从长远来看”将在某个时候将其删除。

尽管G1GC是JDK 9到JEP 248的默认垃圾收集器 ，但它并不总是适用于所有情况的最佳垃圾收集器。 甚至不建议使用CMS的提议在其“ 风险和假设 ”中也承认了这一点，其中指出：“对于某些应用程序，CMS非常适合，并且可能总是优于G1。”

关于OpenJDK jdk9-dev邮件列表的另一个最新讨论的标题为“ JEP 291：弃用并发标记扫描（CMS）垃圾收集器”，其中包含有关保留CMS的有趣论点。 Christoph Engelbert（Hazelcast） 写道 ：“ CMS + ParNew是最常用的解决方案，并且许多应用程序都针对CMS的行为进行了优化。” 斯科特·帕尔默（ Scott Palmer） 写道 ，“在他的特定应用中，“到目前为止，我们发现CMS收集器的最大暂停时间远低于G1。” Roman Kennke（RedHat） 补充说 ，“我说谈论删除CMS还为时过早。 而且，老实说，我什至质疑过时的举动。” Martijn Verburg（jClarity）表示：“我们现在不断被要求为客户调整G1，并且发现，即使使用我们最先进的分析（结合一些常见且更深奥的调整选项），我们也无法使G1达到在某些情况下优于CMS。 因此，一些客户已经恢复使用CMS，并且对CMS的未来（作为消费者）非常感兴趣。”

相同的讨论还包括不建议使用CMS的原因。 马克·雷因霍尔德（Mark Reinhold）的帖子指出，JEP 291是“去年夏天发布的”，并要求提供CMS维护者，但“到目前为止，没有人加紧。” 他总结说，“无论如何，Oracle确实打算在不远的将来停止维护CMS，如果没有人上任，我们将删除代码。”

Jeremy Manson（Google） 解释了G1GC和CMS当前情况的棘手问题：

我们决定，在尝试让G1做我们需要做的事情之后，以任何一种持续的方式支持CMS应该是最后的选择。 我们相信，收藏家越少越好。 在过去的几个月中，我们花了一些时间与Oracle的一些人员进行协调，并进行实验以查看G1是否有可行的前进方法。 我们找不到明显的东西。

这一切的主旨似乎是，许多应用程序仍依赖于CMS，并且这些应用程序将在JDK 9中显示已弃用警告。CMS垃圾收集器的未来似乎令人怀疑，但仅在JDK 9中才会弃用。何时真正删除CMS收集器似乎不太明显，但是我认为JDK 10是潜在的“未来主要发行版”，其中CMS支持可以终止。 再次引用曼森（Google）的话：“简短的是：我们仍然愿意为支持CMS做出贡献，但是我们要确保首先对G1进行了尽职调查。 我们一直认为JDK 10时间框架足够长，因此我们不必着急做出此决定。”

使用JDK9中的并发标记扫描垃圾收集器的Java应用程序似乎将看到有关CMS垃圾收集器已弃用的警告消息。 何时（或是否）根本无法使用CMS不太明显，而取决于谁愿意继续支持CMS。

翻译自: https://www.javacodegeeks.com/2017/04/java-garbage-collectors-will-g1gc-force-cms.html