深入理解CMS GC

背景

1. 網(wǎng)上關(guān)于cms gc介紹和調(diào)優(yōu)的文章比較多待德，但大多沒有經(jīng)過驗(yàn)證辐棒。因?yàn)閏ms目前在Java9之前還是相對(duì)用的較多（G1也需要持續(xù)去調(diào)研），所以這里把CMS的一些重要知識(shí)和調(diào)優(yōu)經(jīng)驗(yàn)總結(jié)一下

2. 相關(guān)jvm源代碼版本為/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/src/share/vm

   除了OpenJDK的源代碼和R大以外蹬刷，什么都不要輕易相信

CMS的一些重要知識(shí)點(diǎn)

1. 使用cms gc必備的三個(gè)參數(shù)

   -XX:+UseConcMarkSweepGC
   -XX:CMSInitiatingOccupancyFraction=n
   -XX:+UseCMSInitiatingOccupancyOnly
   

2. 默認(rèn)的NewRatio未生效吮成，新生代的大小不確定

   • 默認(rèn)的NewRatio為2，表示新生代和老年代比例是1:2郁稍，即占堆的1/3

   • 但是實(shí)際設(shè)置了-Xmx和-Xms后赦政，新生代的大小不符合預(yù)期

   • 原因:runtime.arguments.cpp

     else if (UseConcMarkSweepGC) {
         set_cms_and_parnew_gc_flags();
     }
     
     const size_t preferred_max_new_size_unaligned =
         MIN2(max_heap/(NewRatio+1), ScaleForWordSize(young_gen_per_worker * parallel_gc_threads));
     

   • 即cms新生代的大小是計(jì)算出來的

   • 所以通常使用cms的時(shí)候，建議手動(dòng)指定新生代大小參數(shù)(-XX:NewRatio或者-Xmn或者-XX:NewSize/-XX:MaxNewSize)

   • 另外JDK-6862534 : -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepGC耀怜，之前是即使手動(dòng)指定-XX:NewRatio恢着，也無效，現(xiàn)早已修復(fù)

3. 使用jstat -gccause pid觀察cms fgc的時(shí)候财破，發(fā)現(xiàn)每次到閾值回收的時(shí)候掰派，fgc每次會(huì)跳2次

   • 因?yàn)閏ms的一個(gè)并發(fā)周期內(nèi)有兩個(gè)階段initial mark與final re-mark，這兩個(gè)階段都是"stop the world"‘左痢，不過暫停時(shí)間較短
   • 而jstat的這個(gè)fgc的計(jì)數(shù)器是說的應(yīng)用暫停的次數(shù)
   • 注意這里所指的是'cms gc'引起的stw
   • 詳細(xì)可參考jstat顯示的full GC次數(shù)與CMS周期的關(guān)系

4. 如果觀察cms fgc靡羡，突然發(fā)現(xiàn)stw的時(shí)間很長，多達(dá)幾秒甚至更多俊性，一定是出現(xiàn)了異常情況略步，而這些情況的代價(jià)都十分昂貴，在做cms調(diào)優(yōu)的時(shí)候要盡可能的避免

   • concurrent mode failure

   1. 在cms并發(fā)周期執(zhí)行期間定页，用戶的線程依然在運(yùn)行趟薄，如果這時(shí)候如果應(yīng)用線程向老年代請(qǐng)求分配的空間超過預(yù)留的空間，就會(huì)拋出該錯(cuò)誤 - 后臺(tái)線程的收集沒有趕上應(yīng)用線程的分配速度
   2. 有時(shí)候“空間不足”是CMS GC時(shí)當(dāng)前的浮動(dòng)垃圾過多導(dǎo)致暫時(shí)性的空間不足典徊，而浮動(dòng)垃圾就是cms執(zhí)行期間用戶線程申請(qǐng)的內(nèi)存空間
   3. 這個(gè)錯(cuò)誤可能觸發(fā)兩種情況
    > cms的foreground模式（默認(rèn)的cms gc屬于background模式）杭煎，這個(gè)模式是CMS自己的mark-sweep來做不并發(fā)的（串行的）old generation GC，不過會(huì)將一些階段省略掉卒落。
        + CMS的foreground collector的算法就是普通的mark-sweep羡铲。它收集的范圍只是CMS的old generation，而不包括其它generation导绷。因而它在HotSpot VM里不叫做full GC
    > Serial Old GC
        + mark-sweep-compact算法
        + 它收集的范圍是整個(gè)GC堆犀勒，包括Java heap的young generation和old generation屎飘，以及non-Java heap的permanent generation妥曲。因而其名 Full GC
    > 前者的出現(xiàn)原因：A STW foreground collection can pick up where a concurrent background collection left off to try to avoid a full GC. This is nice but normally it has worse performance than a full GC.
        + 即是為了避免fgc，但是往往性能甚至比fgc更差
    > 對(duì)于第一種foreground模式钦购，必須要 -XX:-UseCMSCompactAtFullCollection  & -XX:CMSFullGCsBeforeCompaction設(shè)置大于0
        + 但是UseCMSCompactAtFullCollection默認(rèn)為true檐盟，CMSFullGCsBeforeCompaction默認(rèn)是0，所以一定會(huì)觸發(fā)第二種Serial Old GC
    > 參考:
        + https://bugs.openjdk.java.net/browse/JDK-8010202
        + https://bugs.openjdk.java.net/browse/JDK-8064702
        + https://bugs.openjdk.java.net/browse/JDK-8027132
        + 均建議foreground collector在Java8廢棄押桃，在Java9移除葵萎，包括UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction這兩個(gè)參數(shù)
   4. 所以通常來說不建議設(shè)置上面兩個(gè)參數(shù)，否則可能在Java8中會(huì)觸發(fā)foreground collector，可能會(huì)更慢(單線程)羡忘。所以通常當(dāng)出現(xiàn)concurrent mode failure時(shí)觸發(fā)的都是Serial Old GC
   

   1. 關(guān)于UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction的警告源代碼
   runtime\arguments.cpp
    
    if (FLAG_IS_CMDLINE(UseCMSCompactAtFullCollection)) {
       warning("UseCMSCompactAtFullCollection is deprecated and will likely be removed in a future release.");
     }
     
     if (FLAG_IS_CMDLINE(CMSFullGCsBeforeCompaction)) {
       warning("CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release.");
     }
   
   2. 關(guān)于用哪種處理方式的源代碼 gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
   
   void CMSCollector::acquire_control_and_collect{
   ...
   bool should_compact    = false;
   decide_foreground_collection_type(clear_all_soft_refs,
       &should_compact, &should_start_over);
   ...
   
   if (should_compact) {
   ...
   // 這個(gè)就是mark-sweep-compact 的 Full GC
   do_compaction_work(clear_all_soft_refs);
   ...
   
   }else {
       // mark-sweep
       do_mark_sweep_work(clear_all_soft_refs, first_state,
         should_start_over);
   }
   
   *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 */));
        
   而should_compact主要的一個(gè)判斷邏輯就是判斷UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction這兩個(gè)參數(shù)
   

   • promotion failed

   1. Java Performance,The Definitive Guide的原文是這樣描述的：
      - Here, CMS started a young collection and assumed that there was enough free space to hold all the promoted objects (otherwise, it would have declared a concurrent mode failure). That assumption proved incorrect: CMS couldn’t promote the objects because the old generation was fragmented (or, much less likely, because the amount of memory to be promoted was bigger than CMS expected).
      - 翻譯：新生代垃圾收集谎痢，判斷老年代似乎有足夠的空閑空間可以容納所有的晉升對(duì)象（否則，CMS收集器會(huì)報(bào)concurrent mode failure）卷雕。這個(gè)假設(shè)最終被證明是錯(cuò)誤的节猿，由于老年代空間的碎片化（或者，不太貼切的說漫雕，由于晉升實(shí)際要占用的內(nèi)存超過了CMS收集器的判斷）滨嘱，CMS收集器無法晉升這些對(duì)象。
   2. Sometimes we see these promotion failures even when thelogs show that there is enough free space in tenured generation. The reason is'fragmentation' - the free space available in tenured generation is notcontiguous, and promotions from young generation require a contiguous freeblock to be available in tenured generation. CMS collector is a non-compactingcollector, so can cause fragmentation of space for some type of applications.
      - 翻譯：CMS收集器對(duì)老年代收集的時(shí)候浸间，不再進(jìn)行任何壓縮和整理的工作太雨，意味著老年代隨著應(yīng)用的運(yùn)行會(huì)變得碎片化；碎片過多會(huì)影響大對(duì)象的分配魁蒜，雖然老年代還有很大的剩余空間囊扳，但是沒有連續(xù)的空間來分配大對(duì)象
   3. 如果在ParNew準(zhǔn)備收集時(shí)CMS說晉升沒問題，但ParNew已經(jīng)開始收集之后確實(shí)遇到了晉升失敗的情況
   4. promotion failed是說兜看，擔(dān)保機(jī)制確定老年代是否有足夠的空間容納新來的對(duì)象宪拥，如果擔(dān)保機(jī)制說有，但是真正分配的時(shí)候發(fā)現(xiàn)由于碎片導(dǎo)致找不到連續(xù)的空間而失斚臣酢她君；而concurrent mode failure是指并發(fā)周期還沒執(zhí)行完，用戶線程就來請(qǐng)求比預(yù)留空間更大的空間了葫哗，即后臺(tái)線程的收集沒有趕上應(yīng)用線程的分配速度缔刹。
   5. promotion failed觸發(fā)fgc，觸發(fā)模式同上劣针，通常也是Serial Old GC
   

   • permgen (or the metaspace) fills up

   1. 對(duì)于Java8來說校镐，這個(gè)主要是在metaspace擴(kuò)容時(shí)觸發(fā)的
   2. 如果老年代設(shè)置了 CMS，則 Metasapce 擴(kuò)容引起的 FGC 會(huì)轉(zhuǎn)變成一次 CMS
   3. Java8中收集器默認(rèn)就會(huì)收集元空間中不再載入的類
   

5. 在剛啟動(dòng)應(yīng)用后捺典，通過jstat -gccause pid后看到出現(xiàn)了fgc鸟廓，此時(shí)ou也沒有占用

   • 通常這種情況是上面提到的metaspace擴(kuò)容引起的，從LGCC也可以看到'Metadata GC Threshold'襟己，觸發(fā)的原因是因?yàn)镸etaspace大小達(dá)到了GC閾值
   • MetaspaceSize主要是控制metaspaceGC發(fā)生的初始閾值引谜，也是最小閾值，但是觸發(fā)metaspaceGC的閾值是不斷變化的

    jstat -gccause 23270 1000
     S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                 
     0.00  25.87  82.46   0.00  97.47  94.80      1    0.124     2    0.096    0.220 Metadata GC Threshold No GC
   

6. 通過觀察gc日志擎浴，出現(xiàn)cms異常的幾種情況

   [ParNew (promotion failed): ... (concurrent mode failure):...

   • 這種情況是先出現(xiàn)了promotion failed员咽，然后準(zhǔn)備觸發(fā)fgc

   • 而此時(shí)cms這在執(zhí)行并發(fā)收集，此時(shí)則執(zhí)行打斷邏輯贮预，輸出concurrent mode failure

   • 具體源代碼也是concurrentMarkSweepGeneration.cpp

     if (first_state > Idling) {
         report_concurrent_mode_interruption();
     }
     

   [ParNew (promotion failed): ...

   • 這種情況就是單純出現(xiàn)了promotion failed贝室，此時(shí)cms未執(zhí)行并發(fā)收集

   (concurrent mode failure): ...

   • 這種情況是單純的cms正在執(zhí)行并發(fā)收集契讲，然后用戶線程申請(qǐng)內(nèi)存空間不足

7. jvm有一個(gè)內(nèi)存擔(dān)保機(jī)制，是類似于判斷'老年代最大的可用連續(xù)空間是否大于新生代所有對(duì)象的總和'滑频。但通常描述promotion failed的時(shí)候是指擔(dān)保機(jī)制夠了捡偏， 才會(huì)發(fā)生。那么既然有最大可用連續(xù)空間峡迷，為什么還會(huì)failed

   • with 5.0 because a single contiguous chunk of space is not required
     for promotions霹琼，即在jdk5后，晉升不需要連續(xù)空間了
   • 所以這里的擔(dān)保是指'老年代是否有足夠的空間容納要晉升的對(duì)象'凉当，而不是連續(xù)空間枣申。那么出現(xiàn)fail，則是碎片問題

CMS優(yōu)化方向

1. 原則

   • cms的的優(yōu)勢(shì)就是低延遲看杭，但是如果出現(xiàn)了長時(shí)間的stw忠藤，則對(duì)應(yīng)用程序有很大的影響
   • 如果出現(xiàn)了concurrent mode failure和promotion failed，代價(jià)都非常昂貴楼雹，我們調(diào)優(yōu)應(yīng)該盡量避免這些情況

2. 針對(duì)concurrent mode failure的優(yōu)化

   • 發(fā)生該失敗的主要原因是由于CMS不能以足夠快的速度清理老年代空間

   • 當(dāng)老年代空間的占用達(dá)到某個(gè)閾值時(shí)模孩，并發(fā)回收就開始了。一個(gè)CMS后臺(tái)線程開始掃描老年代空間贮缅，尋找無用的垃圾對(duì)象時(shí)榨咐，競爭就開始了。CMS收集器必須在老年代剩余的空間用盡之前谴供，完成老年代空間的掃描及回收工作块茁。否則如果在正常速度的比賽中失效，就會(huì)發(fā)生該錯(cuò)誤

   • 在并發(fā)清理階段桂肌，用戶線程仍然在運(yùn)行数焊，必須預(yù)留出空間給用戶線程使用，會(huì)產(chǎn)生’浮動(dòng)垃圾‘

   • 常規(guī)優(yōu)化途徑如下：

     以更高的頻率執(zhí)行后臺(tái)的回收線程崎场，即提高CMS并發(fā)周期發(fā)生的頻率

     • 主要是調(diào)低CMSInitiatingOccupancyFraction的值

     • 但是不能太低佩耳，太低會(huì)導(dǎo)致過于頻繁的gc，會(huì)消耗更多的的cpu和停頓

     • landon

       需要先計(jì)算老年代常駐內(nèi)存大小谭跨，如占用60%干厚，那么這個(gè)閾值則可以設(shè)置為約70%，否則會(huì)比較頻繁gc

       可以考慮擔(dān)保機(jī)制螃宙，只要老年代預(yù)留剩余空間大于年輕代大小蛮瞄，比如新生代和老年代的比例是1 : 4，即新生代占用老年代的25%污呼，那么這個(gè)閾值可以設(shè)置為70裕坊，即老年代還預(yù)留出來30%的空間

       注意如果浮動(dòng)垃圾很多的話燕酷，也無法解決該問題籍凝，即cms并發(fā)回收期間，浮動(dòng)垃圾越來越多苗缩，占用預(yù)留空間饵蒂，多次的ygc的話，會(huì)有填滿預(yù)留空間的可能酱讶，雖然概率較低

       兩個(gè)條件綜合考慮退盯，如果設(shè)置了閾值70，但是老年代常駐內(nèi)存很大泻肯，甚至超過70渊迁，那么此時(shí)的建議要提高堆內(nèi)存，增加老年代的大小或者減少新生代的大小

3. 針對(duì)promotion failed的優(yōu)化

   • 這個(gè)是cms最為嚴(yán)重的’碎片問題‘灶挟，我們要盡量避免這個(gè)發(fā)生后引起的fgc

   • 所以優(yōu)化這個(gè)問題琉朽，也可以描述為'如何解決碎片問題'

   • 常規(guī)優(yōu)化途徑如下

     • 增大堆內(nèi)存，增加老年代大小稚铣，但要注意不要超過32g(the HotSpot JVM uses a trick to compress object pointers when heaps are less than around 32 GB)

     • 盡早執(zhí)行cms gc箱叁，合理設(shè)置CMSInitiatingOccupancyFraction，會(huì)合并老生代中相鄰的free空間惕医，可分配給較大的對(duì)象

     • 和上面一樣耕漱，也可以做一個(gè)老年代預(yù)留空間大于年輕代

     到了閾值后，就會(huì)觸發(fā)cms gc抬伺，但還是和上面說的螟够，會(huì)產(chǎn)生浮動(dòng)垃圾 + 碎片，還是會(huì)出現(xiàn)

     • 另外一個(gè)比較“挫”的辦法峡钓，是在每天凌晨訪問量低的時(shí)候齐鲤，主動(dòng)執(zhí)行一下fgc，執(zhí)行一下'碎片壓縮'

     • 如System.gc椒楣，但是要注意是否開啟了-XX:+ExplicitGCInvokesConcurrent

     • 所以建議辦法是用jmap -histo:live

   • 另外晉升還包括to space空間小给郊，可以根據(jù)情況嘗試提高Survivor

CMS實(shí)戰(zhàn)參數(shù)

1. 日志，主要是用來排查cms相關(guān)問題

   基礎(chǔ)參數(shù)：
   -Xloggc:gc_%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
   
   可選調(diào)試參數(shù):
    -XX:+PrintGCApplicationStoppedTime
    -XX:+PrintTenuringDistribution
    -XX:+PrintPromotionFailure
    -XX:+PrintHeapAtGC
    -XX:PrintFLSStatistics=1
   

2. cms相關(guān)

   1. 物理機(jī)內(nèi)存：16G
   2. 預(yù)估老年代常駐對(duì)象如Player 3000捧灰，一個(gè)Player平均2M淆九，大約6G，所以老年代比如建議10G
   3. -Xms12G -Xmx12G
   4. 設(shè)置新生代2G毛俏，老年代10G
   5. 設(shè)置CMSInitiatingOccupancyFraction為70炭庙，則老年代剩余空間為3G，大于新生代大小
   6. 可選：-XX:+CMSScavengeBeforeRemark
   
   簡單算法：
   -XX:NewRatio=4煌寇，即新生代和老年代1:4
   然后設(shè)置CMSInitiatingOccupancyFraction為70焕蹄，即老年代剩余空間稍大新生代
   但要保證這個(gè)70基本上要大于老年代常駐內(nèi)存，否則可能會(huì)頻繁cms gc
   
   另外建議增加腳本阀溶，嘗試手動(dòng)執(zhí)行fgc腻脏，整理碎片
   如每天凌晨3點(diǎn)
   jstat -gccause pid >> cms.log
   jmap -histo pid >> cms.log
   jstat -gccause pid >> cms.log
   jmap -histo:live pid >> cms.log
   

3. metaspace

   設(shè)置 -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m
   注意如果設(shè)置的過小鸦泳，則會(huì)引起fgc甚至metaspace oom
   

其他

1. cms如果出現(xiàn)ygc時(shí)間較長，可以考慮可能是老年代碎片過多永品，解決方案也是嘗試在業(yè)務(wù)低峰主動(dòng)觸發(fā)fgc執(zhí)行壓縮
2. TODO 了解cms的free list
3. TODO 學(xué)習(xí)Optimizing Java

參考

1. R大
   • https://hllvm-group.iteye.com/group/topic/42365
   • https://hllvm-group.iteye.com/group/topic/28854
   • https://rednaxelafx.iteye.com/blog/1108768
   • https://www.zhihu.com/question/41922036
2. 滌生的博客
   • http://www.disheng.tech/blog/%E6%9C%8D%E5%8A%A1%E5%88%9A%E5%90%AF%E5%8A%A8%E5%B0%B1-full-gc%E8%A6%81%E9%97%B9%E5%93%AA%E6%A0%B7/
   • http://www.disheng.tech/blog/jvm-%E6%BA%90%E7%A0%81%E8%A7%A3%E8%AF%BB%E4%B9%8B-cms-%E4%BD%95%E6%97%B6%E4%BC%9A%E8%BF%9B%E8%A1%8C-full-gc/
   • http://www.disheng.tech/blog/jvm-%E6%BA%90%E7%A0%81%E8%A7%A3%E8%AF%BB%E4%B9%8B-cms-gc-%E8%A7%A6%E5%8F%91%E6%9D%A1%E4%BB%B6/
3. 其他
   • 杜琪 http://www.reibang.com/p/78017c8b8e0f
   • 劉家財(cái) https://liujiacai.net/blog/2019/01/09/java-gc-definitive-guide/
   • 畢玄 http://hellojava.info/?p=142
   • 占小狼 http://www.reibang.com/p/55670407fdb9
   • 江南白衣 http://calvin1978.blogcn.com/articles/jvmoption-7.html
   • 你假笨