深入理解CMS GC

背景

1. 網上關于cms gc介紹和調優的文章比較多，但大多沒有經過驗證。因為cms目前在Java9之前還是相對用的較多（G1也需要持續去調研），所以這里把CMS的一些重要知識和調優經驗總結一下

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

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

CMS的一些重要知識點

1. 使用cms gc必備的三個參數

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

2. 默認的NewRatio未生效，新生代的大小不確定

   • 默認的NewRatio為2，表示新生代和老年代比例是1:2，即占堆的1/3

   • 但是實際設置了-Xmx和-Xms后，新生代的大小不符合預期

   • 原因: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新生代的大小是計算出來的

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

   • 另外JDK-6862534 : -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepGC，之前是即使手動指定-XX:NewRatio，也無效，現早已修復

3. 使用jstat -gccause pid觀察cms fgc的時候，發現每次到閾值回收的時候，fgc每次會跳2次

   • 因為cms的一個并發周期內有兩個階段initial mark與final re-mark，這兩個階段都是"stop the world"‘，不過暫停時間較短
   • 而jstat的這個fgc的計數器是說的應用暫停的次數
   • 注意這里所指的是'cms gc'引起的stw
   • 詳細可參考jstat顯示的full GC次數與CMS周期的關系

4. 如果觀察cms fgc，突然發現stw的時間很長，多達幾秒甚至更多，一定是出現了異常情況，而這些情況的代價都十分昂貴，在做cms調優的時候要盡可能的避免

   • concurrent mode failure

   1. 在cms并發周期執行期間，用戶的線程依然在運行，如果這時候如果應用線程向老年代請求分配的空間超過預留的空間，就會拋出該錯誤 - 后臺線程的收集沒有趕上應用線程的分配速度
   2. 有時候“空間不足”是CMS GC時當前的浮動垃圾過多導致暫時性的空間不足，而浮動垃圾就是cms執行期間用戶線程申請的內存空間
   3. 這個錯誤可能觸發兩種情況
    > cms的foreground模式（默認的cms gc屬于background模式），這個模式是CMS自己的mark-sweep來做不并發的（串行的）old generation GC，不過會將一些階段省略掉。
        + CMS的foreground collector的算法就是普通的mark-sweep。它收集的范圍只是CMS的old generation，而不包括其它generation。因而它在HotSpot VM里不叫做full GC
    > Serial Old GC
        + mark-sweep-compact算法
        + 它收集的范圍是整個GC堆，包括Java heap的young generation和old generation，以及non-Java heap的permanent generation。因而其名 Full GC
    > 前者的出現原因：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更差
    > 對于第一種foreground模式，必須要 -XX:-UseCMSCompactAtFullCollection  & -XX:CMSFullGCsBeforeCompaction設置大于0
        + 但是UseCMSCompactAtFullCollection默認為true，CMSFullGCsBeforeCompaction默認是0，所以一定會觸發第二種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這兩個參數
   4. 所以通常來說不建議設置上面兩個參數，否則可能在Java8中會觸發foreground collector，可能會更慢(單線程)。所以通常當出現concurrent mode failure時觸發的都是Serial Old GC
   

   1. 關于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. 關于用哪種處理方式的源代碼 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) {
   ...
   // 這個就是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主要的一個判斷邏輯就是判斷UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction這兩個參數
   

   • 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).
      - 翻譯：新生代垃圾收集，判斷老年代似乎有足夠的空閑空間可以容納所有的晉升對象（否則，CMS收集器會報concurrent mode failure）。這個假設最終被證明是錯誤的，由于老年代空間的碎片化（或者，不太貼切的說，由于晉升實際要占用的內存超過了CMS收集器的判斷），CMS收集器無法晉升這些對象。
   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收集器對老年代收集的時候，不再進行任何壓縮和整理的工作，意味著老年代隨著應用的運行會變得碎片化；碎片過多會影響大對象的分配，雖然老年代還有很大的剩余空間，但是沒有連續的空間來分配大對象
   3. 如果在ParNew準備收集時CMS說晉升沒問題，但ParNew已經開始收集之后確實遇到了晉升失敗的情況
   4. promotion failed是說，擔保機制確定老年代是否有足夠的空間容納新來的對象，如果擔保機制說有，但是真正分配的時候發現由于碎片導致找不到連續的空間而失敗；而concurrent mode failure是指并發周期還沒執行完，用戶線程就來請求比預留空間更大的空間了，即后臺線程的收集沒有趕上應用線程的分配速度。
   5. promotion failed觸發fgc，觸發模式同上，通常也是Serial Old GC
   

   • permgen (or the metaspace) fills up

   1. 對于Java8來說，這個主要是在metaspace擴容時觸發的
   2. 如果老年代設置了 CMS，則 Metasapce 擴容引起的 FGC 會轉變成一次 CMS
   3. Java8中收集器默認就會收集元空間中不再載入的類
   

5. 在剛啟動應用后，通過jstat -gccause pid后看到出現了fgc，此時ou也沒有占用

   • 通常這種情況是上面提到的metaspace擴容引起的，從LGCC也可以看到'Metadata GC Threshold'，觸發的原因是因為Metaspace大小達到了GC閾值
   • MetaspaceSize主要是控制metaspaceGC發生的初始閾值，也是最小閾值，但是觸發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日志，出現cms異常的幾種情況

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

   • 這種情況是先出現了promotion failed，然后準備觸發fgc

   • 而此時cms這在執行并發收集，此時則執行打斷邏輯，輸出concurrent mode failure

   • 具體源代碼也是concurrentMarkSweepGeneration.cpp

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

   [ParNew (promotion failed): ...

   • 這種情況就是單純出現了promotion failed，此時cms未執行并發收集

   (concurrent mode failure): ...

   • 這種情況是單純的cms正在執行并發收集，然后用戶線程申請內存空間不足

7. jvm有一個內存擔保機制，是類似于判斷'老年代最大的可用連續空間是否大于新生代所有對象的總和'。但通常描述promotion failed的時候是指擔保機制夠了， 才會發生。那么既然有最大可用連續空間，為什么還會failed

   • with 5.0 because a single contiguous chunk of space is not required
     for promotions，即在jdk5后，晉升不需要連續空間了
   • 所以這里的擔保是指'老年代是否有足夠的空間容納要晉升的對象'，而不是連續空間。那么出現fail，則是碎片問題

CMS優化方向

1. 原則

   • cms的的優勢就是低延遲，但是如果出現了長時間的stw，則對應用程序有很大的影響
   • 如果出現了concurrent mode failure和promotion failed，代價都非常昂貴，我們調優應該盡量避免這些情況

2. 針對concurrent mode failure的優化

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

   • 當老年代空間的占用達到某個閾值時，并發回收就開始了。一個CMS后臺線程開始掃描老年代空間，尋找無用的垃圾對象時，競爭就開始了。CMS收集器必須在老年代剩余的空間用盡之前，完成老年代空間的掃描及回收工作。否則如果在正常速度的比賽中失效，就會發生該錯誤

   • 在并發清理階段，用戶線程仍然在運行，必須預留出空間給用戶線程使用，會產生’浮動垃圾‘

   • 常規優化途徑如下：

     以更高的頻率執行后臺的回收線程，即提高CMS并發周期發生的頻率

     • 主要是調低CMSInitiatingOccupancyFraction的值

     • 但是不能太低，太低會導致過于頻繁的gc，會消耗更多的的cpu和停頓

     • landon

       需要先計算老年代常駐內存大小，如占用60%，那么這個閾值則可以設置為約70%，否則會比較頻繁gc

       可以考慮擔保機制，只要老年代預留剩余空間大于年輕代大小，比如新生代和老年代的比例是1 : 4，即新生代占用老年代的25%，那么這個閾值可以設置為70，即老年代還預留出來30%的空間

       注意如果浮動垃圾很多的話，也無法解決該問題，即cms并發回收期間，浮動垃圾越來越多，占用預留空間，多次的ygc的話，會有填滿預留空間的可能，雖然概率較低

       兩個條件綜合考慮，如果設置了閾值70，但是老年代常駐內存很大，甚至超過70，那么此時的建議要提高堆內存，增加老年代的大小或者減少新生代的大小

3. 針對promotion failed的優化

   • 這個是cms最為嚴重的’碎片問題‘，我們要盡量避免這個發生后引起的fgc

   • 所以優化這個問題，也可以描述為'如何解決碎片問題'

   • 常規優化途徑如下

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

     • 盡早執行cms gc，合理設置CMSInitiatingOccupancyFraction，會合并老生代中相鄰的free空間，可分配給較大的對象

     • 和上面一樣，也可以做一個老年代預留空間大于年輕代

     到了閾值后，就會觸發cms gc，但還是和上面說的，會產生浮動垃圾 + 碎片，還是會出現

     • 另外一個比較“挫”的辦法，是在每天凌晨訪問量低的時候，主動執行一下fgc，執行一下'碎片壓縮'

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

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

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

CMS實戰參數

1. 日志，主要是用來排查cms相關問題

   基礎參數：
   -Xloggc:gc_%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
   
   可選調試參數:
    -XX:+PrintGCApplicationStoppedTime
    -XX:+PrintTenuringDistribution
    -XX:+PrintPromotionFailure
    -XX:+PrintHeapAtGC
    -XX:PrintFLSStatistics=1
   

2. cms相關

   1. 物理機內存：16G
   2. 預估老年代常駐對象如Player 3000，一個Player平均2M，大約6G，所以老年代比如建議10G
   3. -Xms12G -Xmx12G
   4. 設置新生代2G，老年代10G
   5. 設置CMSInitiatingOccupancyFraction為70，則老年代剩余空間為3G，大于新生代大小
   6. 可選：-XX:+CMSScavengeBeforeRemark
   
   簡單算法：
   -XX:NewRatio=4，即新生代和老年代1:4
   然后設置CMSInitiatingOccupancyFraction為70，即老年代剩余空間稍大新生代
   但要保證這個70基本上要大于老年代常駐內存，否則可能會頻繁cms gc
   
   另外建議增加腳本，嘗試手動執行fgc，整理碎片
   如每天凌晨3點
   jstat -gccause pid >> cms.log
   jmap -histo pid >> cms.log
   jstat -gccause pid >> cms.log
   jmap -histo:live pid >> cms.log
   

3. metaspace

   設置 -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m
   注意如果設置的過小，則會引起fgc甚至metaspace oom
   

其他

1. cms如果出現ygc時間較長，可以考慮可能是老年代碎片過多，解決方案也是嘗試在業務低峰主動觸發fgc執行壓縮
2. TODO 了解cms的free list
3. TODO 學習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.lxweimin.com/p/78017c8b8e0f
   • 劉家財 https://liujiacai.net/blog/2019/01/09/java-gc-definitive-guide/
   • 畢玄 http://hellojava.info/?p=142
   • 占小狼 http://www.lxweimin.com/p/55670407fdb9
   • 江南白衣 http://calvin1978.blogcn.com/articles/jvmoption-7.html
   • 你假笨