CMS收集器
1. CMS(Concurrent Mark Sweep)收集器是一種獲取最短回收停頓時(shí)間為目標(biāo)的收集器
2. CMS收集器是一種基于"標(biāo)記-清除"算法實(shí)現(xiàn)的收集器，整個(gè)過程分為四步
? ?初始標(biāo)記(CMS initial mark).該過程分為兩步：
? ?標(biāo)記GC Roots可達(dá)的老年代對(duì)象
? ?遍歷新生代對(duì)象石景，標(biāo)記可達(dá)的老年代對(duì)象
? ? 并發(fā)標(biāo)記(CMS concurrent mark)
? ? 重新標(biāo)記 (CMS remark)
? ? 并發(fā)清除 (CMS concurrent sweep)
3. 初始標(biāo)記劈猿、重新標(biāo)記著兩個(gè)步驟任然需要"Stop The World"，初始標(biāo)記僅僅只是標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對(duì)象潮孽，速度很快揪荣，并發(fā)標(biāo)記就是進(jìn)行GC Roots Tracing 的過程，而重新標(biāo)記階段則是為了修正并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)品變動(dòng)的那一部分對(duì)象的標(biāo)記記錄往史。這個(gè)階段的停頓時(shí)間一般會(huì)比初始標(biāo)記階段稍長一些仗颈。，但遠(yuǎn)比并發(fā)標(biāo)記的時(shí)間短怠堪。
4. 由于整個(gè)過程耗時(shí)最長的并發(fā)標(biāo)記和并發(fā)清除都可以和用戶線程一起工作揽乱，所以從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的粟矿。
5. CMS是一款優(yōu)秀的收集器，它的主要優(yōu)點(diǎn)在于：并發(fā)收集损拢、低停頓陌粹。
CMS 收集器的缺點(diǎn)
1.? CMS收集器對(duì)CPU非常敏感。其實(shí)面向并發(fā)設(shè)計(jì)的程序都對(duì)CPU比較敏感福压，在并發(fā)階段掏秩，雖然不會(huì)導(dǎo)致用戶線程停頓，但是會(huì)因?yàn)檎加昧艘徊糠志€程(或者說CPU資源)而導(dǎo)致應(yīng)用程序變慢荆姆，總吞吐量降低蒙幻。CMS默認(rèn)啟動(dòng)的回收線程數(shù)是(CPU數(shù)量+3)/4,也就是當(dāng)CPU在4個(gè)以上時(shí)，并發(fā)回收時(shí)胆筒，垃圾收集線程不少于25%的CPU資源邮破，并且隨著CPU數(shù)量的增加而下降诈豌。但是當(dāng)CPU數(shù)量不足4個(gè)時(shí)，CMS對(duì)用戶程序的影響就可能變的很大抒和。如果CPU負(fù)載本來就很大矫渔，還要分出一半的運(yùn)行能力去執(zhí)行收集器線程，就可能導(dǎo)致用戶程序的執(zhí)行能力下降50%
2. CMS收集器無法處理浮動(dòng)垃圾摧莽∶硗荩可能出現(xiàn)"Concurrent Mode Failure"失敗而導(dǎo)致另一次Full GC。由于CMS并發(fā)清理階段用戶線程還在運(yùn)行著镊辕，伴隨著程序的運(yùn)行自然就還會(huì)有新的垃圾不斷產(chǎn)生油够，這一部分產(chǎn)生的垃圾，CMS無法在當(dāng)次收集中處理掉他們征懈，只要留待下一次GC再進(jìn)行處理石咬。這一部分產(chǎn)生的垃圾成為"浮動(dòng)垃圾"。也是由于在垃圾收集階段用戶線程還要繼續(xù)運(yùn)行受裹，那也就還需要預(yù)留足夠的內(nèi)存空間給用戶線程使用碌补。因此CMS收集器不能像其他收集器那樣，等到老年代被填滿后再進(jìn)行垃圾回收棉饶。需要預(yù)留一部分空間供并發(fā)收集時(shí)的程序運(yùn)行使用厦章。
3.? 由于CMS采用"標(biāo)記-清理"算法實(shí)現(xiàn)，所以當(dāng)垃圾收集后照藻，會(huì)產(chǎn)生大量的內(nèi)存碎片袜啃。空間碎片過多幸缕，當(dāng)程序運(yùn)行需要分配大對(duì)象時(shí)群发，由于找不到連續(xù)的內(nèi)存空間，而不得不提前觸發(fā)一次Full GC.CMS采用了-XX:+UseCMSCompactAtFullCollection開關(guān)參數(shù)发乔，用于在CMS收集器頂不住要進(jìn)行Full GC時(shí)開啟內(nèi)存碎片的合并整理過程熟妓。內(nèi)存碎片的整理是無法并發(fā)執(zhí)行的，空間碎片問題沒有了栏尚，但是隨之而來的停頓時(shí)間變長了起愈。因此，虛擬機(jī)設(shè)計(jì)者還提供了一個(gè)參數(shù)：-XX:CMSFullGCsBeforeCompaction來進(jìn)行設(shè)置執(zhí)行多少次不壓縮的Full GC后進(jìn)行一次帶壓縮的(默認(rèn)是0.標(biāo)識(shí)每次進(jìn)入Full GC后都會(huì)帶有一次內(nèi)存壓縮)
什么時(shí)候使用CMS收集器
如果引用程序?qū)νｎD比較敏感译仗，并在在應(yīng)用程序運(yùn)行時(shí)可以提供更大的內(nèi)存和更多的CPU(硬件相當(dāng)牛逼)抬虽，那么使用CMS收集器會(huì)給我們帶來很多好處。還有就是如果JVM中纵菌，有相對(duì)較多存貨時(shí)間較長的對(duì)象(老年代比較大)會(huì)更適合使用CMS
CMS的理念
CMS垃圾回收器意在通過并發(fā)的方式適度減少吞吐量以達(dá)到減少用戶線程停頓時(shí)間的目標(biāo)阐污。
CMS的問題
a.問題1：無法處理浮動(dòng)垃圾；
b.問題2：并發(fā)回收引起的內(nèi)存空間不足咱圆，由于垃圾收集和用戶線程是并發(fā)執(zhí)行的笛辟，因此CMS收集器不能像其他收集器那樣幾乎填滿了再進(jìn)行收集功氨，需要預(yù)留一些空間用來保存用戶新創(chuàng)建的對(duì)象。
c.問題3：空間碎片隘膘。由于CMS老年代使用標(biāo)記-清除回收策略疑故，因此會(huì)有內(nèi)存碎片問題。當(dāng)碎片過多時(shí)弯菊，將會(huì)給大對(duì)象分配帶來麻煩纵势，往往會(huì)出現(xiàn)老年代還有很多空間但就已經(jīng)不能保存對(duì)象了，不得不提前觸發(fā)一次Full GC管钳。
問題4：對(duì)處理器資源非常敏感钦铁。在并發(fā)階段時(shí)，會(huì)占用一部分線程（或者說處理器的計(jì)算能力）而導(dǎo)致應(yīng)用程序變慢才漆，降低總吞吐量牛曹。CMS默認(rèn)的回收線程數(shù)是（處理器核心數(shù)+3）/4，所以當(dāng)處理器的核心數(shù)小于四個(gè)時(shí)醇滥，會(huì)很影響吞吐量黎比。
問題:5：不支持大內(nèi)存
CMS問題的處理方法
a.針對(duì)問題2，采用預(yù)留空間給浮動(dòng)垃圾進(jìn)行存儲(chǔ)鸳玩。在JDK1.5之前老年帶使用了68%空間后就會(huì)激活CMS收集阅虫，到了JDK6 CMS收集器的啟動(dòng)閥值就已經(jīng)默認(rèn)提升到92%。如果實(shí)際應(yīng)用中可以適當(dāng)調(diào)整參數(shù)-XX:CMSInitiatingOccu-pancyFraction 的值來提高CMS的觸發(fā)百分比不跟，降低內(nèi)存回收頻率獲得更好的性能颓帝。但是如果預(yù)留空間不足，（小概率事件）窝革，會(huì)作出以下處理：首先购城，CMS垃圾回收?qǐng)?bào)錯(cuò)(Concurrent Model Failure) 并發(fā)失敗虐译；然后啟動(dòng)后備預(yù)案：凍結(jié)用戶線程的執(zhí)行瘪板，臨時(shí)啟用Serial Old收集器來重新進(jìn)行老年代的垃圾收集，此時(shí)處理時(shí)間就會(huì)變得特別長漆诽。
b.針對(duì)問題3篷帅，CMS收集器提供了-XX:UseCMSCompactAtFullCollection開關(guān)參數(shù)，用于在CMS收集器不得不進(jìn)行Full GC時(shí)開啟內(nèi)存碎片的合并整理過程拴泌，內(nèi)存整理的過程是無法并發(fā)的，空間碎片問題沒有了惊橱，但停頓時(shí)間不得不變長蚪腐。-XX:CMSFullGCsBeforeCompaction參數(shù)可以配置有多少次Full GC會(huì)堆內(nèi)存碎片進(jìn)行整理。
6）采用ParNew + CMS組合税朴，避免系統(tǒng)產(chǎn)生FGC的方法
1.加大JVM內(nèi)存
2.加大Young的比例
3.提高Y-O的年齡
4.提高S區(qū)比例
5.避免代碼內(nèi)存泄漏
參考
https://blog.csdn.net/Waiting_Mr_Liu/article/details/110631303
周志明《深入理解Java虛擬機(jī)》
