### CMS將可達性分析分解成兩個階段 a.僅掃描與根節點直接關聯的對象; b.繼續向下掃描完所有對象。因此，標記階段也被拆分成兩個階段，即初始標記和并發標記。 #### CMS完整的收集過程如下： 1. 初始標記（init-mark）：僅掃描與根節點直接關聯的對象并標記，這個階段必須STW, 由于跟節點數量有限，所以這個過程非常短暫。 2. 并發標記（concurrent-marking）：與用戶線程并發標記。這個階段在初始標記的基礎上繼續向下追溯標記。在并發標記階段，用戶線程和標記線程并發執行，所以用戶不會感受到停頓。 3. 并發預清理（concurrent-precleaning）：與用戶線程并發進行。在并發標記階段一些對象的引用已經發生了變化，precleaning會發現這些引用關系的改變，并將存活的對象標記。舉個例子：如果線程A有一個指向對象X的引用，并將該引用傳遞給了線程B，CMS需要記錄下線程B持有了對象X，即使線程A已經不存在了。precleaning是為了減少下一階段“重新標記”的工作量，因為remark階段會STW。 4. 重新標記（remark）： remark階段會STW。如果應用正在并發運行且在不斷地改變對象引用，CMS則不能準確地確定某個對象是否存活。所以CMS會在remark階段STW，從而獲取所有引用關系的改變。 5. 并發清理（concurrent-sweeping）：清理垃圾對象，這個階段GC線程和用戶線程并發執行。 6. 并發重置（concurrent-reset）：重置CMS收集器的數據結構，做好下一次執行GC任務的準備工作。  由上述CMS執行過程可以得出： * **CMS兩次STW的時間都是比較短暫的，兩個最耗時的時間是并發標記和并發清理，但是這兩個階段都是可以和用戶線程并發執行的**。 * 由于在并發標記和并發清理階段用戶線程并沒有中斷，所在CMS回收過程中，還應該保證用戶線程有足夠的內存可用，**CMS并不能讓其他老年代垃圾回收器那樣等到內存幾乎被填滿之后再進行垃圾回收**。而是當堆內存使用率達到一定的閾值的時候就開始進行回收，以確保應用程序在CMS執行垃圾回收期間依然有足夠的內存空間支持運行。 * 如果**CMS垃圾回收執行失敗（CMS運行期間預留的內存無法滿足程序需要，會出現Concurrent Mode Failure），這是JVM將要啟動后備方案，臨時啟動Serial Old收集器重新進行老年代垃圾回收**。