网易视频云：Base GC的前生今世 身世篇.docx

网易视频云：HBase GC的前生今世 身世篇 网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。现在，网易视频云与大家分享一下HBase GC的前生今世 身世篇。在之前的HBase BlockCache系列文章中已经简单提到：使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多，从而可能引发臭名昭著的Full GC，触发可怕的’stop-the-world’暂停，严重影响上层业务；而Bucket Cache缓存机制因为在初始化的时候就申请了一片固定大小的内存作为缓存，缓存淘汰不再由 JVM管理，数据Block的缓存操作只是对这篇空间的访问和覆盖，因而大大减少了内存碎片的出现，降低了Full GC发生的频率。那CMS GC策略如何导致内存碎片过多？内存碎片过多如何触发Full GC？HBase在演进的道路上又如何不断优化CMS GC？接下来这个系列《HBase GC的前生今生》将会为你一一揭开谜底，这个系列一共两篇文章，本篇文章－’身世篇’将会带你全面了解HBase的GC机制，后面一篇－’演进篇’将会给你道出HBase在发展的道路上如何不断对Full GC进行优化。Java GC概述整个HBase是构建在JVM虚拟机上的，因此了解HBase的内存管理机制以及不同缓存机制对GC的影响，就必须对Java GC有一个全面的了解。至于深入地理解Java GC 的工作原理，不在本文的讨论范围之内；当然，如果已经对Java GC比较熟悉，也可以跳过此节。Java GC建立在这样一个假设基础上的：大多数内存对象要么生存周期比较短，很快就会没人引用，比如处理RPC请求的buffer可能只会生存几微秒；要么生存周期比较长，比如Block Cache中的热点Block，可能就会生存几分钟，甚至更长时间。基于这样的事实，JVM将整个堆内存分为两个部分：新生代（young generation）和老生代（tenured generation），除此之外，JVM还有一个非堆内存区－Perm区，主要存放class信息以及其他meta元信息，内存结构如下图所示：其中Young区又分为Eden区和两个Survivor 区：S0和S1。一个内存对象在创建之后，首先会为其在新生代申请一块内存空间，如果这个对象在新生代存活了很长时间，会将其迁移到老生代。 在大多数对延迟敏感的业务场景下（比如HBase），建议使用如下JVM参数，-XX:+UseParNewGC和XX:+UseConcMarkSweepGC，其中前者表示对新生代执行并行的垃圾回收机制，而后者表示对老生代执行并行标记－清除垃圾回收机制。可见，JVM允许针对不同内存区执行不同的GC策略。新生代GC策略 – Parallel New Collector根据上文所述，对象初始化之后会被放入Young区，更具体的话应该是Eden区，当Eden区满了之后，会进行一次GC。GC算法会检查所有对象的引用情况，如果某个对象还有被引用，表示该对象存活。检查完成之后，会将这些存活的对象移到S0区，并且回收整个Eden区空间，称为一次Minor GC；接着新对象进来，又会放入Eden区，满了之后会检查S0和Eden区存活的对象，将所有存活的对象移到S1区，再回收整个S0和Eden区空间；很容易理解，S0和S1两个区总会有一个区是预留给下次存放存活对象用的。整个过程可以使用如下图示：这种算法称为复制算法，对于这种算法，有两点需要关注：1. 算法会执行’stop-the-world’暂停，但时间非常短。因为Young区通常会设置的比较小（一般不建议不超过512M），而且JVM会启动大量线程并发执行，一次Minor GC一般都会在几毫秒内完成2. 不会产生碎片，每次GC之后都会将存活的对象放入连续的空间（S0或S1）内存中所有对象都会维护一个计数器，每次Minor GC移动一个对象之后，都会为这个对象的计数器加一。当计数器增加到一定阈值之后，算法就会认为该对象生命周期很长，会将其移入老生代。该阈值可以通过JVM参数XX:MaxTenuringThreshold指定。老生代GC策略 – Concurrent Mark-Sweep每次执行Minor GC之后，都会有部分生命周期较长的对象被移入老生代，一段时间之后，老生代空间也会被占满。此时就需要针对老生代空间执行GC操作，此处我们介绍Concurrent Mark-Sweep（CMS）算法。CMS算法整个流程分为6个阶段，其中部分阶段会执行