垃圾回收器篇之三：G1

G1(Garbage First 垃圾优先)

在延迟可控的情况下获得尽可能高的吞吐量

G1是一个并行回收器，他把堆内存分割为很多不相关的区域，使用不同的区域来标识Eden、幸存者0区，幸存者1区、老年代等。
G1跟踪各个区域里面垃圾堆积的价值大小（回收所得的空间大小以及回收所需时间的经验值）在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region,这种方式侧重与回收垃圾最大量的区间。

Region（分区）

分区化为4种角色：

• 自由角色（Free Tag）
• 新生代分区（YoungHeapRegion）,细分为eden分区与survivor分区
• 大对象分区（HHR）
• 老年代分区（OHR）

• 一个region有可能属于Eden,Survivor或者old/Tenured内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域，s表示属于Survivor内存区域，o表示属于old内存区域。图中空白的表示未使用的内存空间。
• G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过1.5个region,就放到H。
• 设置H的原因：
  • 对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待。
    

工作过程

可以分为如下几步

4. 初始标记（Initial Marking）
   标记以下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程，存在STW
5. 并发标记（Concurrent Marking）
   从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行
6. 最终标记（Final Marking）
   修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程,存在STW
7. 筛选回收（Live Data Counting and Evacuation）
   对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

使用场景

• 面向服务端应用，针对大内存的机器
• 在下面情况中用来替换JDK1.5中的CMS处理器
  • 超过50%的java堆被活动数据占用
  • 对象分配频率或年代提升频率变化大
  • GC停顿时间过长
• HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行

GC的多线程操作，而G1GC可以采用应用线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

G1回收器垃圾回收过程

1. 当年轻代的Eden区用尽时开始年轻代回收过程，G1的年轻代收集阶段是一个并行的独占式收集器。G1 GC暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Survivor区间或者老年区间，也有可能是两个区间都会涉及。
2. 当内存使用达到一定值（默认45%）时，开始老年代并发标记过程。
3. 标记完成开始混合收集过程，进行回收老年代与年轻代。G1 GC从老年代移动存活对象到空闲区，这些空闲区也就成了新的老年代。老年代的G1回收器和其他GC不同，G1的老年代回收器不需要整个老年代被回收，一次只扫描/回收一部分老年代的Region就可以了。

举个例子：一个web服务器，Java进程最大堆内存为4G,每分钟响应1500个请求，每45秒钟会新分配大约2G的内存。G1会每45秒钟进行一次年轻代回收，每31个小时整个堆的使用率会达到45，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收。

记忆集（Remembered Set）

区域间的对象相互引用，但对某一区域进行回收前需判断是否有其他区域的对象再引用着该区域。对其他区域逐一判断性能消耗过大。故区域内存储着记忆集。记忆集中记录着引用该区域内对象的区域地址。即通过CardTable把相关引用信息记录到引用对象的所在Region对应的Remembered Set 。
RSet有三种实现：

稀疏表

本质上就是一种Hash表，Key是Region的起始地址，Value是一个数组，里面存储的元素是卡页的索引号。但是这种key-value结构比较消耗内存

细粒度位图

就是一个位图，但是这个位图，可以详细的记录我们的内存变化，包括并发标记修改，对应元素标识等当稀疏表指定region的card数量超过阈值时，则在细粒度位图中创建一个对应的PerRegionTable对象。一个Region地址链表，维护当前Region中所有card对应的一个BitMap集合。

粗粒度位图

当细粒度位图 size超过阈值时，所有region 形成一个 bitMap。如果有region 对当前 Region 有指针指向，就设置其对应的bit 为1，也就是粗粒度位图

G1回收阶段：年轻代GC

1. 扫描根
   根是指static变量指向的对象、正在执行的方法调用链上的局部变量、连同RSet记录的外部引用作为存活对象的扫描入口
2. 更新Rset
   产生赋值语句时A a1 = new A() JVM会在diry card queue（脏卡队列）中入队一个保存了对象引用信息的card。在开始年轻代GC时将diry card queue中的数据更新到RSet中（不是赋值的时候直接更新RSet是因为Rset的处理需要线程同步开销会很大）
3. 处理RSet
   Eden中Rset中记录的老年代中的指向源就是存活的对象
   

G1回收阶段：并发标记过程

1. 初始标记阶段：标记从根节点直接可达的对象。这个阶段是STW的，并且会触发一次年轻代GC。
2. 根区域扫描(Root Region Scanning):G1 GC扫描Survivorl区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在young GC.之前完成。
3. 并发标记(Concurrent Marking):在整个堆中进行并发标记（和应用程序并发执行），此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例)。
4. 再次标记(Remark):由于应用程序持续进行，需要修正上一次的标记结果。是sTw的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning(SATB)。
5. 独占清理(cleanup,STW):计算各个区域的存活对象和GG回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫。是STW的。这个阶段并不会实际上去做垃圾的收集
6. 并发清理阶段：识别并清理完全空闲的区域。
   

G1回收阶段：混合回收

• 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。默认情况下，这些老年代的内存分段会分8次（可以通过XX:G1MixedGCCountTarget设置)被回收。
• 混合回收的回收集(collection Set)包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
• 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收，-XX:G1MixedGCLiveThresholdPercent,默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。
• 混合回收并不一定要进行8次。有一个阈值-XX:G1 HeapWastePercent,默认值为10%,意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少
  

G1回收阶段：Full GC

G1的初衷就是要避免Full GC的出现。但是如果上述方式不能正常工作，G1会停止应用程序的执行(Stop-The-World),使用单线程的内存回收算法
进行垃圾回收，性能会非常差，应用程序停顿时间会很长。
要避免Full GC的发生，一旦发生需要进行调整。什么时候会发生Full GC
呢？比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到full gc,这种情况可以通过增大内存解决。
导致G1Full GC的原因可能有两个：
1.Evacuation的时候没有足够的to-space来存放晋升的对象；
2.并发处理过程完成之前空间耗尽。

G1回收器优化建议

• 年轻代大小
  • 避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小
  • 固定年轻代的大小会覆盖暂停时间目标
• 暂停时间目标不要太过严苛
  • G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间
  • 评估G1 GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。
    

G1优点

1. 并行与并发
   并行性：G1回收期间，可以有多个GC同时工作，有效利用多核计算能力。此时用户线程STW。
   并发性：G1拥有与应用线程交互执行的能力，不会在整个回收阶段发生完全阻塞应用程序的情况
2. 分代收集
   1. G1属于分代型垃圾收集器，分为年轻代与老年代，年轻代也分为Eden区和Survivor区。但他不要求分代必须是连续的，也没有固定大小和固定数量。
   2. G1既可以处理年轻代又可以处理老年代
3. 空间整合
   region之间是复制算法，整体上可以看做标记-压缩算法。两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会无法找到连续的内存而触发GC。尤其是当Java堆很大时，G1优势更明显
4. 可预测的停顿时间模型
   G1除了追求低停顿外，还能建立可预测的停顿时间模型，让使用者明确指定在一个长度M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
   G1跟踪各个Region里面的垃圾堆积的价值大小，（回收所得的空间大小以及回收所需时间的经验值）在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region,这种方式在有限的时间内可以获取尽可能高的收集效率。
   

G1缺点

在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行的额外执行负载都比CMS高
在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上能发挥优势。平衡点在6-8G之间。

G1参数设置

• -XX:+UseG1GC：手动指定使用G1收集器执行内存回收任务。
• -XX:G1HeapRegionSize：设置每个Regionl的大小。值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
• -XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间指标(JVM会尽力实现，但不保证达到)。默认值是200ms
• -XX:ParallelGCThread：设置STW时GC线程数的值。最多设置为8
• -XX:ConcGCThreads：设置并发标记的线程数。将设置为并行垃圾回收线程数(Parallel GCThreads)的1/4左右。
• -XX:InitiatingHeapoccupancyPercent,设置触发并发Gc周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。
  

7种垃圾回收器总结

怎么选择垃圾收集器？

1. 优先调整堆的大小让JVM自适应完成。
2. 如果内存小于180M,使用串行收集器
3. 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
4. 如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
5. 如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用)，使用并发收集器

官方推荐G1,性能高。现在互联网的项目，基本都是使用G1。