• 寫在前面

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

在G1出來之前隘冲，CMS絕對是OLTP系統(tǒng)的標(biāo)配。即使G1出來幾年了绑雄，生產(chǎn)環(huán)境很多的JVM實例還是采用ParNew+CMS的組合展辞。但是即使其得到這么廣泛的應(yīng)用，還是有很多同學(xué)對它有很深的誤解万牺。本文主要對ParNew+CMS經(jīng)典組合下纵竖，觸發(fā)的幾種垃圾回收方式進行幾個概念的糾正。

Backgroud CMS

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

CMS示意圖

說明：

• 圖中初始化標(biāo)記階段是串行的度液，這是JDK7的行為厕宗。JDK8以后默認(rèn)是并行的，可以通過參數(shù)-XX:+CMSParallelInitialMarkEnabled控制堕担。
• 由圖可知已慢，CMS還有兩個階段是完全STW（Stop The World）的，即初始化標(biāo)記和最終標(biāo)記（重新標(biāo)記）霹购。
• 其他階段都是并發(fā)的佑惠，所以CMS被稱為Concurrent Mark&Sweep，但是我認(rèn)為前面還需要加個Mostly才是最貼切，即CMS是一個Mostly Concurrent Mark and Sweep Garbage Collector膜楷，因為它還沒辦法做到完全并發(fā)旭咽。

不只是CMS，就是G1赌厅，以及JDK11的ZGC都沒有做到完全的并發(fā)穷绵。就目前筆者了解到的所有GC中，只有Azul的C4是完全并發(fā)的特愿。

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

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

Foregroud CMS

這個名詞第一次聽笨神說的（公眾號：你假笨）膳叨。當(dāng)然笨神也不是隨便自己捏造一個名詞出來洽洁，這個名詞來自于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:
        // 預(yù)清理啥都沒干
    case AbortablePreclean:
        // Elide(省略菲嘴，取消的意思饿自，相當(dāng)于這個階段也啥都沒做) the preclean phase
        _collectorState = FinalMarking;
        break;
    default:
        ShouldNotReachHere();
}

源碼比較多，我就不全部貼出來的龄坪，有興趣的同學(xué)可以自己下載源碼查看昭雌。

它發(fā)生的場景，比如業(yè)務(wù)線程請求分配內(nèi)存健田，但是內(nèi)存不夠了烛卧，于是可能觸發(fā)一次CMS GC，這個過程就必須要等待內(nèi)存分配成功后業(yè)務(wù)線程才能繼續(xù)往下面走妓局，因此整個過程必須STW总放，所以這種CMS GC整個過程都是STW，但是為了提高效率好爬，它并不是每個階段都會走的局雄，只走其中一些階段，通過上面的源碼可知存炮，這些省下來的階段主要是并行階段：Precleaning炬搭、AbortablePreclean蜈漓，Resizing。但不管怎么說如果走了類似foreground這種CMS GC尚蝌，那么整個過程業(yè)務(wù)線程都是不可用的迎变，效率會影響挺大。

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

MSC

MSC的全稱是Mark Sweep Compact，即標(biāo)記-清理-壓縮姿鸿，MSC是一種算法谆吴，請注意Compact，即它會壓縮整理堆苛预，這一點很重要句狼。

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

-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=0

配置-XX:+UseCMSCompactAtFullCollection（默認(rèn)）前提下筹吐，如果CMSFullGCsBeforeCompaction=0，那么每次foreground CMS后都會采用MSC算法壓縮堆內(nèi)存秘遏；如果CMSFullGCsBeforeCompaction=3丘薛，那么每3次foreground CMS后才會有1次采用MSC算法壓縮堆內(nèi)存。

碎片問題也是CMS采用的標(biāo)記清理算法最讓人詬病的地方：Backgroud CMS采用的標(biāo)記清理算法會導(dǎo)致內(nèi)存碎片問題邦危，從而埋下發(fā)生FullGC導(dǎo)致長時間STW的隱患洋侨。

所以如果觸發(fā)了FullGC，無論是否會采用MSC算法壓縮堆倦蚪，那都是ParNew+CMS組合非常糟糕的情況希坚。因為這個時候并發(fā)模式已經(jīng)搞不定了，而且整個過程單線程陵且，完全STW裁僧，可能會壓縮堆（是否壓縮堆通過上面兩個參數(shù)控制），真的不能再糟糕了滩报！想象如果這時候業(yè)務(wù)量比較大，由于FullGC導(dǎo)致服務(wù)完全暫停幾秒鐘播急，甚至上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這么恐怖，有辦法緩解么，或者說盡量避免它在白天握截，甚至業(yè)務(wù)高峰期出現(xiàn)飞崖？有！筆者給你分享一個歪門邪道谨胞，不記得是多少年前固歪，在哪里道聽途說才得到這個偏方的，而且據(jù)說以前阿里的一些業(yè)務(wù)也用了這個偏方胯努，不管是哪里得來的偏方牢裳，反正肯定有用的。這個偏方很簡單：在業(yè)務(wù)最低峰期（比如大陸的很多業(yè)務(wù)可以選在凌晨2叶沛，3點夜深人靜的時候）強行觸發(fā)FullGC（需要結(jié)合參數(shù)-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0蒲讯，這兩個參數(shù)默認(rèn)值就是這樣的，表示觸發(fā)FullGC時壓縮堆）灰署，從而優(yōu)化內(nèi)存碎片并壓縮堆判帮，降低在業(yè)務(wù)高峰期發(fā)生FullGC的概率（只能降低，不能杜絕）溉箕。

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

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

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

總結(jié)

按照慣例约巷，最后來個總結(jié)：

• 正常情況下觸發(fā)Backgroud模式的CMS GC偎痛，這是并發(fā)模式收集，對業(yè)務(wù)影響很小独郎，你好我好都好踩麦。
• 當(dāng)并發(fā)模式搞不定了，就會退化成Foreground模式氓癌，這個回收過程業(yè)務(wù)線程是不可用的谓谦，這時候就觸發(fā)了FullGC。
• 接下來根據(jù)上面提到的兩個參數(shù)決定是否采用MSC算法壓縮堆贪婉。
• CMSFullGCsBeforeCompaction決定多少次FullGC后壓縮堆反粥，具體配置多大，由你決定疲迂，但是不建議太大才顿，否則在采用MSC算法壓縮堆之前，由于內(nèi)存碎片的問題尤蒿，導(dǎo)致出現(xiàn)promotion failure郑气，總之這是trade-off。

友情提醒：

1. JVM很難腰池，網(wǎng)上錯誤的觀點很多尾组；
2. 再次推薦你假笨（公眾號）和RednaxelaFX（只有知乎和ITEYE忙芒，江湖人稱R大）。

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