CMS(Concurrent Mark Sweep)收集器是一種以最短回收停頓時(shí)間為目標(biāo)的收集器丹拯。目前很大一部分的java應(yīng)用集中在互聯(lián)網(wǎng)站或者B/S系統(tǒng)的服務(wù)端上档玻，這類應(yīng)用尤其重視服務(wù)的響應(yīng)速度兼都，希望系統(tǒng)停頓時(shí)間最短，已給用戶帶來(lái)較好的體驗(yàn)。CMS收集器就非常符合這類應(yīng)用的需求后控。
從名字（包含 Mark Sweep）上就可以看出，CMS收集器是基于“標(biāo)記-清除”算法實(shí)現(xiàn)的空镜，整個(gè)過(guò)程分為4步包括：
1浩淘、初始標(biāo)記（CMS initial mark）
2捌朴、并發(fā)標(biāo)記（CMS concurrent mark）
3、重新標(biāo)記（CMS remark）
4张抄、并發(fā)清除（CMS concurrent sweep）
其中砂蔽，初始標(biāo)記、重新標(biāo)記這兩個(gè)步驟仍然需要“stop the word”署惯。初始標(biāo)記僅僅只是標(biāo)記一下GC roots能直接關(guān)聯(lián)到的對(duì)象左驾，速度很快，并發(fā)標(biāo)記階段就是進(jìn)行GC Roots Tracing的過(guò)程极谊，而重新標(biāo)記階段是為了修正并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄诡右，這個(gè)階段的停頓時(shí)間一般會(huì)比初始標(biāo)記階段稍長(zhǎng)，但遠(yuǎn)比并發(fā)標(biāo)記的時(shí)間短怀酷。由于整個(gè)過(guò)程耗時(shí)最長(zhǎng)的并發(fā)標(biāo)記和并發(fā)清除過(guò)程收集器線程都可以與用戶線程一起工作稻爬，所以，從整體上來(lái)說(shuō)蜕依，CMS收集器的內(nèi)存回收過(guò)程是與用戶線程一起并發(fā)執(zhí)行的桅锄。如下圖
CMS是一款優(yōu)秀的收集器，它的主要優(yōu)點(diǎn)是并發(fā)收集样眠、低停頓友瘤。但是還遠(yuǎn)達(dá)不到完美的成都，它的主要缺點(diǎn)如下：
1檐束、CMS收集器對(duì)資源非常敏感辫秧。總的來(lái)說(shuō)面向并發(fā)設(shè)計(jì)的程序都對(duì)CPU資源比較敏感被丧。在并發(fā)階段盟戏，他雖然不會(huì)導(dǎo)致應(yīng)用程序線程停頓，但是會(huì)因?yàn)檎加昧艘徊糠志€程（或說(shuō)CPU資源）而導(dǎo)致應(yīng)用程序變慢甥桂，總吞吐量降低柿究。
2、CMS收集器無(wú)法處理浮動(dòng)垃圾黄选，可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC產(chǎn)生蝇摸。由于CMS并發(fā)清理階段用戶線程還在運(yùn)行著，伴隨程序運(yùn)行自然就還會(huì)有新的垃圾不斷產(chǎn)生办陷，這部分垃圾出現(xiàn)在標(biāo)記過(guò)程之后貌夕，CMS無(wú)法在當(dāng)次收集中處理掉他們，只好留待下一次GC在清理民镜。這部分垃圾被稱為浮動(dòng)垃圾啡专。
3、CMS收集器是基于“標(biāo)記-清除”算法實(shí)現(xiàn)的收集器制圈，著意味著收集結(jié)束時(shí)會(huì)有大量空間碎片產(chǎn)生植旧∪杞遥空間碎片多的情況可能會(huì)出現(xiàn)還有很大的空間但是無(wú)法找到足夠大的連續(xù)空間來(lái)分配對(duì)象，不得不提前觸發(fā)一次Full GC病附。為了解決這個(gè)問(wèn)題CMS收集器會(huì)在頂不住了要進(jìn)行Full GC時(shí)開啟內(nèi)存碎片合并整理過(guò)程，此過(guò)程無(wú)法并發(fā)亥鬓，會(huì)導(dǎo)致停頓時(shí)間變長(zhǎng)完沪。
