在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 conditionForegroud
這個名詞第一次聽笨神說的。當然笨神也不是隨便自己捏造一個名詞出來，這個名詞來自於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前提下有三種可能：
-
上一次CMS併發GC執行過後，再執行參數
-XX:CMSFullGCsBeforeCompaction=0指定的Full GC次數，0表示每次FullGC後都會壓縮，同時0也是默認值； -
調用了System.gc()，當然這就要滿足
-XX:-DisableExplicitGC； - 晉升擔保失敗，即預計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。