cms gc的設計文檔：http://labs.oracle.com/techrep/2000/abstract-88.html

 concurrent collection的周期一般包含以下步驟：

· 中斷所有application的線程運行；執(zhí)行initial mark；恢復所有application的線程運行；

· 執(zhí)行concurrent mark（使用一個處理器為并發(fā)工作提供服務）；

· 執(zhí)行concurrent pre-clean（并發(fā)預清理）（使用一個處理器為并發(fā)工作提供服務）；

· 中斷所有application的線程運行；執(zhí)行remark；恢復所有application的線程運行；

· 執(zhí)行concurrent sweep（使用一個處理器為并發(fā)工作提供服務）；

· 執(zhí)行concurrent reset（并發(fā)重置）（使用一個處理器為并發(fā)工作提供服務）；

     因此CMS會有兩個階段暫停，mark和remark

1.1 CMS的開銷

cms gc主要消耗的是處理器資源，他會和應用一起運行；如果想縮短暫停時間，即使在單核處理器下，也可以考慮cms，在單核模式下有incremental 模式，也能提供較好的rt。

并發(fā)的線程數(shù)在1<=K<=N/4(N表示核數(shù))

1.CMS的major gc會有兩個STW階段，一開始會有個STW,稱為初始標記階段（initial mark pause）

2.接著中間會有個并發(fā)標記的過程，Concurrent garbage collector thread會開始執(zhí)行，并占用本可為application提供服務的處理器資源（對于計算密集行的應用，會有一定比例的吞吐量下降，雖然沒有暫停）。在remark階段后，是concurrent sweep階段，用于回收那些已死亡的對象。在此階段，Concurrent garbage collector thread又將占用那些本可為application提供服務的處理器資源。在打掃完后，Concurrent collector將進入睡眠狀態(tài)，直到開始下一次的major collection。

3.后面是一個比較長的STW（remark pause）,使用多線程標記那些在并發(fā)標記之后變?yōu)椴豢蛇_的對象

1.2 CMS一些常見問題

A.為了避免Perm區(qū)滿引起的full gc，建議開啟CMS回收Perm區(qū)選項：
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

B.默認CMS是在tenured generation沾滿68%的時候開始進行CMS收集，如果你的年老代增長不是那么快，并且希望降低CMS次數(shù)的話，可以適當調高此值：
-XX:CMSInitiatingOccupancyFraction=80

C.遇到兩種fail引起full gc：Prommotion failed和Concurrent mode failed時：
Prommotion failed的日志輸出大概是這樣：

[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K(  166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]  這個問題的產生是由于救助空間不夠，從而向年老代轉移對象，年老代沒有足夠的空間來容納這些對象，導致一次full gc的產生。解決這個問題的辦法有兩種完全相反的傾向：增大救助空間、增大年老代或者去掉救助空間。

Concurrent mode failed的日志大概是這樣的

(concurrent mode failure): 1228795K->1228598K(1228800K), 7.6748280 secs] 1911483K->1681165K(1911488K), [CMS Perm : 225407K->225394K(262144K)], 7.6751800 secs]問題的產生原因是由于CMS回收年老代的速度太慢，導致年老代在CMS完成前就被沾滿，引起full gc，避免這個現(xiàn)象的產生就是調小-XX:CMSInitiatingOccupancyFraction參數(shù)的值，讓CMS更早更頻繁的觸發(fā)，降低年老代被沾滿的可能。

D.CMS是并發(fā)的mark和sweep，沒有壓縮，因此會有碎片，因為一些原因，CMS會退化為Full GC，full GC時用的算法是mark-sweep-compact，但compaction是可選的，不做的話碎片化會嚴重些但這次full GC的暫停時間會短些；這是個取舍；

1.3.回收時間過長而OOM

并發(fā)GC的時候，如果GC使用了98%的時間，但是只回收了2%的堆空間，就會發(fā)生OOM，這個策略是為了避免不斷的處于GC中，可以通過-XX:-UseGCOverheadLimit禁用這個策略

1.4.Incremental 模式

避免并發(fā)階段占用線程資源過多，過長，可以在young gc的時候，分階段的嘗試并發(fā)回收，對處理器資源較少的情況下比較有用

  通常，Concurrent collector在整個concurrent mark階段，僅用一個處理器為并發(fā)工作提供服務，并且不會自愿讓出占用的處理器。類似的，在concurrent sweep階段同樣僅使用一個處理器，而且也不會讓出占用的處理器。這時處理器會由于application與中斷時間的約束而負擔過重，這種情況在僅有一或兩個處理器的設備上尤為明顯。I-CMS模式可解決這個問題，它將并發(fā)階段分割成可執(zhí)行的小塊任務，這些任務則可被安排在兩次minor pause（次要中斷）之間執(zhí)行。

 I-CMS使用一種名為“duty cycle（職責循環(huán)）”的機制，來控制concurrent collector在自愿放棄處理器之前被允許運行的數(shù)量。duty cycle其實是兩次young generation收集過程中的時間比率，以表明concurrent collector允許運行的時間。I-CMS能夠根據(jù)application的行為自動計算duty cycle的時間比率（推薦這種方式），或通過命令為duty cycle設一個固定值。

6.CMS的日志

[GC [1 CMS-initial-mark: 13991K(20288K)] 14103K(22400K), 0.0023781 secs]
[GC [DefNew: 2112K->64K(2112K), 0.0837052 secs] 16103K->15476K(22400K), 0.0838519 secs]
...
[GC [DefNew: 2077K->63K(2112K), 0.0126205 secs] 17552K->15855K(22400K), 0.0127482 secs]
[CMS-concurrent-mark: 0.267/0.374 secs]
[GC [DefNew: 2111K->64K(2112K), 0.0190851 secs] 17903K->16154K(22400K), 0.0191903 secs]
[CMS-concurrent-preclean: 0.044/0.064 secs]
[GC [1 CMS-remark: 16090K(20288K)] 17242K(22400K), 0.0210460 secs]
[GC [DefNew: 2112K->63K(2112K), 0.0716116 secs] 18177K->17382K(22400K), 0.0718204 secs]
[GC [DefNew: 2111K->63K(2112K), 0.0830392 secs] 19363K->18757K(22400K), 0.0832943 secs]
...
[GC [DefNew: 2111K->0K(2112K), 0.0035190 secs] 17527K->15479K(22400K), 0.0036052 secs]
[CMS-concurrent-sweep: 0.291/0.662 secs]
[GC [DefNew: 2048K->0K(2112K), 0.0013347 secs] 17527K->15479K(27912K), 0.0014231 secs]
[CMS-concurrent-reset: 0.016/0.016 secs]
[GC [DefNew: 2048K->1K(2112K), 0.0013936 secs] 17527K->15479K(27912K), 0.0014814 secs]

CMS-initial-mark：表明concurrent collection cycle的啟動，CMS-concurrent-mark：表明concurrent marking phase的結束，CMS-concurrent-sweep：標記concurrent sweeping phase的結束。CMS-concurrent-preclean：表明之前沒有討論的precleaning phase。Precleaning，它是一項為標記階段CMS-remark提供的準備工作，而且能并發(fā)完成。最后階段由CMS-concurrent-reset來定義，它是下一次concurrent collection的準備過程。

 initial mark pause所用的時間相比minor collection pause來說通常很短。而concurrent phases的所用的時間（concurrent mark, concurrent precleaning, 和concurrent sweep）比起minor collection pause可能相對較長，但application不會在concurrent phases被中斷。remark pause則被application的特殊細節(jié)（比如，高頻度的修改對象便可使中斷增加），以及自最后一次進行minor collection的時間所影響（換言之，young generation中的對象越多就越可能使中斷增加）。