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。一个内存对象在创建之后，首先会为其在新生代申请一块内存空间，如果这个对象在新生代存活了很长时间，会将其迁移到