原文鏈接：http://hellojava.info/?p=142

為什么不建議

之前曾經有講過在heap size<=3G的情況下完全不要考慮CMS GC，在heap size>3G的情況下也優先選擇ParallelOldGC，而不是CMS GC，只有在暫停時間無法接受的情況下才考慮CMS GC（不過當然，一般來說在heap size>8G后基本上都得選擇CMS GC，否則那暫停時間是相當嚇人的，除非是完全不在乎響應時間的應用），這其實也是官方的建議（每年JavaOne的GC Tuning基本都會這么講）。

為什么給了一個這么“武斷”的建議呢，不是我對CMS GC有什么不爽，相反CMS GC一直是我很熱愛的一種GC實現，之所以建議在<=3G的情況下完全不要考慮CMS GC，主要出于以下幾點考慮： 1、觸發比率不好設置 在JDK 1.6的版本中CMS GC的觸發比率默認為old使用到92%時，假設3G的heap size，那么意味著舊生代大概就在1.5G--2.5G左右的大小，假設是92%觸發，那么意味著這個時候舊生代只剩120M--200M的大小，通常這點大小很有可能是會導致不夠裝下新生代晉生的對象，因此需要調整觸發比率，但由于heap size比較小，這個時候到底設置為多少是挺難設置的，例如我看過heap size只有1.5G，old才800m的情況下，還使用CMS GC的，觸發比率還是80%，這種情況下就悲催了，意味著舊生代只要使用到640m就觸發CMS GC，只要應用里稍微把一些東西cache了就會造成頻繁的CMS GC。 CMS GC是一個大部分時間不暫停應用的GC，就造成了需要給CMS GC留出一定的時間（因為大部分時間不暫停應用，這也意味著整個CMS GC過程的完成時間是會比ParallelOldGC時的一次Full GC長的），以便它在進行回收時內存別分配滿了，而heap size本來就小的情況下，留多了嘛容易造成頻繁的CMS GC，留少了嘛會造成CMS GC還在進行時內存就不夠用了，而在不夠用的情況下CMS GC會退化為采用Serial Full GC來完成回收動作，這個時候就慢的離譜了。 2、搶占CPU CMS GC大部分時間和應用是并發的，所以會搶占應用的CPU，通常在CMS GC較頻繁的情況下，可以很明顯看到一個CPU會消耗的非常厲害。 3、YGC速度變慢 由于CMS GC的實現原理，導致對象從新生代晉升到舊生代時，尋找哪里能放下的這個步驟比ParallelOld GC是慢一些的，因此就導致了YGC速度會有一定程度的下降。 4、碎片問題帶來的嚴重后果 CMS GC最麻煩的問題在于碎片問題，同樣是由于實現原理造成的，CMS GC為了確保盡可能少的暫停應用，取消了在回收對象所占的內存空間后Compact的過程，因此就造成了在回收對象后整個old區會形成各種各樣的不連續空間，自然也就產生了很多的碎片，碎片會造成什么后果呢，會造成例如明明舊生代還有4G的空余空間，而新生代就算全部是存活的1.5g對象，也還是會出現promotion failed的現象，而在出現這個現象的情況下CMS GC多數會采用Serial Full GC來解決問題。 碎片問題最麻煩的是你完全不知道它什么時候會出現，因此有可能會造成某天高峰期的時候應用突然來了個長暫停，于是就悲催了，對于很多采用了類似心跳來維持長連接或狀態的分布式場景而言這都是災難，這也是Azul的Zing JVM相比而言最大的優勢（可實現不暫停的情況下完成Compact，解決碎片問題）。 目前對于這樣的現象我們唯一的解決辦法都是選擇在低峰期主動觸發Full GC（執行jmap -histo:live [pid]）來避免碎片問題，但這顯然是一個很齷蹉的辦法（因為同樣會對心跳或維持狀態的分布式場景造成影響）。 5、CMS GC的”不穩定“性 如果關注過我在之前的blog記錄的碰到的各種Java問題的文章（可在此查看），就會發現碰到過很多各種CMS GC的詭異問題，盡管里面碰到的大部分BUG目前均已在新版本的JVM修復，但誰也不知道是不是還有問題，畢竟CMS GC的實現是非常復雜的（因為要在盡可能降低應用暫停時間的情況下還保持對象引用的掃描不要出問題），而ParallelOldGC的實現相對是更簡單很多的，因此穩定性相對高多了。
而且另外一個不太好的消息是JVM Team的精力都已轉向G1GC和其他的一些方面，CMS GC的投入已經很少了（這也正常，畢竟G1GC確實是方向）。

在大內存的情況下，CMS GC絕對是不二的選擇，而且Java在面對內存越來越大的情況下，必須采用這種大部分時候不暫停應用的方式，否則Java以后就非常悲催了，G1GC在CMS GC的基礎上，有了很多的進步，尤其是會做部分的Compact，但仍然碎片問題還是存在的，哎…