了解 CMSConcurrentMark-Sweep

了解CMS(Concurrent Mark-Sweep)垃圾回收器

1.總體介紹：

CMS(Concurrent Mark-Sweep)是以犧牲吞吐量為代價來獲得最短回收停頓時間的垃圾回收器。對於要求伺服器響應速度的應用上，這種垃圾回收器非常適合。在啟動JVM參數加上-XX:+UseConcMarkSweepGC ，這個參數表示對於老年代的回收採用CMS。CMS採用的基礎演算法是：標記—清除。

2.CMS過程：

初始標記(STW initial mark)

並發標記(Concurrent marking)

並發預清理(Concurrent precleaning)

重新標記(STW remark)

並發清理(Concurrent sweeping)

並發重置(Concurrent reset)

初始標記 ：在這個階段，需要虛擬機停頓正在執行的任務，官方的叫法STW(Stop The Word)。這個過程從垃圾回收的」根對象」開始，只掃描到能夠和」根對象」直接關聯的對象，並作標記。所以這個過程雖然暫停了整個JVM，但是很快就完成了。

並發標記 ：這個階段緊隨初始標記階段，在初始標記的基礎上繼續向下追溯標記。並發標記階段，應用程序的線程和並發標記的線程並發執行，所以用戶不會感受到停頓。

並發預清理 ：並發預清理階段仍然是並發的。在這個階段，虛擬機查找在執行並發標記階段新進入老年代的對象(可能會有一些對象從新生代晉陞到老年代， 或者有一些對象被分配到老年代)。通過重新掃描，減少下一個階段」重新標記」的工作，因為下一個階段會Stop The World。

重新標記 ：這個階段會暫停虛擬機，收集器線程掃描在CMS堆中剩餘的對象。掃描從」跟對象」開始向下追溯，並處理對象關聯。

並發清理 ：清理垃圾對象，這個階段收集器線程和應用程序線程並發執行。

並發重置 ：這個階段，重置CMS收集器的數據結構，等待下一次垃圾回收。

CSM執行過程：

3.CMS缺點

CMS回收器採用的基礎演算法是Mark-Sweep。所有CMS不會整理、壓縮堆空間。這樣就會有一個問題：經過CMS收集的堆會產生空間碎片。CMS不對堆空間整理壓縮節約了垃圾回收的停頓時間，但也帶來的堆空間的浪費。為了解決堆空間浪費問題，CMS回收器不再採用簡單的指針指向一塊可用堆空間來為下次對象分配使用。而是把一些未分配的空間匯總成一個列表，當JVM分配對象空間的時候，會搜索這個列表找到足夠大的空間來hold住這個對象。

需要更多的CPU資源。從上面的圖可以看到，為了讓應用程序不停頓，CMS線程和應用程序線程並發執行，這樣就需要有更多的CPU，單純靠線程切換是不靠譜的。並且，重新標記階段，為空保證STW快速完成，也要用到更多的甚至所有的CPU資源。當然，多核多CPU也是未來的趨勢！

CMS的另一個缺點是它需要更大的堆空間。因為CMS標記階段應用程序的線程還是在執行的，那麼就會有堆空間繼續分配的情況，為了保證在CMS回收完堆之前還有空間分配給正在運行的應用程序，必須預留一部分空間。也就是說，CMS不會在老年代滿的時候才開始收集。相反，它會嘗試更早的開始收集，已避免上面提到的情況：在回收完成之前，堆沒有足夠空間分配！默認當老年代使用68%的時候，CMS就開始行動了。 – XX:CMSInitiatingOccupancyFraction =n 來設置這個閥值。

總得來說，CMS回收器減少了回收的停頓時間，但是降低了堆空間的利用率。

4.啥時候用CMS

如果你的應用程序對停頓比較敏感，並且在應用程序運行的時候可以提供更大的內存和更多的CPU(也就是硬體牛逼)，那麼使用CMS來收集會給你帶來好處。還有，如果在JVM中，有相對較多存活時間較長的對象(老年代比較大)會更適合使用CMS。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！