在針對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

總結

以上是生活随笔為你收集整理的Java垃圾收集器：G1GC何时将CMS强制退出？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。