CMS的缺點(diǎn)：

1.浮動(dòng)垃圾：由于CMS并發(fā)清理階段用戶線程還在運(yùn)行著，伴隨程序運(yùn)行自然會(huì)有新垃圾產(chǎn)生，這部分垃圾得標(biāo)記過程之后，所以CMS無法在當(dāng)收集中處理掉他們，只好留待下一次GC清理掉，這一部分垃圾稱為浮動(dòng)垃圾。在jdk1.5默認(rèn)設(shè)置下，CMS收集器當(dāng)老年代使用了68%的空間就會(huì)被激活，可以通過-XX:CMSInitialOccupancyFraction的值來提高觸發(fā)百分比，在jdk1.6中CMS啟動(dòng)閾值提升到了92%，要是CMS運(yùn)行期間預(yù)留的內(nèi)存無法滿足程序的需要，就會(huì)出現(xiàn)”Concurrent Mode Failure“,然后降級(jí)臨時(shí)啟用Serial Old收集器進(jìn)行老年代的垃圾收集，這樣停頓時(shí)間就很長了，所以-XX:CMSInitialOccupancyFraction設(shè)置太高容易導(dǎo)致大量”Concurrent Mode Failure“。

2.有空間碎片：CMS是一款基于“標(biāo)記-清除”算法實(shí)現(xiàn)的，所以會(huì)產(chǎn)生空間碎片。為了解決這個(gè)問題，CMS提供了-XX:UseCMSCompactAtFullCollection開發(fā)參數(shù)用于開啟內(nèi)存碎片的合并整理，由于內(nèi)存整理是無法并行的，所以停頓時(shí)間會(huì)變長。還有-XX:CMSFullGCBeforeCompaction，這個(gè)參數(shù)用于設(shè)置多少次不壓縮Full GC后，跟著來一次帶壓縮的(默認(rèn)為0)。

3.對(duì)CPU資源敏感，CMS默認(rèn)啟動(dòng)的回收線程數(shù)是（cpu數(shù)量+3）/4。所以CPU數(shù)量少會(huì)導(dǎo)致用戶程序執(zhí)行速度降低較多。