JVM性能调优实践——G1 垃圾收集器介绍篇

前言

前面两篇主要整理了性能测试的主要观察指标信息：性能测试篇，以及JVM性能调优的工具：JVM篇。这一篇先简单总结一下GC的种类，然后侧重总结下G1(Garbage-First)垃圾收集器的分代，结合open-jdk源码分析下重要算法如SATB,重要存储结构如CSet、RSet、TLAB、PLAB、Card Table等。最后会再梳理下G1 GC的YoungGC,MixedGC收集过程。

GC的分类

GC的主要回收区域就是年轻代(young gen)、老年代(tenured gen)、持久区（perm gen）。在jdk8之后，perm gen消失，被替换成了元空间（Metaspace）。垃圾收集为了提高效率，采用分代收集的方式，对于不同特点的回收区域使用不同的垃圾收集器。系统正常运行情况young是比较频繁的，full gc会触发整个heap的扫描和回收。在G1垃圾收集器中，最好的优化状态就是通过不断调整分区空间，避免进行full gc，可以大幅提高吞吐量。下面会详细介绍。

串行垃圾回收器

JDK 1.3之前的垃圾回收器，单线程回收，并且会有stop theworld（下文会简称STW），也即GC时，暂停所有用户线程。其运行方式是单线程的，适合Client模式的应用，适合单CPU环境。串行的垃圾收集器有两种，Serial以及SerialOld，一般会搭配使用。新生代使用Serial采取复制算法，老年代使用Serial Old采取标记整理算法。Client应用或者命令行程序可以，通过**-XX:+UseSerialGC**可以开启上述回收模式。

• Serial：用于新生代垃圾收集，复制算法
• SerialOld：用于老年代垃圾收集，标记整理算法

并行垃圾回收器

整体来说，并行垃圾回收相对于串行，是通过多线程运行垃圾收集的。也会stop-the-world。适合Server模式以及多CPU环境。一般会和jdk1.5之后出现的CMS搭配使用。并行的垃圾回收器有以下几种：

• ParNew：Serial收集器的多线程版本，默认开启的收集线程数和cpu数量一样，运行数量可以通过修改ParallelGCThreads设定。用于新生代收集，复制算法。使用**-XX:+UseParNewGC**,和Serial Old收集器组合进行内存回收。
• Parallel Scavenge: 关注吞吐量,吞吐量优先，吞吐量=代码运行时间/(代码运行时间+垃圾收集时间),也就是高效率利用cpu时间，尽快完成程序的运算任务
  可以设置最大停顿时间MaxGCPauseMillis以及，吞吐量大小GCTimeRatio。如果设置了-XX:+UseAdaptiveSizePolicy参数，则随着GC,会动态调整新生代的大小，Eden,Survivor比例等，以提供最合适的停顿时间或者最大的吞吐量。用于新生代收集，复制算法。通过**-XX:+UseParallelGC**参数，Server模式下默认提供了其和SerialOld进行搭配的分代收集方式。
• Parllel Old：Parallel Scavenge的老年代版本。JDK 1.6开始提供的。在此之前Parallel Scavenge的地位也很尴尬，而有了Parllel Old之后，通过**-XX:+UseParallelOldGC**参数使用Parallel Scavenge + Parallel Old器组合进行内存回收。

并发标记扫描垃圾回收器(CMS)

CMS（Concurrent Mark Sweep）基于“标记—清除”算法，用于老年代,所以其关注点在于减少“pause time”也即因垃圾回收导致的stop the world时间。对于重视服务的响应速度的应用可以使用CMS。因为CMS是“并发”运行的，也即垃圾收集线程可以和用户线程同时运行。 缺点就是会产生内存碎片。
CMS的回收分为几个阶段：

1. 初始标记：标记一下GC Roots能直接关联到的对象，会“Stop The World”
2. 并发标记：GC Roots Tracing，可以和用户线程并发执行。
3. 重新标记：标记期间产生的对象存活的再次判断，修正对这些对象的标记，执行时间相对并发标记短，会“Stop The World”。
4. 并发清除：清除对象,可以和用户线程并发执行。

CMS最主要解决了pause time，但是会占用CPU资源，牺牲吞吐量。CMS默认启动的回收线程数是（CPU数量+3）/ 4，当CPU<4个时，会影响用户线程的执行。另外一个缺点就是内存碎片的问题了，碎片会给大对象的内存分配造成麻烦，如果老年代的可用的连续空间也无法分配时，会触发full gc。并且full gc时如果发生young gc会被young gc打断，执行完young gc之后再继续执行full gc。
-XX:UseConcMarkSweepGC参数可以开启CMS,年轻代使用ParNew，老年代使用CMS，同时Serial Old收集器将作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器使用。

G1垃圾收集器

G1（Garbage-First）是在JDK 7u4版本之后发布的垃圾收集器，并在jdk9中成为默认垃圾收集器。通过“-XX:+UseG1GC”启动参数即可指定使用G1 GC。从整体来说，G1也是利用多CPU来缩短stop the world时间，并且是高效的并发垃圾收集器。但是G1不再像上文所述的垃圾收集器，需要分代配合不同的垃圾收集器，因为G1中的垃圾收集区域是“分区”（Region）的。G1的分代收集和以上垃圾收集器不同的就是除了有年轻代的ygc，全堆扫描的fullgc外，还有包含所有年轻代以及部分老年代Region的MixedGC。G1的优势还有可以通过调整参数，指定垃圾收集的最大允许pause time。下面会详细阐述下G1分区以及分代的概念，以及G1 GC的几种收集过程的分类。

G1分区的概念

在G1之前的垃圾收集器，将堆区主要划分了Eden区，Old区，Survivor区。其中对于Eden，Survivor对回收过程来说叫做“年轻代垃圾收集”。并且年轻代和老年代都分别是连续的内存空间。
G1将堆分成了若干Region,以下和"分区"代表同一概念。Region的大小可以通过G1HeapRegionSize参数进行设置，其必须是2的幂，范围允许为1Mb到32Mb。 JVM的会基于堆内存的初始值和最大值的平均数计算分区的尺寸，平均的堆尺寸会分出约2000个Region。分区大小一旦设置，则启动之后不会再变化。如下图简单画了下G1分区模型。

1. Eden regions(年轻代-Eden区)
2. Survivor regions(年轻代-Survivor区)
3. Old regions（老年代）
4. Humongous regions（巨型对象区域）
5. Free resgions（未分配区域，也会叫做可用分区）-上图中空白的区域

关于分区有几个重要的概念：

• G1还是采用分代回收，但是不同的分代之间内存不一定是连续的，不同分代的Region的占用数也不一定是固定的（不建议通过相关选项显式设置年轻代大小。会覆盖暂停时间目标。）。年轻代的Eden,Survivor数量会随着每一次GC发生相应的改变。
• 分区是不固定属于哪个分代的，所以比如一次ygc过后，原来的Eden的分区就会变成空闲的可用分区，随后也可能被用作分配巨型对象，成为H区等。
• G1中的巨型对象是指，占用了Region容量的50%以上的一个对象。Humongous区，就专门用来存储巨型对象。如果一个H区装不下一个巨型对象，则会通过连续的若干H分区来存储。因为巨型对象的转移会影响GC效率，所以并发标记阶段发现巨型对象不再存活时，会将其直接回收。ygc也会在某些情况下对巨型对象进行回收。
• 通过上图可以看出，分区可以有效利用内存空间，因为收集整体是使用“标记-整理”，Region之间基于“复制”算法，GC后会将存活对象复制到可用分区（未分配的分区），所以不会产生空间碎片。
• G1类似CMS，也会在比如一次fullgc中基于堆尺寸的计算重新调整（增加）堆的空间。但是相较于执行fullgc，G1 GC会在无法分配对象或者巨型对象无法获得连续分区来分配空间时，优先尝试扩展堆空间来获得更多的可用分区。原则上就是G1会计算执行GC的时间，并且极力减少花在GC上的时间（包括ygc,mixgc）,如果可能，会通过不断扩展堆空间来满足对象分配、转移的需要。
• 因为G1提供了“可预测的暂停时间”，也是基于G1的启发式算法，所以G1会估算年轻代需要多少分区，以及还有多少分区要被回收。ygc触发的契机就是在Eden分区数量达到上限时。一次ygc会回收所有的Eden和survivor区。其中存活的对象会被转移到另一个新的survivor区或者old区，如果转移的目标分区满了，会再将可用区标记成S或者O区。

G1 中的重要数据结构、算法

在提及G1的垃圾收集过程时，需要理解几个G1的重要的分区内部的详细数据结构、以及核心算法。

TLAB(Thread Local Allocation Buffer)本地线程缓冲区

G1 GC会默认会启用Tlab优化。其作用就是在并发情况下，基于CAS的独享线程(mutator threads)可以优先将对象分配在一块内存区域（属于Java堆的Eden中)，只是因为是Java线程独享的内存区，没有锁竞争，所以分配速度更快，每个Tlab都是一个线程独享的。如果待分配的对象被判断是巨型对象，则不使用TLAB。
下面把TLAB分配对象内存的open jdk部分源码附上，有助理解。

HeapWord* G1CollectedHeap::allocate_new_tlab(size_t min_size,
                                             size_t requested_size,
                                             size_t* actual_size) {
  assert_heap_not_locked_and_not_at_safepoint();
  assert(!is_humongous(requested_size), "we do not allow humongous TLABs");

  return attempt_allocation(min_size, requested_size, actual_size);
}


inline HeapWord* G1CollectedHeap::attempt_allocation(size_t min_word_size,
                                                     size_t desired_word_size,
                                                     size_t* actual_word_size) {
  assert_heap_not_locked_and_not_at_safepoint();
  // 排除巨型对象
  assert(!is_humongous(desired_word_size), "attempt_allocation() should not "
         "be called for humongous allocation requests");

// 在当前的region分配 
  HeapWord* result = _allocator->attempt_allocation(min_word_size, desired_word_size, actual_word_size);

// 可用空间不够，申请新的region分配 
  if (result == NULL) {
    *actual_word_size = desired_word_size;
    // 可能存在多线程申请，所以通过加锁的方式申请，如果young区没有超出阀值，则会获取新的region 
    result = attempt_allocation_slow(desired_word_size);
  }

  // 判断没有因gc导致堆locked  
  assert_heap_not_locked();
  if (result != NULL) {
    assert(*actual_word_size != 0, "Actual size must have been set here");
    // 脏化年轻代的card(卡片)数据
    dirty_young_block(result, *actual_word_size);
  } else {
    *actual_word_size = 0;
  }

  return result;
}

PLAB(Promotion Local Allocation Buffer) 晋升本地分配缓冲区

在ygc中，对象会将全部Eden区存货的对象转移（复制）到S区分区。也会存在S区对象晋升（Promotion）到老年代。这个决定晋升的阀值可以通过MaxTenuringThreshold设定。晋升的过程,无论是晋升到S还是O区，都是在GC线程的PLAB中进行。每个GC线程都有一个PLAB。

Collection Sets(CSets)待收集集合

GC中待回收的region的集合。CSet中可能存放着各个分代的Region。CSet中的存活对象会在gc中被移动（复制）。GC后CSet中的region会成为可用分区。

Card Table 卡表

将Java堆划分为相等大小的一个个区域，这个小的区域（一般size在128-512字节）被当做Card，而Card Table维护着所有的Card。Card Table的结构是一个字节数组,Card Table用单字节的信息映射着一个Card。当Card中存储了对象时，称为这个Card被脏化了（dirty card）。 对于一些热点Card会存放到Hot card cache。同Card Table一样，Hot card cache也是全局的结构。

Remembered Sets(RSets)已记忆集合

已记忆集合在每个分区中都存在，并且每个分区只有一个RSet。其中存储着其他分区中的对象对本分区对象的引用,是一种points-in结构。ygc的时候，只要扫描RSet中的其他old区对象对于本young区的引用，不需要扫描所有old区。mixed gc时，扫描Old区的RSet中,其他old区对于本old分区的引用，一样不用扫描所有的old区。提高了GC效率。因为每次GC都会扫描所有young区对象，所以RSet只有在扫描old引用young，old引用old时会被使用。
为了防止RSet溢出，对于一些比较“Hot”的RSet会通过存储粒度级别来控制。RSet有三种粒度，对于“Hot”的RSet在存储时，根据细粒度的存储阀值，可能会采取粗粒度。
这三种粒度的RSet都是通过PerRegionTable来维护内部数据的。可以查看其部分源码如下：

class PerRegionTable: public CHeapObj<mtGC> {
  friend class OtherRegionsTable;
  friend class HeapRegionRemSetIterator;

  HeapRegion*     _hr; // 来自其他分区的引用
  CHeapBitMap     _bm; // card索引存放的位图
  jint            _occupied; // 已占用的容量

  // next pointer for free/allocated 'all' list
  PerRegionTable* _next;

  // prev pointer for the allocated 'all' list
  PerRegionTable* _prev;

  // next pointer in collision list
  PerRegionTable * _collision_list_next;

  // Global free list of PRTs 
  static PerRegionTable* volatile _free_list;

简要结构如下图（图片来源）

下面是三种粒度级别，以及对应的简要数据结构：

• 细粒度(fine),其PerRegionTable存储了所有对于本Resgion的引用的卡片的索引，其卡片索引都存储在CHeapBitMap结构里。伪代码类似：hash_map<region_id ,bitmap<MAX_CARD>>
• 稀疏(sparse) ，存储了部分Card索引。伪代码类似：hash_map<region_id,card_list>
• 粗粒度(coarse) ，其只存储了所有对于本Resgion有着引用的分区的列表。伪代码类似 bitmap<MAX_REGION>

所以对于粗粒度的RSet的扫描是最慢的，因为要先找到引用的分区，然后再扫描该分区的所有Card。为了提高扫描卡片的效率，在GC过程中，都会把扫描记录在全局的Card Table中，避免重复扫描,并在这次GC后会运行G1ClearCardTableTask，清空Card Table，在ygc,mixedgc的日志中可以可以看到执行Clear CT的记录（下一篇文章会分析G1的gc log）。
当然为了能更好得在并发条件下处理RSet，G1 GC还通过(Post-write barriers)也即栅栏代码的执行是在引用写之后，以及并发优化线程(Concurrent refinement threads)来帮助处理跨分区的引用的Card的更新。这些附增的分区信息会被Mutator线程放到“更新日志缓冲区”或者DirtyCardQueueSet脏卡片队列。
对于Rset更详细的介绍可以参考Tips for Tuning the Garbage First Garbage Collector 。

Snapshot-At-The-Beginning(SATB)

SATB是在G1 GC在并发标记阶段使用的增量式的标记算法。并发标记是并发多线程的，但并发线程在同一时刻只扫描一个分区。
在解释SATB前先要了解三色标记法。三色标记法是将对象的存活状态用三种颜色标记，从黑色到灰色逐层标记：

• 黑：该对象被标记了，并且其引用的对象也都被标记完成。
• 灰：对象被标记了，但其引用的对象还没有被标记完。
• 白：对象还没有被标记，标记阶段结束后，会被回收。

在CMS GC中，并发标记阶段使用的是Incremental update批量更新算法，在增加引用时的写屏障中触发新的对象引用的标记（三色标记法）。
G1的并发标记算法，使用的是SATB。在GC开始时先创建一个对象快照，STAB可以在并发标记时标记所有快照中当时的存活对象。标记过程中新分配的对象也会被标记为存活对象，不会被回收。STAB核心的两个结构就是两个BitMap。如下：

 // from G1ConcurrentMark-可以认为Bitmap的内部存储着对象地址（reference 是8byte,所以Bitmap存储着一个个64bit结构）

 G1CMBitMap*             _prev_mark_bitmap; //  全局的bitmap,存储PTAMS偏移位置，也即当前标记的对象的地址（初始值是对应上次已经标记完成的地址）
 G1CMBitMap*             _next_mark_bitmap; // 全局的bitmap,存储NTAMS偏移位置。标记过程不断移动，标记完成后会和prev_map 互换。 

bitmap分别存储着每个分区中，并发标记过程里的两个重要的变量：PTAMS(pre-top-at-mark-start，代表着分区上一次完成标记的位置) 以及NTAMS（next-top-at-mark-start，随着标记的进行会不断移动，一开始在top位置）。SATB通过控制两个变量的移动来进行标记。为了直观了解标记过程，如下图所示：（原图论文）

A：初始标记，因为要扫描所有Root Trace可达的对象，会有STW的暂停时间，会将扫描分区的NTAMS值设置为分区的顶部（Top）。
B：最终标记，因为并发导致会有新分配的对象，因为并发标记过程中对象会被分配到NTAMS~TOP中间的区域。这些对象会被定义为”隐式对象“。因为NTAMS有很多值了，所以_next_mark_bitmap也会开始存储NTAMS标记的对象的地址。
C:清除阶段：_next_mark_bitmap和_prev_mark_bitmap会进行Swap。PTAMS和NTAMS也会互换值。清除所有Bottom~PTAMS的对象。对于”隐式对象“会在下次垃圾收集过程进行回收（如图F过程）。这也是SATB存在弊端，会一定程度产生未能在本次标记中识别的浮动垃圾。

另，以上过程省略了根分区扫描和并发标记。上图是包含了两次标记过程，主要是为了展示B-E过程中，并发情况新对象的分配。

G1 GC的分类和过程

JDK10 之前的G1中的GC只有YoungGC,MixedGC。FullGC处理会交给单线程的Serial Old垃圾收集器。

YoungGC年轻代收集

在分配一般对象（非巨型对象）时，当所有eden region使用达到最大阀值并且无法申请足够内存时，会触发一次YoungGC。每次younggc会回收所有Eden以及Survivor区，并且将存活对象复制到Old区以及另一部分的Survivor区。到Old区的标准就是在PLAB中得到的计算结果。因为YoungGC会进行根扫描，所以会stop the world。

YoungGC的回收过程如下：

1. 根扫描,跟CMS类似，Stop the world，扫描GC Roots对象。
2. 处理Dirty card,更新RSet.
3. 扫描RSet,扫描RSet中所有old区对扫描到的young区或者survivor去的引用。
4. 拷贝扫描出的存活的对象到survivor2/old区
5. 处理引用队列，软引用，弱引用，虚引用（下一篇优化中会再讲一下这三种引用对gc的影响）

MixGC混合收集

MixedGC是G1 GC特有的，跟Full GC不同的是Mixed GC只回收部分老年代的Region。哪些old region能够放到CSet里面，有很多参数可以控制。比如G1HeapWastePercent参数，在一次younggc之后，可以允许的堆垃圾百占比，超过这个值就会触发mixedGC。G1MixedGCLiveThresholdPercent参数控制的，old代分区中的存活对象比，达到阀值时，这个old分区会被放入CSet。源码可以看下gc/g1/collectionSetChooser。
MixedGC一般会发生在一次YoungGC后面,为了提高效率，MixedGC会复用YoungGC的全局的根扫描结果，因为这个Stop the world过程是必须的，整体上来说缩短了暂停时间。

MixGC的回收过程可以理解为YoungGC后附加的全局concurrent marking，全局的并发标记主要用来处理old区（包含H区）的存活对象标记，过程如下：

1. 初始标记（InitingMark）。标记GC Roots，会STW,一般会复用YoungGC的暂停时间。如前文所述，初始标记会设置好所有分区的NTAMS值。
2. 根分区扫描（RootRegionScan）。这个阶段GC的线程可以和应用线程并发运行。其主要扫描初始标记以及之前YoungGC对象转移到的Survivor分区，并标记Survivor区中引用的对象。所以此阶段的Survivor分区也叫根分区（RootRegion）。部分源码如下:

// 当有需要扫描的的S分区时，该Task会被开启，扫描后会执行scan_finished，notify其他GC活动，如youngGC  
class G1CMRootRegionScanTask : public AbstractGangTask {
  G1ConcurrentMark* _cm;
public:
  G1CMRootRegionScanTask(G1ConcurrentMark* cm) :
    AbstractGangTask("G1 Root Region Scan"), _cm(cm) { }

  void work(uint worker_id) {
    assert(Thread::current()->is_ConcurrentGC_thread(),
           "this should only be done by a conc GC thread");

    G1CMRootRegions* root_regions = _cm->root_regions();  //   _root_regions 初始化为待扫描的Survivor分区。   
    HeapRegion* hr = root_regions->claim_next();
    while (hr != NULL) { // 循环分别处理所有待扫描的S分区   
      _cm->scan_root_region(hr, worker_id);  //方法如下
      hr = root_regions->claim_next();
    }
  }
};


  // 扫描Survivor区 （HeapRegion* hr）   
void G1ConcurrentMark::scan_root_region(HeapRegion* hr, uint worker_id) {
 
  assert(hr->next_top_at_mark_start() == hr->bottom(), "invariant");
  G1RootRegionScanClosure cl(_g1h, this, worker_id);

  const uintx interval = PrefetchScanIntervalInBytes; 
  HeapWord* curr = hr->bottom();   // 扫描分区的bottom
  const HeapWord* end = hr->top(); // 扫描分区的top
  while (curr < end) { // 扫描所有bottom到top的分区的对象  
    Prefetch::read(curr, interval);
    oop obj = oop(curr);
    int size = obj->oop_iterate_size(&cl);
    assert(size == obj->size(), "sanity");
    curr += size;
  }
}   

3. 并发标记（ConcurrentMark）。会并发标记所有非完全空闲的分区的存活对象，也即使用了SATB算法，标记各个分区。
4. 最终标记（Remark）。主要处理SATB缓冲区，以及并发标记阶段未标记到的漏网之鱼（存活对象），会STW,可以参考上文的SATB处理。
5. 清除阶段（Clean UP）。上述SATB也提到了，会进行bitmap的swap，以及PTAMS,NTAMS互换。整理堆分区，调整相应的RSet（比如如果其中记录的Card中的对象都被回收，则这个卡片的也会从RSet中移除）,如果识别到了完全空的分区，则会清理这个分区的RSet。这个过程会STW。

清除阶段之后，还会对存活对象进行转移（复制算法），转移到其他可用分区，所以当前的分区就变成了新的可用分区。复制转移主要是为了解决分区内的碎片问题。

FullGC

G1在对象复制/转移失败或者没法分配足够内存（比如巨型对象没有足够的连续分区分配）时，会触发FullGC。FullGC使用的是stop the world的单线程的Serial Old模式,所以一旦触发FullGC则会STW应用线程，并且执行效率很慢。JDK 8版本的G1是不提供Full gc的处理的。对于G1 GC的优化，很大的目标就是没有FullGC。

总结

文章对目前JVM的几种垃圾收集器做了简单总结。详细梳理了一下G1 GC的关键概念。本来想一起把G1 GC参数优化和GC Log也加上的，但篇幅有点长了，下一篇会加上[TODO->G1 垃圾收集器性能调优篇]。
本文内容都是基于JDK 8的版本的，在jdk10版本的G1 GC会有很多优化。Full CG方面，将提供并发标记的Full GC方案：Parallelize Mark-Sweep-Compact。Card Table的扫描也会得到加速。RSet也优化了，目前的RSet会存储在所有的分区里，新版本的RSet只需要在CSet中，并且是在Remark到Clean阶段之间并发构建RSet。这项优化会增加整个并发标记的周期，但是缩减了很多RSet的占用空间。另外，对于PauseTime会有更精准的处理，在MixedGC的对象拷贝阶段，提供了可放弃拷贝的（Abortable）选项。MixedGC会计算下一个Region的对象拷贝，如果可能会超过预期的pause time,则会放弃这次拷贝。对于JDK10的G1 GC更多信息可以看一下2018-Oracle G1 GC。

参考文献

Garbage-First Garbage Collection
introduction-g1-garbage-collector
tuning-tips-G1-GC
2018-Oracle G1 GC