摘要：原文出處這種垃圾收集器的官方名稱是。使用收集器的名稱。事件時(shí)長(zhǎng)記錄不同的類型回收期間垃圾收集器線程消耗事件調(diào)用操作系統(tǒng)活著等待系統(tǒng)事件消耗時(shí)間應(yīng)用停頓的時(shí)鐘時(shí)間。現(xiàn)在我們看一些一些任務(wù)的時(shí)間，垃圾收集器線程等待很長(zhǎng)時(shí)間。

原文出處：Concurrent Mark and Sweep

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

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

你在命令行通過如下圖所示的選項(xiàng)顯式指定這個(gè)收集器：

java -XX:+UseConcMarkSweepGC

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

就拿上面的GC算法來(lái)說(shuō)，讓我們看一下這種算法在實(shí)踐應(yīng)用當(dāng)中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事件開始的時(shí)間。

GC開始相對(duì)于JVM啟動(dòng)時(shí)間時(shí)間差。

區(qū)分Minor GC和Full GC的標(biāo)記。它表示是一個(gè)Minor GC。

收集原因。這個(gè)原因是，一次分配請(qǐng)求不適合在Young代的任何區(qū)域。

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

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

Young代的大小。

清除時(shí)間時(shí)長(zhǎng)

回收前后Heap區(qū)已使用大小。

Heap大小

Young代垃圾收集器標(biāo)記復(fù)制存活對(duì)象消耗時(shí)長(zhǎng)。包括，CMS收集器通訊時(shí)長(zhǎng)，對(duì)象升遷進(jìn)入Old代的時(shí)間，垃圾循環(huán)收集結(jié)束后的最終清除時(shí)間。

GC事件時(shí)長(zhǎng)-記錄不同的類型：
1.user-回收期間垃圾收集器線程消耗CPU事件
2.sys-調(diào)用操作系統(tǒng)活著等待系統(tǒng)事件消耗時(shí)間
3.real-應(yīng)用停頓的時(shí)鐘時(shí)間。Parallel GC時(shí)間接近（user+sys）單個(gè)垃圾收集器使用線程分開運(yùn)行時(shí)間總和。應(yīng)當(dāng) 注意， 因?yàn)橐恍┗顒?dòng)不被允許并行執(zhí)行，它通常超過合計(jì)時(shí)間。

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

Full GC

現(xiàn)在，你已經(jīng)習(xí)慣閱讀GC日志,這章介紹日志中另外一種形式的垃圾收集器。下圖中冗長(zhǎng)的輸出囊括了Old代主要垃圾收集器不同階段。我們不一次性地簡(jiǎn)單概括日志事件，相反，我們一條一條分析日志的不同階段。回顧一下，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]

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

階段1：初始化標(biāo)記。CMS期間兩次“”stop-the-world“”中的一次在這個(gè)階段發(fā)生。這個(gè)階段的目標(biāo)是標(biāo)記Old代所有的GC root可達(dá)對(duì)象，Young代中被引用的對(duì)象。Old代獨(dú)立回收這點(diǎn)很重要。

GC時(shí)間開始時(shí)間，包含時(shí)鐘時(shí)間和距離相對(duì)于JVM啟用的時(shí)間，簡(jiǎn)單略過貫穿以后的階段的類似的概念。

回收階段-這時(shí)的“”Initial Mark“”收集GC Roots對(duì)象。

Old代當(dāng)前已使用空間。

Old代大小。

heap區(qū)大小。

這次過程持續(xù)時(shí)間-user,sys,real的實(shí)際時(shí)間。

階段2: 并發(fā)標(biāo)記。這個(gè)階段期間，垃圾回收器掃描整個(gè)Old代，標(biāo)記所有存活對(duì)象，從上一個(gè)“”Initial Mark“”階段發(fā)現(xiàn)的所有Root對(duì)象。“”Concurrent Mark“”階段，正如名稱所示，和應(yīng)用線程并發(fā)運(yùn)行，不會(huì)停頓應(yīng)用線程。由于標(biāo)記期間應(yīng)用改變對(duì)象引用，Old代不是所有存活對(duì)象也許被標(biāo)記。

上面的示意圖說(shuō)明，標(biāo)記線程并發(fā)地移除沒有被“”Current obj“”指針引用的對(duì)象。

收集階段，“”Concurrent Mark“”-掃描整個(gè)Old區(qū),標(biāo)記所有存活對(duì)象。

階段持續(xù)時(shí)間，展示相對(duì)鐘墻時(shí)間的消耗時(shí)間。

“”Times“”部分，對(duì)于并發(fā)階段中計(jì)算并發(fā)標(biāo)記開始時(shí)間更有意義，不只是包含并發(fā)標(biāo)記完成工作的時(shí)間。

階段3:并發(fā)清除 。這是一個(gè)并發(fā)階段，和應(yīng)用線程并行執(zhí)行,不會(huì)引起線程停頓。雖然上一個(gè)階段和應(yīng)用線程并發(fā)執(zhí)行，但是一些引用被改變。無(wú)論何時(shí)發(fā)生，JVM標(biāo)記heap區(qū)（“”Card“”）包含突變成“”dirty“”的對(duì)象（了解 Card Marking）。

在預(yù)清理階段，這些“”臟“”對(duì)象被占用，被他們引用的對(duì)象依然被標(biāo)記，當(dāng)它釋放后，Card被清除。

補(bǔ)充一點(diǎn)，一些必要的最后標(biāo)記的準(zhǔn)備工作被執(zhí)行。

收集階段-“Concurrent Preclean”階段-前一個(gè)標(biāo)記階段期間引用發(fā)生變化。

相對(duì)于鐘墻時(shí)間的消耗時(shí)間。

“”Times“”部分，對(duì)于并發(fā)階段中計(jì)算并發(fā)標(biāo)記開始時(shí)間更有意義，不只是包含并發(fā)標(biāo)記完成工作的時(shí)間。

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

“”并發(fā)預(yù)清理“”階段。

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

“”Times“”部分，對(duì)于并發(fā)階段中計(jì)算并發(fā)標(biāo)記開始時(shí)間更有意義，不只是包含并發(fā)標(biāo)記完成工作的時(shí)間。

這個(gè)階段會(huì)明顯影響到即將帶來(lái)的“”stop-the-world“”階段，有很多的配置選項(xiàng)和失敗模式。

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

通常當(dāng)年輕代為了盡可能多清除幾次緊接著發(fā)生的幾次“”stop-the-world“”而CM去執(zhí)行最終標(biāo)記。

這次事件看起來(lái)比之前的階段復(fù)雜得多：

GC 事件開始時(shí)間，包括時(shí)鐘時(shí)間和相對(duì)于JVM啟動(dòng)的時(shí)間

收集階段-“”““Final Remark”，標(biāo)記Old代所有的存活對(duì)象，包括并發(fā)標(biāo)記階段新建的，應(yīng)用改變的對(duì)象。

當(dāng)前已使用的空間和Young代的空間大小

“掃描”-應(yīng)用線程停頓期間標(biāo)記所有的存活對(duì)象。這種情況下并發(fā)掃描花費(fèi)0.0085125 s。

第一個(gè)子階段處理弱引用d的時(shí)間戳。

第二個(gè)子階段卸載無(wú)用class對(duì)象的時(shí)間戳。

最后一個(gè)子階段清除擁有class級(jí)別元數(shù)據(jù)的符號(hào)和字符串表，和其內(nèi)部的String。這個(gè)階段通常包括時(shí)鐘時(shí)間。

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

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

階段持續(xù)時(shí)長(zhǎng)。

階段持續(xù)時(shí)長(zhǎng)，user, system and real 的時(shí)間。

最后標(biāo)記階段過后，Old代所有存活對(duì)象被標(biāo)記，垃圾收集器去準(zhǔn)備去回收Old代中的無(wú)用對(duì)象。

階段6：并發(fā)清除。和應(yīng)用線程并發(fā)執(zhí)行，不需要“”stop-the-world“”。這個(gè)階段的目的清除無(wú)用對(duì)象，以備以后使用。

清除沒有標(biāo)記和無(wú)用的對(duì)象以回收空間。

展示運(yùn)行時(shí)間和墻鐘時(shí)間。

time 部分對(duì)并發(fā)階段有重大意義，正如并發(fā)標(biāo)記開始時(shí)間，包含但不限于并發(fā)標(biāo)記的工作。

階段7: 并發(fā)重置。并發(fā)執(zhí)行階段，重置CMS算法內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，為下一個(gè)周期做準(zhǔn)備。

并發(fā)階段，重置CMS算法內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，為下次循環(huán)做準(zhǔn)備。
2.展示運(yùn)行時(shí)間和墻鐘時(shí)間。

time 部分對(duì)并發(fā)階段有重大意義，正如并發(fā)標(biāo)記開始時(shí)間，包含但不限于并發(fā)標(biāo)記的工作。

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