你不知道的CMS GC

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

Backgroud

可能更多人只知道CMS，而不知道Backgroud CMS。事實上我們說的CMS，即包含了5個階段的CMS，就是Background 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的C四是完全并發的。

為什么有個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

這個名詞第一次聽笨神說的。當然笨神也不是隨便自己捏造一個名詞出來，這個名詞來自于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，那么整個過程業務線程都是不可用的，效率會影響挺大。

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

如果觸發了FullGC，那就是ParNew+CMS組合最糟糕的情況。因為這個時候并發模式已經搞不定了，而且整個過程單線程，完全STW，甚至可能還會壓縮堆（是否壓縮堆在后面的MSC段落說明），真的不能再糟糕了！想象一下如果這時候業務量比較大，由于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

MSC

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

這是foreground CMS在特定情況下才會采用的一種垃圾回收算法。至于什么時候會采用MSC進行壓縮呢，請看源碼，依然在concurrentMarkSweepGeneration.cpp中：

//a method used by foreground collection to determine what type of collection 
//(compacting or not, continuing or fresh)it should do.
void CMSCollector::decide_foreground_collection_type(){
  ... ... 
  *should_compact =
    UseCMSCompactAtFullCollection &&
    ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) ||
     GCCause::is_user_requested_gc(gch->gc_cause()) ||
     gch->incremental_collection_will_fail(true /* consult_young */));    
  ... ... 
}

由這段源碼可知，foreground收集模式下如果采用MSC算法的壓縮模式，那么在-XX:+UseCMSCompactAtFullCollection前提下有三種可能：

1. 上一次CMS并發GC執行過后，再執行參數-XX:CMSFullGCsBeforeCompaction=0指定的Full GC次數，0表示每次FullGC后都會壓縮，同時0也是默認值；

2. 調用了System.gc()，當然這就要滿足-XX:-DisableExplicitGC；

3. 晉升擔保失敗，即預計Old區沒有足夠空間來容納下次YoungGC晉升的對象；

HOW?

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

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。