GC一直是Java应用中讨论的一个热门话题，尤其在像HBase这样的大型在线存储系统中，大堆下(百GB)的GC停顿延迟产生的在线实时影响，成为内核和应用开发者的一大痛点。
过去的一年里，我们准备在Ali-HBase上突破这个被普遍认知的痛点，为此进行了深度分析及全面创新的工作，获得了一些比较好的效果。以蚂蚁风控场景为例，HBase的线上young GC时间从120ms减少到15ms，结合阿里巴巴JDK团队提供的利器——ZenGC，进一步在实验室压测环境做到了5ms。本文主要介绍我们过去在这方面的一些工作和技术思想。
背景
JVM的GC机制对开发者屏蔽了内存管理的细节，提高了开发效率。说起GC，很多人的第一反应可能是JVM长时间停顿或者FGC导致进程卡死不可服务的情况。但就HBase这样的大数据存储服务而言，JVM带来的GC挑战相当复杂和艰难。原因有三:
1、内存规模巨大。线上HBase进程多数为96G大堆，今年新机型已经上线部分160G以上的堆配置
2、对象状态复杂。HBase服务器内部会维护大量的读写cache，达到数十GB的规模。HBase以表格的形式提供有序的服务数据，数据以一定的结构组织起来，这些数据结构产生了过亿级别的对象和引用
3、young GC频率高。访问压力越大，young区的内存消耗越快，部分繁忙的集群可以达到每秒1~2次youngGC， 大的young区可以减少GC频率，但是会带来更大的young GC停顿，损害业务的实时性需求。
思路
1. HBase作为一个存储系统，使用了大量的内存作为写buffer和读cache，比如96G的大堆（4G young 92G old）下，写buffer 读cache会占用70%以上的内存(约70G），本身堆内的内存水位会控制在85%，而剩余的占用内存就只有在10G以内了。所以，如果我们能在应用层面自管理好这70G 的内存，那么对于JVM而言，百G大堆的GC压力就会等价于10G小堆的GC压力，并且未来面对更大的堆也不会恶化膨胀。 在这个解决思路下，我们线上的young GC时间获得了从120ms到15ms的优化效果。
2. 在一个高吞吐的数据密集型服务系统中，大量的临时对象被频繁创建与回收，如何能够针对性管理这些临时对象的分配与回收，AliJDK团队研发了一种新的基于租户的GC算法—ZenGC。集团HBase基于这个新的ZenGC算法进行改造，我们在实验室中压测的young GC时间从15ms减少到5ms，这是一个未曾期望的极致效果。
下面将逐一介绍Ali-HBase版本GC优化所使用的关键技术。
消灭一亿个对象：更快更省的CCSMap
目前HBase使用的存储模型是LSMTree模型，写入的数据会在内存中暂存到一定规模后再dump到磁盘上形成文件。
下面我们将其简称为写缓存。写缓存是可查询的，这就要求数据在内存中有序。为了提高并发读写效率，并达成数据有序且支持seek&scan的基本要求，SkipList是使用得比较广泛的数据结构。
我们以JDK自带的ConcurrentSkipListMap为例子进行分析，它有下面三个问题:
1. 内部对象繁多。每存储一个元素，平均需要4个对象(index node key value，平均层高为1)
2. 新插入的对象在young区，老对象在old区。当不断插入元素时，内部的引用关系会频繁发生变化，无论是ParNew算法的CardTable标记，还是G1算法的RSet标记，都有可能触发old区扫描。
3. 业务写入的KeyValue元素并不是规整长度的，当它晋升到old区时，可能产生大量的内存碎片。
问题1使得young区GC的对象扫描成本很高，young GC时晋升对象更多。问题2使得young GC时需要扫描的old区域会扩大。问题3使得内存碎片化导致的FGC概率升高。当写入的元素较小时，问题会变得更加严重。我们曾对线上的RegionServer进程进行统计，活跃Objects有1亿2千万之多！
分析完当前young GC的最大敌人后，一个大胆的想法就产生了，既然写缓存的分配，访问，销毁，回收都是由我们来管理的，如果让JVM“看不到”写缓存，我们自己来管理写缓存的生命周期，GC问题自然也就迎刃而解了。
说起让JVM“看不到”，可能很多人想到的是off-heap的解决方案，但是这对写缓存来说没那么简单，因为即使把KeyValue放到offheap，也无法避免问题1和问题2。而1和2也是young GC的最大困扰。
问题现在被转化成了：如何不使用JVM对象来构建一个有序的支持并发访问的Map。
当然我们也不能接受性能损失，因为写入Map的速度和HBase的写吞吐息息相关。
需求再次强化：如何不使用对象来构建一个有序的支持并发访问的Map，且不能有性能损失。
为了达成这个目标，我们设计了这样一个数据结构：
-- 它使用连续的内存(堆内or堆外)，我们通过代码控制内部结构而不是依赖于JVM的对象机制
-- 在逻辑上也是一个SkipList，支持无锁的并发写入和查询
-- 控制指针和数据都存放在连续内存中
我们以JDK自带的ConcurrentSkipListMap为例子进行分析，它有下面三个问题:
1. 内部对象繁多。每存储一个元素，平均需要4个对象(index node key value，平均层高为1)
2. 新插入的对象在young区，老对象在old区。当不断插入元素时，内部的引用关系会频繁发生变化，无论是ParNew算法的CardTable标记，还是G1算法的RSet标记，都有可能触发old区扫描。
3. 业务写入的KeyValue元素并不是规整长度的，当它晋升到old区时，可能产生大量的内存碎片。
问题1使得young区GC的对象扫描成本很高，young GC时晋升对象更多。问题2使得young GC时需要扫描的old区域会扩大。问题3使得内存碎片化导致的FGC概率升高。当写入的元素较小时，问题会变得更加严重。我们曾对线上的RegionServer进程进行统计，活跃Objects有1亿2千万之多！
分析完当前young GC的最大敌人后，一个大胆的想法就产生了，既然写缓存的分配，访问，销毁，回收都是由我们来管理的，如果让JVM“看不到”写缓存，我们自己来管理写缓存的生命周期，GC问题自然也就迎刃而解了。
说起让JVM“看不到”，可能很多人想到的是off-heap的解决方案，但是这对写缓存来说没那么简单，因为即使把KeyValue放到offheap，也无法避免问题1和问题2。而1和2也是young GC的最大困扰。
问题现在被转化成了：如何不使用JVM对象来构建一个有序的支持并发访问的Map。
当然我们也不能接受性能损失，因为写入Map的速度和HBase的写吞吐息息相关。
需求再次强化：如何不使用对象来构建一个有序的支持并发访问的Map，且不能有性能损失。
为了达成这个目标，我们设计了这样一个数据结构：
-- 它使用连续的内存(堆内or堆外)，我们通过代码控制内部结构而不是依赖于JVM的对象机制
-- 在逻辑上也是一个SkipList，支持无锁的并发写入和查询
-- 控制指针和数据都存放在连续内存中
追求极致：ZenGC
经过以上两个大的优化之后，蚂蚁风控生产环境的young GC时间已经缩减到15ms。由于ParNew CMS算法在这个尺度上再做优化已经很困难了，我们转而投向ZenGC的怀抱。ZenGC在G1算法的基础上做了深度改进，内存自管理的大堆HBase和ZenGC产生了很好的化学反应。
ZenGC是阿里巴巴JVM团队基于G1算法， 面向大堆 (LargeHeap) 应用场景，优化的GC算法的统称。这里主要介绍下多租户GC。
多租户GC包含的三层核心逻辑：1） 在JavaHeap上，对象的分配按照租户隔离，不同的租户使用不同的Heap区域；2）允许GC以更小的代价发生在租户粒度，而不仅仅是应用的全局；3）允许上层应用根据业务需求对租户灵活映射。
ZenGC将内存Region划分为了多个租户，每个租户内独立触发GC。在个基础上，我们将内存分为普通租户和中等生命周期租户。中等生命周期对象指的是，既不稍纵即逝，也不永久存在的对象。由于经过以上两个大幅优化，现在堆中等生命周期对象数量和内存占用已经很少了。但是中等生命周期对象在生成时会被old区对象引用，每次young GC都需要扫描RSet，现在仍然是young GC的耗时大头。
借助于AJDK团队的ObjectTrace功能，我们找出中等生命周期对象中最'大头'的部分，将这些对象在生成时直接分配到中等生命周期租户的old区，避免RSet标记。而普通租户则以正常的方式进行内存分配。
普通租户GC频率很高，但是由于晋升的对象少，跨代引用少，Young区的GC时间得到了很好的控制。在实验室场景仿真环境中，我们将young GC优化到了5ms。
云端使用
阿里HBase目前已经在阿里云提供商业化服务，任何有需求的用户都可以在阿里云端使用深入改进的、一站式的HBase服务。云HBase版本与自建HBase相比在运维、可靠性、性能、稳定性、安全、成本等方面均有很多的改进
联系客服
