网易视频云：HBase GC的前生今世 – 演进篇 _内存

现在，网易视频云与大家分享一下HBase GC的前生今世–演进篇。
最原始的HBase CMS GC相当严重，经常会因为碎片过多导致，严重影响业务的读写请求。幸运的是，HBase并没有止步不前，很多优化方案相继被提出并贡献给社区，本文要介绍的就是几个比较重要的核心优化，分别是针对所作的两个优化：-Local和 Chunk Pool 以及针对所作的优化：方案。在详细介绍这几个优化之前有必要简单介绍一下HBase GC优化的目标，很直观的，第一是要尽量避免长时间的Full GC，避免影响用户的读写请求；第二是尽量减少GC时间，提高读写性能；接着分别来看HBase针对GC所做的各种优化：
GC优化一－-Local
HBase数据写入操作实际上并没有直接将数据写入磁盘，而是先写入内存并顺序写入HLog，之后等待满足某个特定条件后统一将内存中的数据刷新到磁盘。一个通常由多个组成，每张通常包含一张表的多个列族，而每个列族对应一块内存区域，这块内存被称为，很显然，一个会由多个构成，一个会由多个构成。
最原始的HBase版本存在很严重的内存碎片，经常会导致长时间的Full GC，其中最核心的问题就出在这里。因为一个由多个构成，不同的数据写入到对应，在JVM看来其实是混合在一起写入Heap的，此时假如上对应的所有执行落盘操作，就会出现下图所示场景：

文章插图
为了优化这种内存碎片可能导致的Full GC，HBase借鉴了Arena 内存管理方式，它通过顺序化分配内存、内存数据分块等特性使得内存碎片更加粗粒度，有效改善Full GC情况；
具体实现原理如下：
1. 每个会实例化出来一个
2. 会申请一个2M大小的Chunk数组和一个Chunk偏移量，初始值为0
3. 当一个值插入后，会首先通过.()取得data数组，并将data数组复制到Chunk数组中，之后再将Chunk偏移量往前移动data.
4. 如果当前Chunk满了之后，再调用new byte[ 2 * 1024 * 1024]申请一个新的Chunk
很显然，通过申请2M大小的Chunk可以使得内存碎片更加粗粒度，官方在优化前后通过设置-xx: = 1 统计了老生代的Max Chunk Size分别随时间的变化曲线，如下图所示：

文章插图

文章插图
由上图可以看出，未优化前碎片会大量出现导致频繁的Full GC，优化后虽然依然会产生大量碎片，但是最大碎片大小一直会维持在1e＋08左右，极大地降低了Full GC频率。
GC优化二–Chunk Pool
然而一旦一个Chunk写满之后，系统就会重新申请一个新的Chunk，这些Chunk大部分都会经过多次YGC之后晋升到老生代，如果某个Chunk再没有被引用就会被JVM垃圾回收。很显然，不断申请新的Chunk会导致YGC频率不断增多，YGC频率增加必然会导致晋升到老生代的Chunk增多，进而增加CMS GC发生的频率。如果这些Chunk能够被循环利用，系统就不需要申请新的Chunk，这样就会使得YGC频率降低，晋升到老生代的Chunk就会减少，CMS GC发生的频率就会降低。这就是 Chunk Pool的核心思想，具体实现如下：
1. 系统会创建一个Chunk Pool来管理所有未被引用的，这些chunk就不会再被JVM当作垃圾回收掉了
2. 如果一个Chunk没有再被引用，将其放入Chunk Pool
3. 如果当前Chunk Pool已经达到了容量最大值，就不会再接纳新的Chunk
4. 如果需要申请新的Chunk来存储，首先从Chunk Pool中获取，如果能够获取得到就重复利用，如果为null就重新申请一个新的Chunk