老年代 CMS gc回收算法 對hbase的影響
參考鏈接： 深入研究java gc https://blog.51cto.com/12445535/2372976
CMS失敗模式（CMS Failure Mode）
1、上文提到在正常的情況下CMS整個流程的暫停時間都是很短的，一般也就在10ms～100ms左右。
2、然而這與線上的情況並不相符，線上集群在讀寫壓力很大的情況下，經常會出現長時間的卡頓，有些卡頓甚至長達幾分鐘，導致很嚴重的讀寫阻塞，甚至會造成Region Server和Zookeeper之間Session超時，使得Region Server異常離線。
3、實際上，CMS並不是很完美，它會在兩種場景下產生嚴重的Full GC（Concurrent Failure(並發失敗)，Promotion Failure （促銷失敗）），接下來分別進行介紹。
Concurrent Failure(並發失敗)
為什麽會出現並發失敗？
1、假如現在系統正在執行CMS回收老生代空間，在回收的過程中新生代來了一批對象進來，不巧的是，老生代已經沒有空間再容納這些對象了。
2、這種場景下，CMS回收器會停止繼續工作，系統進入 ’stop-the-world’ 模式，並且回收算法會退化為單線程復制算法，重新分配整個堆內存的存活對象到S0中，釋放所有其他空間。很顯然，整個過程會非常’漫長’。
解決方法：
JVM提供了參數-XX:CMSInitiatingOccupancyFraction=N來設置CMS回收的時機，其中N表示當前老生代已使用內存占新生代總內存的比例，該值默認為68，可以將該值修改的更小使得回收更早進行。
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=70 表示 老年代堆空間的使用率
Promotion Failure （促銷失敗）
1、假設此時設置XX:CMSInitiatingOccupancyFraction＝60，但是在已使用內存還沒有達到總內存60%的時候，已經沒有空間容納從新生代遷移的對象了。
2、oh，my god！怎麽會這樣？罪魁禍首就是內存碎片，上文中提到CMS算法會產生大量碎片，當碎片容量積累到一定大小之後就會造成上面的場景。
4、JVM也提供了參數 -XX: UseCMSCompactAtFullCollection來減少碎片的產生，這個參數表示會在每次CMS回收垃圾之後執行一次碎片整理，很顯然，這個參數會對性能有比較大的影響，對HBase這種對延遲敏感的業務來說並不是一個完美解決方案。
//-XX: UseCMSCompactAtFullCollection 此參數，在cdh中默認沒有
1、在實際線上環境中，很少出現Concurrent Failure模式的Full GC，大多數Full GC場景都是Promotion Failure。
2、我們線上集群也會每隔半個月左右就會因為Promotion Failure觸發一次Full GC。
3、為了更好地理解CMS策略下內存碎片是如何觸發Promotion Failure，接下來我們做一個簡單的實驗：
4、JVM提供了參數 -XX:PrintFLSStatistics=1來打印每次GC前後內存碎片的統計信息，統計信息主要包括3個維度：Free Space、Max Chunk Size和Num Chunks，
5、其中Free Space表示老生代當前空閑的總內存容量，
6、Max Chunk Size表示老生代中最大的內存碎片所占的內存容量大小，
7、Num Chunks表示老生代中總的內存碎片數。
8、我們在測試環境集群（共4臺Region Server）將這個參數設置為1，然後使用一個客戶端YCSB執行Read-And-Write操作，分別統計日誌中Free Space和Max Chunk Size兩個指標隨時間的變化情況。
小結：
可以知道：CMS GC會不斷產生內存碎片，當碎片小到一定程度之後就會基本維持不變，如果此時業務寫入一些單條數據量很大的KeyValue，就有可能觸發Promotion Failure模式Full GC。
參考鏈接：
http://hbasefly.com/2016/05/21/hbase-gc-1/
老年代 CMS gc回收算法 對hbase的影響