一文讀懂 fgc之cms-實戰(zhàn)篇

1. 前言

線上應用運行過程中可能會出現(xiàn)內(nèi)存使用率較高，甚至達到95+仍然不觸發(fā)fgc的情況，存在內(nèi)存打滿風險，持續(xù)觸發(fā)fgc回收；或者內(nèi)存占用率較低時觸發(fā)了fgc，導致某些接口tp99，tp999上升，觸發(fā)下游系統(tǒng)以及自身系統(tǒng)頻繁告警。

2. java8場景下為什么要使用cms

在Java 8場景下，使用CMS（Concurrent Mark Sweep）收集器的原因主要基于以下幾點：

2.1 CMS收集器的設(shè)計特性

并發(fā)垃圾收集：CMS收集器使用并發(fā)線程跟蹤可達對象，以減少Major GC（即老年代垃圾收集）帶來的暫停時間。它允許應用程序線程和垃圾收集線程在Major GC期間并發(fā)運行，從而降低了應用程序的停頓時間。

分代收集：CMS收集器也是基于“代”的收集器，支持Minor GC和Major GC。Minor GC可以與正在進行的Major GC交叉進行，提高了垃圾收集的效率。

兩次主要停頓：CMS收集器在GC過程中會有兩次短暫的停頓：初始化標記（initial mark pause）和再標記（remark pause）。初始化標記停頓較短，用于標記從GC root能直接訪問到的對象；再標記停頓稍長，用于處理并發(fā)跟蹤階段中程序線程引用發(fā)生變化的對象。

浮動垃圾：由于并發(fā)GC期間對象狀態(tài)可能發(fā)生變化，因此會產(chǎn)生浮動垃圾（Floating Garbage）。浮動垃圾的數(shù)量取決于并發(fā)收集周期的持續(xù)時間和應用程序引用更新的頻率?？梢酝ㄟ^增大老年代空間來緩解浮動垃圾帶來的問題。

2.2 CMS收集器的適用場景

需要短暫停頓時間的應用：CMS收集器非常適合那些需要低停頓時間的應用程序，如大型數(shù)據(jù)應用和多處理器環(huán)境下的應用。在這些環(huán)境中，CMS收集器能夠充分利用多處理器的優(yōu)勢，通過并發(fā)執(zhí)行垃圾收集來降低應用程序的停頓時間。

偏好更短GC暫停時間的應用：對于那些能夠忍受GC分享處理器資源，但希望有更短GC暫停時間的應用來說，CMS收集器是一個很好的選擇。

2.3 注意事項

并發(fā)模式失敗：如果CMS收集器無法在老年代滿之前完成垃圾收集，或者老年代的可用空間無法滿足某次分配操作，那么會發(fā)生并發(fā)模式失敗（Concurrent Mode Failure），導致應用程序線程暫停并完成GC。
此時，可以通過調(diào)整CMS收集器的參數(shù)來避免并發(fā)模式失敗。

3. cms觸發(fā)的時機

這里我們僅介紹配置CMSInitiatingOccupancyFraction參數(shù)的場景（一般都會改這個參數(shù)的默認值）：如果大于閾值（默認92%，閾值參數(shù)為CMSInitiatingOccupancyFraction），則進行CMS GC。
那么這里說的閾值是什么呢？指的是老年代被使用的內(nèi)存空間的閾值。

一定注意，這里說的是老年代被使用的內(nèi)存空間，我們通過jvm監(jiān)控一般看到的都是整個堆內(nèi)存的占比，所以通過這個監(jiān)控看到的fgc數(shù)據(jù)可能與CMSInitiatingOccupancyFraction設(shè)定不一致。這里我們可以結(jié)合精細化的監(jiān)控來分析。

舉個例子，在8C16G的機器上，假設(shè)堆內(nèi)存為10000M，新生代為5000M，元空間為500M（元空間使用本地內(nèi)存（即操作系統(tǒng)的內(nèi)存），而不是堆內(nèi)存，因此它的大小不再受限于JVM的堆內(nèi)存設(shè)置。元空間主要用于存放類的元數(shù)據(jù)信息，包括類的名稱、成員變量、方法等信息）。那么老年代大概就是5000M，如果設(shè)置了-XX:CMSInitiatingOccupancyFraction=75。結(jié)合上文，觸發(fā)fgc的一種場景就是老年代占用達到3750M左右。

4. 如何根據(jù)運行情況調(diào)整fgc觸發(fā)的時機

這里我們僅介紹CMSInitiatingOccupancyFraction作用的場景。如果我們設(shè)定了-XX:CMSInitiatingOccupancyFraction=75，可以觀察一段時間線上應用的jvm監(jiān)控。執(zhí)行fgc時，如果堆內(nèi)存整體使用率較低，這時我們可以適當增大CMSInitiatingOccupancyFraction延遲fgc觸發(fā)的時機再觀察調(diào)整，比如先增加到80；如果堆內(nèi)存整體使用率較高，或使用率較高時仍不觸發(fā)fgc，那么就需要考慮減小CMSInitiatingOccupancyFraction以加快fgc觸發(fā)的時機，比如先調(diào)到70。

5. 一切的理論都要基于實踐進行驗證

大部分開發(fā)者可能在部署時很少關(guān)注jvm參數(shù)，或者關(guān)注的較少，大都其他地復制直接使用。但是線上運行場景繁雜，統(tǒng)一的參數(shù)并不能滿足所有的場景。這時我們就需要結(jié)合實際的監(jiān)控 + 理論來不斷的調(diào)整，直到應用達到最佳運行狀態(tài)。比如調(diào)整增大堆內(nèi)存以延緩gc，增大新生代以減少ygc從而提高tp999，調(diào)整CMSInitiatingOccupancyFraction適配。
我負責有個toC的大流量應用，在過年期間出現(xiàn)流量升高，tp999上升，部分擴容后只是短暫緩解了問題，考慮隨意擴容可能造成機器過度浪費，于是先降低限流值保障穩(wěn)定的同時尋求其他方案。觀察tp999上升的機器，可以發(fā)現(xiàn)jvm監(jiān)控數(shù)據(jù)都出現(xiàn)了多次的ygc，于是考慮用一個分組來實驗，調(diào)整新生代大小來降低ygc的頻率。實驗運行一段時后果然tp999穩(wěn)定了很多，于是逐步灰度到全量的機器，保障了線上接口的穩(wěn)定性。