如何理解GC知識點(diǎn)CMS

如何理解GC知識點(diǎn)CMS，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

今天準(zhǔn)備將之前沒有細(xì)講的部分進(jìn)行補(bǔ)充，首先要提到的就是垃圾收集器。

基礎(chǔ)的回收方式有三種：清除、壓縮、復(fù)制，衍生出來的垃圾收集器有：

Serial 收集器

新生代收集器，使用停止復(fù)制算法，使用一個線程進(jìn)行 GC ，串行，其它工作線程暫停。

使用-XX:+UseSerialGC開關(guān)來控制使用Serial + Serial Old模式運(yùn)行進(jìn)行內(nèi)存回收（這也是虛擬機(jī)在 Client 模式下運(yùn)行的默認(rèn)值）。

ParNew 收集器

新生代收集器，使用停止復(fù)制算法，Serial 收集器的多線程版，用多個線程進(jìn)行 GC ，并行，其它工作線程暫停，關(guān)注縮短垃圾收集時間。

使用-XX:+UseParNewGC開關(guān)來控制使用ParNew + Serial Old收集器組合收集內(nèi)存；使用-XX:ParallelGCThreads來設(shè)置執(zhí)行內(nèi)存回收的線程數(shù)。

Parallel Scavenge 收集器

新生代收集器，使用停止復(fù)制算法，關(guān)注 CPU 吞吐量，即運(yùn)行用戶代碼的時間/總時間，比如：JVM 運(yùn)行 100 分鐘，其中運(yùn)行用戶代碼 99 分鐘，垃 圾收集 1 分鐘，則吞吐量是 99% ，這種收集器能最高效率的利用 CPU ，適合運(yùn)行后臺運(yùn)算（其他關(guān)注縮短垃圾收集時間的收集器，如 CMS ，等待時間很少，所以適 合用戶交互，提高用戶體驗(yàn)）。

使用-XX:+UseParallelGC開關(guān)控制使用Parallel Scavenge + Serial Old收集器組合回收垃圾（這也是在 Server 模式下的默認(rèn)值）；使用-XX:GCTimeRatio來設(shè)置用戶執(zhí)行時間占總時間的比例，默認(rèn) 99 ，即 1% 的時間用來進(jìn)行垃圾回收。使用-XX:MaxGCPauseMillis設(shè)置 GC 的最大停頓時間（這個參數(shù)只對 Parallel Scavenge 有效），用開關(guān)參數(shù)-XX:+UseAdaptiveSizePolicy可以進(jìn)行動態(tài)控制，如自動調(diào)整 Eden / Survivor 比例，老年代對象年齡，新生代大小等，這個參數(shù)在 ParNew 下沒有。

Serial Old 收集器

老年代收集器，單線程收集器，串行，使用標(biāo)記-整理算法，使用單線程進(jìn)行GC，其它工作線程暫停（注意：在老年代中進(jìn)行標(biāo)記-整理算法清理，也需要暫停其它線程），在JDK1.5之前，Serial Old 收集器與 ParallelScavenge 搭配使用。 >整理的方法是 Sweep （清除）和 Compact （壓縮），清除是將廢棄的對象干掉，只留幸存的對象，壓縮是移動對象，將空間填滿保證內(nèi)存分為2塊，一塊全是對象，一塊空閑），

Parallel Old 收集器

老年代收集器，多線程，并行，多線程機(jī)制與 Parallel Scavenge 差不錯，使用標(biāo)記-整理算法，在 Parallel Old 執(zhí)行時，仍然需要暫停其它工作線程。 >Parallel Old 收集器的整理，與 Serial Old 不同，這里的整理是Copy（復(fù)制）和Compact（壓縮），復(fù)制的意思就是將幸存的對象復(fù)制到預(yù)先準(zhǔn)備好的區(qū)域，而不是像Sweep（清除）那樣清除廢棄的對象。

Parallel Old 在多核計算中很有用。 Parallel Old 出現(xiàn)后（JDK 1.6），與 Parallel Scavenge 配合有很好的效果，充分體現(xiàn) Parallel Scavenge 收集器吞吐量優(yōu)先的效果。使用-XX:+UseParallelOldGC開關(guān)控制使用Parallel Scavenge + Parallel Old組合收集器進(jìn)行收集。

CMS

全稱 Concurrent Mark Sweep，老年代收集器，致力于獲取最短回收停頓時間（即縮短垃圾回收的時間），使用標(biāo)記-清除算法，多線程，優(yōu)點(diǎn)是并發(fā)收集（用戶線程可以和 GC 線程同時工作），停頓小。

使用-XX:+UseConcMarkSweepGC進(jìn)行ParNew + CMS + Serial Old進(jìn)行內(nèi)存回收，優(yōu)先使用ParNew + CMS（原因見后面），當(dāng)用戶線程內(nèi)存不足時，采用備用方案Serial Old收集。

如何開始

首先來看一下 CMS 是在什么情況下進(jìn)行 GC：

1. 首先 JVM 根據(jù)-XX:CMSInitiatingOccupancyFraction、-XX:+UseCMSInitiatingOccupancyOnly來決定什么時間開始垃圾收集。

2. 如果設(shè)置了-XX:+UseCMSInitiatingOccupancyOnly，那么只有當(dāng)老年代占用確實(shí)達(dá)到了-XX:CMSInitiatingOccupancyFraction參數(shù)所設(shè)定的比例時才會觸發(fā) CMS GC。

3. 如果沒有設(shè)置-XX:+UseCMSInitiatingOccupancyOnly，那么系統(tǒng)會根據(jù)統(tǒng)計數(shù)據(jù)自行決定什么時候觸發(fā) CMS GC。因此有時會遇到設(shè)置了 80% 比例才 CMS GC，但是 50% 時就已經(jīng)觸發(fā)了，就是因?yàn)檫@個參數(shù)沒有設(shè)置的原因。

具體執(zhí)行

CMS GC 的執(zhí)行過程，具體來說就是：

初始標(biāo)記(CMS-initial-mark)

該階段是 stop the world 階段，因此此階段標(biāo)記的對象只是從 root 集最直接可達(dá)的對象。

此階段會打印 1 條日志：CMS-initial-mark：961330K（1572864K），指標(biāo)記時，老年代的已用空間和總空間

并發(fā)標(biāo)記(CMS-concurrent-mark)

此階段是和應(yīng)用線程并發(fā)執(zhí)行的，所謂并發(fā)收集器指的就是這個，主要作用是標(biāo)記可達(dá)的對象，此階段不需要用戶線程停頓。

此階段會打印 2 條日志：CMS-concurrent-mark-start，CMS-concurrent-mark

預(yù)清理(CMS-concurrent-preclean)

此階段主要是進(jìn)行一些預(yù)清理，因?yàn)闃?biāo)記和應(yīng)用線程是并發(fā)執(zhí)行的，因此會有些對象的狀態(tài)在標(biāo)記后會改變，此階段正是解決這個問題。因?yàn)橹蟮?CMS-remark 階段也會 stop the world，為了使暫停的時間盡可能的小，也需要 preclean 階段先做一部分工作以節(jié)省時間。

此階段會打印 2 條日志：CMS-concurrent-preclean-start，CMS-concurrent-preclean

可控預(yù)清理(CMS-concurrent-abortable-preclean)

此階段的目的是使 CMS GC 更加可控一些，作用也是執(zhí)行一些預(yù)清理，以減少 CMS-remark 階段造成應(yīng)用暫停的時間。

此階段涉及幾個參數(shù)：

    -XX:CMSMaxAbortablePrecleanTime：當(dāng) abortable-preclean 階段執(zhí)行達(dá)到這個時間時才會結(jié)束。
    -XX:CMSScheduleRemarkEdenSizeThreshold（默認(rèn)2m）：控制 abortable-preclean 階段什么時候開始執(zhí)行，即當(dāng)年輕代使用達(dá)到此值時，才會開始 abortable-preclean 階段。
    -XX:CMSScheduleRemarkEdenPenetratio（默認(rèn)50%）：控制 abortable-preclean 階段什么時候結(jié)束執(zhí)行。

此階段會打印 3 條日志：CMS-concurrent-abortable-preclean-start，CMS-concurrent-abortable-preclean，CMS：abort preclean due to time XXX

重新標(biāo)記(CMS-remark)

此階段暫停應(yīng)用線程，停頓時間比并發(fā)標(biāo)記小得多，但比初始標(biāo)記稍長，因?yàn)闀λ袑ο筮M(jìn)行重新掃描并標(biāo)記。

此階段會打印以下日志：

1. YG occupancy：964861K（2403008K），指執(zhí)行時年輕代的情況。

2. CMS remark：961330K（1572864K），指執(zhí)行時老年代的情況。

3. 此外，還打印出了弱引用處理、類卸載等過程的耗時。

并發(fā)清除(CMS-concurrent-sweep)

此階段進(jìn)行并發(fā)的垃圾清理。

并發(fā)重設(shè)狀態(tài)等待下次CMS的觸發(fā)(CMS-concurrent-reset)

此階段是為下一次 CMS GC 重置相關(guān)數(shù)據(jù)結(jié)構(gòu)。

總結(jié)

CMS 的收集過程，概括一下就是：2 次標(biāo)記，2 次預(yù)清除，1 次重新標(biāo)記，1 次清除。

在CMS清理過程中，只有初始標(biāo)記和重新標(biāo)記需要短暫停頓用戶線程，并發(fā)標(biāo)記和并發(fā)清除都不需要暫停用戶線程，因此效率很高，很適合高交互的場合。

CMS也有缺點(diǎn)，它需要消耗額外的 CPU 和內(nèi)存資源。在 CPU 和內(nèi)存資源緊張，會加重系統(tǒng)負(fù)擔(dān)（CMS 默認(rèn)啟動線程數(shù)為( CPU數(shù)量 + 3 ) / 4 ）。

另外，在并發(fā)收集過程中，用戶線程仍然在運(yùn)行，仍然產(chǎn)生內(nèi)存垃圾，所以可能產(chǎn)生“浮動垃圾”（本次無法清理，只能下一次Full GC才清理）。因此在 GC 期間，需要預(yù)留足夠的內(nèi)存給用戶線程使用。

所以使用 CMS 的收集器并不是老年代滿了才觸發(fā) Full GC ，而是在使用了一大半（默認(rèn) 68% ，即 2/3 ，使用-XX:CMSInitiatingOccupancyFraction來設(shè)置）的時候就要進(jìn)行 Full GC。如果用戶線程消耗內(nèi)存不是特別大，可以適當(dāng)調(diào)高-XX:CMSInitiatingOccupancyFraction以降低 GC 次數(shù)，提高性能。如果預(yù)留的用戶線程內(nèi)存不夠，則會觸發(fā) Concurrent Mode Failure，此時，將觸發(fā)備用方案：使用 Serial Old 收集器進(jìn)行收集，但這樣停頓時間就長了，因此-XX:CMSInitiatingOccupancyFraction不宜設(shè)的過大。

還有，CMS 采用的是標(biāo)記-清除算法，會導(dǎo)致內(nèi)存碎片的產(chǎn)生，可以使用-XX：+UseCMSCompactAtFullCollection來設(shè)置是否在 Full GC 之后進(jìn)行碎片整理，用-XX：CMSFullGCsBeforeCompaction來設(shè)置在執(zhí)行多少次不壓縮的 Full GC 之后，來一次帶壓縮的 Full GC。

并發(fā)和并行

并發(fā)收集： >指用戶線程與GC線程同時執(zhí)行（不一定是并行，可能交替，但總體上是在同時執(zhí)行的），不需要停頓用戶線程（其實(shí)在 CMS 中用戶線程還是需要停頓的，只是非常短，GC 線程在另一個 CPU 上執(zhí)行）；

并行收集： >指多個 GC 線程并行工作，但此時用戶線程是暫停的；

所以，Serial 是串行的，Parallel 收集器是并行的，而 CMS 收集器是并發(fā)的。

看完上述內(nèi)容，你們掌握如何理解GC知識點(diǎn)CMS的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！