摘要：原文出處這種垃圾收集器的官方名稱是。使用收集器的名稱。事件時長記錄不同的類型回收期間垃圾收集器線程消耗事件調用操作系統活著等待系統事件消耗時間應用停頓的時鐘時間。現在我們看一些一些任務的時間，垃圾收集器線程等待很長時間。

原文出處：Concurrent Mark and Sweep

這種垃圾收集器的官方名稱是“Mostly Concurrent Mark and Sweep Garbage Collector”。它在Yong代使用
并行，“stop-the-world”、標記復制算法，在Old代使用并發標記清除算法。

設計這種算法目的是，在回收Old代的時候去避免長時間停頓。他的實現分為兩方面。第一，它不清楚Old代，而是使用空閑列表管理回收空間。第二，它在標記清除期間的大部分工作和應用程序并發執行。這意味著執行這些階段，收集器不會刻意停頓應用線程。應當注意的是，它依然和應用程序搶占CPU時間片。默認的，這種算法的使用的線程數等于你的機器物理核心數的?。

你在命令行通過如下圖所示的選項顯式指定這個收集器：

java -XX:+UseConcMarkSweepGC

如果你有意向的話，在多核機器上使用這樣的組合是個不錯的選擇。應用用戶可以明顯感知個別GC階段停頓時長減少帶來的變化，快速響應給他們帶來更好用戶體驗。大多時候，GC消耗至少幾個CPU資源，而不是執行你的應用代碼。在單核應用中CMS性能通常低于Parallel。

就拿上面的GC算法來說，讓我們看一下這種算法在實踐應用當中Minor GC和Major GC階段如何工作：

2015-05-26T16:23:07.219-0200: 64.322: [GC (Allocation Failure) 64.322: [ParNew: 613404K->68068K(613440K), 0.1020465 secs] 10885349K->10880154K(12514816K), 0.1021309 secs] [Times: user=0.78 sys=0.01, real=0.11 secs]
2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Minor GC

從日志看出，GC事件第一步操作是Minor GC清理Young代。我們分析一下面示意圖中收集器是如何工作的：

GC事件開始的時間。

GC開始相對于JVM啟動時間時間差。

區分Minor GC和Full GC的標記。它表示是一個Minor GC。

收集原因。這個原因是，一次分配請求不適合在Young代的任何區域。

使用收集器的名稱。它表示，在Young代中使用的是并行，標記復制，“stop-the-world”算法。被設計在Old代工作的并發標記清除籌集起的組合。

Young代回收前后的已使用空間。

Young代的大小。

清除時間時長

回收前后Heap區已使用大小。

Heap大小

Young代垃圾收集器標記復制存活對象消耗時長。包括，CMS收集器通訊時長，對象升遷進入Old代的時間，垃圾循環收集結束后的最終清除時間。

GC事件時長-記錄不同的類型：
1.user-回收期間垃圾收集器線程消耗CPU事件
2.sys-調用操作系統活著等待系統事件消耗時間
3.real-應用停頓的時鐘時間。Parallel GC時間接近（user+sys）單個垃圾收集器使用線程分開運行時間總和。應當 注意， 因為一些活動不被允許并行執行，它通常超過合計時間。

通過上面我們可以看出，回收前heap區已使用空間10,885,349K，Young代已使用空間613,404K。這意味著Old代可用空間是10,271,945K。回收后，Young代減少545,336K但是heap區僅僅減少5,195K。這意味著540,141K是Yong代升遷到Old代的對象的大小。

Full GC

現在，你已經習慣閱讀GC日志,這章介紹日志中另外一種形式的垃圾收集器。下圖中冗長的輸出囊括了Old代主要垃圾收集器不同階段。我們不一次性地簡單概括日志事件，相反，我們一條一條分析日志的不同階段。回顧一下，CMS收集器類似于下圖：

2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

但要記住，實際上Old代并發收集期間的任何時候，Young代都會發生Minor GC。在這種情況下，可以看到上面的Major GC和Minor GC 事件交替執行。

階段1：初始化標記。CMS期間兩次“”stop-the-world“”中的一次在這個階段發生。這個階段的目標是標記Old代所有的GC root可達對象，Young代中被引用的對象。Old代獨立回收這點很重要。

GC時間開始時間，包含時鐘時間和距離相對于JVM啟用的時間，簡單略過貫穿以后的階段的類似的概念。

回收階段-這時的“”Initial Mark“”收集GC Roots對象。

Old代當前已使用空間。

Old代大小。

heap區大小。

這次過程持續時間-user,sys,real的實際時間。

階段2: 并發標記。這個階段期間，垃圾回收器掃描整個Old代，標記所有存活對象，從上一個“”Initial Mark“”階段發現的所有Root對象。“”Concurrent Mark“”階段，正如名稱所示，和應用線程并發運行，不會停頓應用線程。由于標記期間應用改變對象引用，Old代不是所有存活對象也許被標記。

上面的示意圖說明，標記線程并發地移除沒有被“”Current obj“”指針引用的對象。

收集階段，“”Concurrent Mark“”-掃描整個Old區,標記所有存活對象。

階段持續時間，展示相對鐘墻時間的消耗時間。

“”Times“”部分，對于并發階段中計算并發標記開始時間更有意義，不只是包含并發標記完成工作的時間。

階段3:并發清除 。這是一個并發階段，和應用線程并行執行,不會引起線程停頓。雖然上一個階段和應用線程并發執行，但是一些引用被改變。無論何時發生，JVM標記heap區（“”Card“”）包含突變成“”dirty“”的對象（了解 Card Marking）。

在預清理階段，這些“”臟“”對象被占用，被他們引用的對象依然被標記，當它釋放后，Card被清除。

補充一點，一些必要的最后標記的準備工作被執行。

收集階段-“Concurrent Preclean”階段-前一個標記階段期間引用發生變化。

相對于鐘墻時間的消耗時間。

“”Times“”部分，對于并發階段中計算并發標記開始時間更有意義，不只是包含并發標記完成工作的時間。

階段4：并發預處理。又一個并發的，不需要“”stop-the-world“”的階段嘗試去盡可能多消除最終標記由于停頓的影響。由于他做循環做著同樣的事情直到遇到一個中斷式條件（例如迭代次數，有用工作完成的數量，鐘墻時間消耗，等等），因此這個階段的準確好事取決于這些因素。

“”并發預清理“”階段。

整個階段消耗時間，暫時耗費時間和多帶帶的鐘墻時間。有趣的一點是，user time大大小于時鐘時間。通常我們看到時鐘時間小于user time，意味著一些工作并行執行，因此時鐘時間小于cpu 時間。現在我們看一些一些任務：0.167s 的cpu 時間，垃圾收集器線程等待很長時間。本質上，他們盡量去避開STW階段。默認的，這各階段持續5s。

“”Times“”部分，對于并發階段中計算并發標記開始時間更有意義，不只是包含并發標記完成工作的時間。

這個階段會明顯影響到即將帶來的“”stop-the-world“”階段，有很多的配置選項和失敗模式。

階段5：最終標記。這是第二個也是最后一次事件發生期間“”stop-the-world“”的階段。“”stop-the-world“”的目的是最后標記Old代中所有的存活對象。由于預處理階段是并發的，它們也許趕不上應用線程改變的速度。“”stop-the-world“”需要完成這些考驗。

通常當年輕代為了盡可能多清除幾次緊接著發生的幾次“”stop-the-world“”而CM去執行最終標記。

這次事件看起來比之前的階段復雜得多：

GC 事件開始時間，包括時鐘時間和相對于JVM啟動的時間

收集階段-“”““Final Remark”，標記Old代所有的存活對象，包括并發標記階段新建的，應用改變的對象。

當前已使用的空間和Young代的空間大小

“掃描”-應用線程停頓期間標記所有的存活對象。這種情況下并發掃描花費0.0085125 s。

第一個子階段處理弱引用d的時間戳。

第二個子階段卸載無用class對象的時間戳。

最后一個子階段清除擁有class級別元數據的符號和字符串表，和其內部的String。這個階段通常包括時鐘時間。

這個階段過后Old代已使用和Old代空間大小。

階段過后heap已使用和heap空間大小。

階段持續時長。

階段持續時長，user, system and real 的時間。

最后標記階段過后，Old代所有存活對象被標記，垃圾收集器去準備去回收Old代中的無用對象。

階段6：并發清除。和應用線程并發執行，不需要“”stop-the-world“”。這個階段的目的清除無用對象，以備以后使用。

清除沒有標記和無用的對象以回收空間。

展示運行時間和墻鐘時間。

time 部分對并發階段有重大意義，正如并發標記開始時間，包含但不限于并發標記的工作。

階段7: 并發重置。并發執行階段，重置CMS算法內部的數據結構，為下一個周期做準備。

并發階段，重置CMS算法內部的數據結構，為下次循環做準備。
2.展示運行時間和墻鐘時間。

time 部分對并發階段有重大意義，正如并發標記開始時間，包含但不限于并發標記的工作。

總而言之，CMS收集器通過并發線程卸載大量工作而不用去停頓應用線程在減少階段運行時間上做了偉大的工作。然而，他也存在一些缺點，最值得的注意的是造成Old代碎片化，階段持續時間在某些情況下缺乏可預見性，尤其在大heap區。