java gc cms_Java垃圾收集器：G1GC何时将CMS强制退出？

java gc cms

在针对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。