先看：
深入研究java gc https://blog.51cto.com/12445535/2372976
老年代 CMS gc回收算法 对hbase的影响 https://blog.51cto.com/12445535/2373206
1、最原始的HBase CMS GC相当严重，经常会因为碎片过多导致Promotion Failure，严重影响业务的读写请求。
2、分别是针对Memstore所作的两个优化：Thread-Local Allocation Buffer和MemStore Chunk Pool
3、以及针对BlockCache所作的优化：BucketCache方案。
4、在详细介绍这几个优化之前有必要简单介绍一下HBase GC优化的目标，很直观的，
5、第一是要尽量避免长时间的Full GC，避免影响用户的读写请求；
6、第二是尽量减少GC时间，提高读写性能；
7、接着分别来看HBase针对GC所做的各种优化：
MemStore GC优化一 － Thread-Local Allocation Buffer
回顾hbase数据写流程
1、HBase数据写入操作实际上并没有直接将数据写入磁盘，
2、而是先写入内存并顺序写入HLog，
3、之后等待满足某个特定条件后统一将内存中的数据刷新到磁盘。
4、一个RegionServer通常由多个Region组成，每张Region通常包含一张表的多个列族，而每个列族对应一块内存区域，这块内存被称为MemStore，
5、很显然，一个RegionServer会由多个Region构成，一个Region会由多个MemStore构成。
老版本hbase中：
1、最原始的HBase版本存在很严重的内存碎片，经常会导致长时间的Full GC，其中最核心的问题就出在MemStore这里。
2、因为一个RegionServer由多个Region构成，不同Region的数据写入到对应Memstore，
3、在JVM看来其实是混合在一起写入Heap（堆内存）的
为了优化这种内存碎片可能导致的Full GC，HBase借鉴了Arena Allocation内存管理方式，它通过顺序化分配内存、内存数据分块等特性使得内存碎片更加粗粒度，有效改善Full GC情况；
具体实现原理如下：
- 每个MemStore会实例化出来一个MemStoreLAB
- MemStoreLAB会申请一个2M大小的Chunk数组和一个Chunk偏移量，初始值为0
- 当一个KeyValue值插入MemStore后，MemStoreLAB会首先通过KeyValue.getBuffer()取得data数组，并将data数组复制到Chunk数组中，之后再将Chunk偏移量往前移动data.length
- 如果当前Chunk满了之后，再调用new byte[ 2 1024 1024]申请一个新的Chunk
提示：
很显然，通过申请2M大小的Chunk可以使得内存碎片更加粗粒度，官方在优化前后通过设置 -xx:PrintFLSStatistics = 1
未优化前碎片会大量出现导致频繁的Full GC，优化后虽然依然会产生大量碎片，但是最大碎片大小一直会维持在1e＋08左右，极大地降低了Full GC频率。
MemStore GC优化二 – MemStore Chunk Pool
MemStore Chunk Pool的核心思想为：
1、如果这些Chunk能够被循环利用，系统就不需要申请新的Chunk，这样就会使得YGC频率降低，晋升到老生代的Chunk就会减少，CMS GC发生的频率就会降低。
为什么Chunk不能被循环利用呢？
1、一旦一个Chunk写满之后，系统就会重新申请一个新的Chunk，
2、这些Chunk大部分都会经过多次YGC之后晋升到老生代，如果某个Chunk再没有被引用就会被JVM垃圾回收。
3、很显然，不断申请新的Chunk会导致YGC频率不断增多，YGC频率增加必然会导致晋升到老生代的Chunk增多，进而增加CMS GC发生的频率。
具体实现如下：
- 系统会创建一个Chunk Pool来管理所有未被引用的chunks，这些chunk就不会再被JVM当作垃圾回收掉了
- 如果一个Chunk没有再被引用，将其放入Chunk Pool
- 如果当前Chunk Pool已经达到了容量最大值，就不会再接纳新的Chunk
- 如果需要申请新的Chunk来存储KeyValue，首先从Chunk Pool中获取，如果能够获取得到就重复利用，如果为null就重新申请一个新的Chunk
官方针对该优化也进行了简单的测试，使用jstat -gcutil对优化前后的JVM GC情况进行了统计，具体的测试条件和测试结果如下所示：
测试条件：
HBase版本：0.94
JVM参数：-Xms4G -Xmx4G -Xmn2G
单条数据大小：Row size=50 bytes, Value size=1024 bytes
实验方法：50 concurrent theads per client, insert 10,000,000 rows
//cdh中参数为：
根据 MSLAB 分配方式分配的块区大小
hbase.hregion.memstore.mslab.chunksize = 2M
MemStoreChunkPool&MSLAB提升HBASE GC性能 https://blog.csdn.net/map_lixiupeng/article/details/40914567
BlockCache优化－BucketCache方案
1、BucketCache。这种方案还是采用“将小碎片整理为大碎片”的思路，
2、由程序在初始化的时候就申请了很多大小为2M的Bucket，数据Block的Get/Cache动作只是对这片空间的访问/覆写，CMS碎片会自然大大降低。
1、其中heap模式表示将数据存储在JVM堆内存，
2、offheap模式表示将数据Block存储到操作系统内存，
3、file模式表示将数据Block存储到类似于SSD的外部高速缓存上；
//很显然，offheap模式和file模式根本没有将数据Block存在JVM堆内存，所以几乎不会出现Full GC，而heap模式即使数据存储在JVM堆内存，也会因为内存由程序独立管理大大降低内存碎片。
从结果可以看出，BucketCache大大减少了碎片的产生，而且YGC和FGC时间也极大地得到了改善。
参考链接：
http://hbasefly.com/2016/05/29/hbase-gc-2/
原文地址：https://blog.51cto.com/12445535/2373223