深入理解CMS GC

深入理解CMS GC

背景

  1. 網(wǎng)上關(guān)于cms gc介紹和調(diào)優(yōu)的文章比較多，但大多沒(méi)有經(jīng)過(guò)驗(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ì)算出來(lái)的

    • 所以通常使用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，也無(wú)效，現(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"‘，不過(guò)暫停時(shí)間較短
    • 而jstat的這個(gè)fgc的計(jì)數(shù)器是說(shuō)的應(yīng)用暫停的次數(shù)
    • 注意這里所指的是'cms gc'引起的stw
    • 詳細(xì)可參考jstat顯示的full GC次數(shù)與CMS周期的關(guān)系

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

    • concurrent mode failure
    1. 在cms并發(fā)周期執(zhí)行期間，用戶(hù)的線程依然在運(yùn)行，如果這時(shí)候如果應(yīng)用線程向老年代請(qǐng)求分配的空間超過(guò)預(yù)留的空間，就會(huì)拋出該錯(cuò)誤 - 后臺(tái)線程的收集沒(méi)有趕上應(yīng)用線程的分配速度
2. 有時(shí)候“空間不足”是CMS GC時(shí)當(dāng)前的浮動(dòng)垃圾過(guò)多導(dǎo)致暫時(shí)性的空間不足，而浮動(dòng)垃圾就是cms執(zhí)行期間用戶(hù)線程申請(qǐng)的內(nèi)存空間
3. 這個(gè)錯(cuò)誤可能觸發(fā)兩種情況
 > cms的foreground模式（默認(rèn)的cms gc屬于background模式），這個(gè)模式是CMS自己的mark-sweep來(lái)做不并發(fā)的（串行的）old generation GC，不過(guò)會(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，但是往往性能甚至比f(wàn)gc更差
 > 對(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. 所以通常來(lái)說(shuō)不建議設(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ò)誤的，由于老年代空間的碎片化（或者，不太貼切的說(shuō)，由于晉升實(shí)際要占用的內(nèi)存超過(guò)了CMS收集器的判斷），CMS收集器無(wú)法晉升這些對(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ì)變得碎片化；碎片過(guò)多會(huì)影響大對(duì)象的分配，雖然老年代還有很大的剩余空間，但是沒(méi)有連續(xù)的空間來(lái)分配大對(duì)象
3. 如果在ParNew準(zhǔn)備收集時(shí)CMS說(shuō)晉升沒(méi)問(wèn)題，但ParNew已經(jīng)開(kāi)始收集之后確實(shí)遇到了晉升失敗的情況
4. promotion failed是說(shuō)，擔(dān)保機(jī)制確定老年代是否有足夠的空間容納新來(lái)的對(duì)象，如果擔(dān)保機(jī)制說(shuō)有，但是真正分配的時(shí)候發(fā)現(xiàn)由于碎片導(dǎo)致找不到連續(xù)的空間而失??；而concurrent mode failure是指并發(fā)周期還沒(méi)執(zhí)行完，用戶(hù)線程就來(lái)請(qǐng)求比預(yù)留空間更大的空間了，即后臺(tái)線程的收集沒(méi)有趕上應(yīng)用線程的分配速度。
5. promotion failed觸發(fā)fgc，觸發(fā)模式同上，通常也是Serial Old GC
    • permgen (or the metaspace) fills up
    1. 對(duì)于Java8來(lái)說(shuō)，這個(gè)主要是在metaspace擴(kuò)容時(shí)觸發(fā)的
2. 如果老年代設(shè)置了 CMS，則 Metasapce 擴(kuò)容引起的 FGC 會(huì)轉(zhuǎn)變成一次 CMS
3. Java8中收集器默認(rèn)就會(huì)收集元空間中不再載入的類(lèi)

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

    • 通常這種情況是上面提到的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. 通過(guò)觀察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ā)收集，然后用戶(hù)線程申請(qǐng)內(nèi)存空間不足

  7. jvm有一個(gè)內(nèi)存擔(dān)保機(jī)制，是類(lèi)似于判斷'老年代最大的可用連續(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，則是碎片問(wèn)題

CMS優(yōu)化方向

  1. 原則

    • cms的的優(yōu)勢(shì)就是低延遲，但是如果出現(xiàn)了長(zhǎng)時(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ā)回收就開(kāi)始了。一個(gè)CMS后臺(tái)線程開(kāi)始掃描老年代空間，尋找無(wú)用的垃圾對(duì)象時(shí)，競(jìng)爭(zhēng)就開(kāi)始了。CMS收集器必須在老年代剩余的空間用盡之前，完成老年代空間的掃描及回收工作。否則如果在正常速度的比賽中失效，就會(huì)發(fā)生該錯(cuò)誤

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

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

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

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

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

      • landon

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

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

        注意如果浮動(dòng)垃圾很多的話，也無(wú)法解決該問(wèn)題，即cms并發(fā)回收期間，浮動(dòng)垃圾越來(lái)越多，占用預(yù)留空間，多次的ygc的話，會(huì)有填滿預(yù)留空間的可能，雖然概率較低

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

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

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

    • 所以?xún)?yōu)化這個(gè)問(wèn)題，也可以描述為'如何解決碎片問(wèn)題'

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

      • 增大堆內(nèi)存，增加老年代大小，但要注意不要超過(guò)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，但還是和上面說(shuō)的，會(huì)產(chǎn)生浮動(dòng)垃圾 + 碎片，還是會(huì)出現(xiàn)

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

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

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

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

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

  1. 日志，主要是用來(lái)排查cms相關(guān)問(wè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

簡(jiǎn)單算法：
-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è)置的過(guò)小，則會(huì)引起fgc甚至metaspace oom

其他

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

參考

  1. R大
  2. 滌生的博客
  3. 其他
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • System.gc整理 System.gc()源碼public static void gc() { Runtim...
    andersonoy閱讀 3,150評(píng)論 0贊 1
  • # 前言 在 深入淺出 JVM GC（2） 中，我們介紹了一些 GC 算法，GC 名詞，同時(shí)也留下了一個(gè)問(wèn)題，就...
    莫那一魯?shù)?/span>閱讀 1,207評(píng)論 1贊 4
  • 這篇文章是我之前翻閱了不少的書(shū)籍以及從網(wǎng)絡(luò)上收集的一些資料的整理，因此不免有一些不準(zhǔn)確的地方，同時(shí)不同JDK版本的...
    高廣超閱讀 16,062評(píng)論 3贊 83
  • 作者：一字馬胡 轉(zhuǎn)載標(biāo)志 【2017-11-12】 更新日志 日期更新內(nèi)容備注 2017-11-12新建文章初版 ...
    beneke閱讀 2,334評(píng)論 0贊 7
  • 聲明：原創(chuàng)文章，轉(zhuǎn)載請(qǐng)注明出處。http://www.itdecent.cn/u/e02df63eaa87 1、J...
    唐影若凡閱讀 1,349評(píng)論 0贊 6

友情鏈接更多精彩內(nèi)容