PS：之前做項目的時候，需要做個復雜的查詢，大量的查詢總是導致hbase集群奔潰，最後定位到時full GC的原因。

以下轉自《Hbase不睡覺書》------------------------

可怕的Full GC

隨著內存的加大， 有一個不容忽視的問題也出現了， 那就是JVM的堆內存越大， Full GC的時間越久。 Full GC有時候可以達到好幾分鐘。在Full GC的時候JVM會停止響應任何的請求， 整個JVM的世界就像是停止了一樣， 所以這種暫停又被叫做Stop-The-World（ STW） 。當ZooKeeper像往常一樣通過心跳來檢測RegionServer節點是否存
活的時候， 發現已經很久沒有接收到來自RegionServer的回應， 會直接把這個RegionServer標記為已經宕機。 等到這臺RegionServer終於結束了Full GC後， 去查看ZooKeeper的時候會發現原來自己已經“ 被宕機” 了， 為了防止腦裂問題的發生， 它會自己停止自己。 這種場景稱為RegionServer自殺， 它還有另一個美麗的名字叫朱麗葉暫停， 而且這問
題還挺常見的， 早期一直困擾著HBase開發人員。 所以我們一定要設定好GC回收策略， 避免長時間的Full GC發生， 或者是盡量減小Full GC的時間。

GC回收策略優化
由於數據都是在RegionServer裏面的， Master只是做一些管理操作， 所以一般內存問題都出在RegionServer上。 接下來主要用RegionServer來講解參數配置， 如果你想調整Master的內存參數， 只需要把HBASE_REGIONSERVER_OPTS換成HBASE_MASTER_OPTS就行了。JVM提供了4種GC回收器：

• 串行回收器（ SerialGC） 。
• 並行回收器（ ParallelGC） ， 主要針對年輕帶進行優化（ JDK 8默認策略） 。
• 並發回收器（ ConcMarkSweepGC， 簡稱CMS） ， 主要針對年老帶進行優化。
• G1GC回收器， 主要針對大內存（ 32GB以上才叫大內存） 進行優化。

具體實現請參考《Hbase不睡覺書》第八章第一節。

《Hbase不睡覺書》下載 http://www.aboutyun.com/thread-25255-1-1.html

其實spark也有這個問題。

可怕的Full GC （轉自Hbase不睡覺書）