• 寫在前面

非常感謝笨神對這篇文章的一些指正。

在G1出來之前，CMS絕對是OLTP系統的標配。即使G1出來幾年了，生產環境很多的JVM實例還是采用ParNew+CMS的組合。但是即使其得到這么廣泛的應用，還是有很多同學對它有很深的誤解。本文主要對ParNew+CMS經典組合下，觸發的幾種垃圾回收方式進行幾個概念的糾正。

Backgroud CMS

可能更多人只知道CMS，而不知道Backgroud CMS。事實上我們說的CMS，即包含了5個階段的CMS，就是Background CMS，如下圖所示：

CMS示意圖

說明：

• 圖中初始化標記階段是串行的，這是JDK7的行為。JDK8以后默認是并行的，可以通過參數-XX:+CMSParallelInitialMarkEnabled控制。
• 由圖可知，CMS還有兩個階段是完全STW（Stop The World）的，即初始化標記和最終標記（重新標記）。
• 其他階段都是并發的，所以CMS被稱為Concurrent Mark&Sweep，但是我認為前面還需要加個Mostly才是最貼切，即CMS是一個Mostly Concurrent Mark and Sweep Garbage Collector，因為它還沒辦法做到完全并發。

不只是CMS，就是G1，以及JDK11的ZGC都沒有做到完全的并發。就目前筆者了解到的所有GC中，只有Azul的C4是完全并發的。

為什么有個Background關鍵詞？我們都知道配置CMS垃圾回收的話，有兩個重要參數：-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly，這兩個參數表示只有在Old區占了75%的內存時才滿足觸發CMS的條件。注意這只是滿足觸發CMS GC的條件。至于什么時候真正觸發CMS GC，由一個后臺掃描線程決定。CMSThread默認2秒鐘掃描一次，判斷是否需要觸發CMS，這個參數可以更改這個掃描時間間隔，例如-XX:CMSWaitDuration=5000，此外可以通過jstack日志看到這個線程：

"Concurrent Mark-Sweep GC Thread" os_prio=2 tid=0x000000001870f800 nid=0x0f4 waiting on condition

Foregroud CMS

這個名詞第一次聽笨神說的（公眾號：你假笨）。當然笨神也不是隨便自己捏造一個名詞出來，這個名詞來自于openjdk源碼，參考concurrentMarkSweepGeneration.cpp：

void CMSCollector::collect_in_foreground(bool clear_all_soft_refs, GCCause::Cause cause) {
    case Resizing: {
        // nothing to be done in this state. 即這個階段啥都沒做
        _collectorState = Resetting;
        break;
    }  
    case Precleaning:
        // 預清理啥都沒干
    case AbortablePreclean:
        // Elide(省略，取消的意思，相當于這個階段也啥都沒做) the preclean phase
        _collectorState = FinalMarking;
        break;
    default:
        ShouldNotReachHere();
}

源碼比較多，我就不全部貼出來的，有興趣的同學可以自己下載源碼查看。

它發生的場景，比如業務線程請求分配內存，但是內存不夠了，于是可能觸發一次CMS GC，這個過程就必須要等待內存分配成功后業務線程才能繼續往下面走，因此整個過程必須STW，所以這種CMS GC整個過程都是STW，但是為了提高效率，它并不是每個階段都會走的，只走其中一些階段，通過上面的源碼可知，這些省下來的階段主要是并行階段：Precleaning、AbortablePreclean，Resizing。但不管怎么說如果走了類似foreground這種CMS GC，那么整個過程業務線程都是不可用的，效率會影響挺大。

這事實上就是發生了FullGC，由這段的分析可知FullGC相比CMS Backgroud collect模式差距還是非常大的。

MSC

MSC的全稱是Mark Sweep Compact，即標記-清理-壓縮，MSC是一種算法，請注意Compact，即它會壓縮整理堆，這一點很重要。

這是foreground CMS在特定情況下才會采用的一種垃圾回收算法。為什么這么說了，這里需要介紹兩個參數，這兩個參數表示多少次FullGC后采用MSC算法壓縮堆內存，0表示每次FullGC后都會壓縮，同時0也是默認值：

-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=0

配置-XX:+UseCMSCompactAtFullCollection（默認）前提下，如果CMSFullGCsBeforeCompaction=0，那么每次foreground CMS后都會采用MSC算法壓縮堆內存；如果CMSFullGCsBeforeCompaction=3，那么每3次foreground CMS后才會有1次采用MSC算法壓縮堆內存。

碎片問題也是CMS采用的標記清理算法最讓人詬病的地方：Backgroud CMS采用的標記清理算法會導致內存碎片問題，從而埋下發生FullGC導致長時間STW的隱患。

所以如果觸發了FullGC，無論是否會采用MSC算法壓縮堆，那都是ParNew+CMS組合非常糟糕的情況。因為這個時候并發模式已經搞不定了，而且整個過程單線程，完全STW，可能會壓縮堆（是否壓縮堆通過上面兩個參數控制），真的不能再糟糕了！想象如果這時候業務量比較大，由于FullGC導致服務完全暫停幾秒鐘，甚至上10秒，對用戶體驗影響得多大。

另外，別以為G1就好很多，G1的FullGC同樣是垃圾級別的存在：
The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm.

原文出自：http://openjdk.java.net/jeps/307

HOW?

FullGC這么恐怖，有辦法緩解么，或者說盡量避免它在白天，甚至業務高峰期出現？有！筆者給你分享一個歪門邪道，不記得是多少年前，在哪里道聽途說才得到這個偏方的，而且據說以前阿里的一些業務也用了這個偏方，不管是哪里得來的偏方，反正肯定有用的。這個偏方很簡單：在業務最低峰期（比如大陸的很多業務可以選在凌晨2，3點夜深人靜的時候）強行觸發FullGC（需要結合參數-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0，這兩個參數默認值就是這樣的，表示觸發FullGC時壓縮堆），從而優化內存碎片并壓縮堆，降低在業務高峰期發生FullGC的概率（只能降低，不能杜絕）。

可能還有一小部分同學連強行觸發FullGC都不知道，筆者好人做到底，送佛送到西：

# 沒有開啟-XX:+DisableExplicitGC的前提下調用System.gc()就會發生FullGC
System.gc();

或者通過jmap命令觸發：
# jmap -histo:live pid

總結

按照慣例，最后來個總結：

• 正常情況下觸發Backgroud模式的CMS GC，這是并發模式收集，對業務影響很小，你好我好都好。
• 當并發模式搞不定了，就會退化成Foreground模式，這個回收過程業務線程是不可用的，這時候就觸發了FullGC。
• 接下來根據上面提到的兩個參數決定是否采用MSC算法壓縮堆。
• CMSFullGCsBeforeCompaction決定多少次FullGC后壓縮堆，具體配置多大，由你決定，但是不建議太大，否則在采用MSC算法壓縮堆之前，由于內存碎片的問題，導致出現promotion failure，總之這是trade-off。

友情提醒：

1. JVM很難，網上錯誤的觀點很多；
2. 再次推薦你假笨（公眾號）和RednaxelaFX（只有知乎和ITEYE，江湖人稱R大）。

友情鏈接：http://hllvm.group.iteye.com/group/topic/28854（又是來自R大滿滿的干貨，喜歡JVM的一定不要錯過）