G1垃圾收集器

G1垃圾收集器

---

---

前言

G1垃圾收集器相信大家都听说过，但是在工作中用的都比较少，它是在JDK9版本Oracle公司正式推出了稳定版本的垃圾收集器。目前大多数互联网公司的项目都在使用JDK8版本，但是对于长远来看，G1还是会使用到，那么今天就让我们来一起学习下吧。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、G1垃圾收集器是什么？

G1(Garbage-First)垃圾收集器是一款面向服务器的垃圾收集器,主要针对配备多颗处理器以及大容量的机器。以极高的概率满足GC要求停顿时间的要求的同时，还具备高吞吐量的特性。

二、从G1的架构图来了解它

从上图我们可以了解，G1垃圾收集器没有物理上分代的概念，但是有逻辑上的分代概念。

1.Region

G1将java的堆分成大小相同的独立region，jvm最多有2048个独立的region。一般region的大小等于堆大小除以2048，比如说堆的大小是4个G（4096M），则每个region的大小是2M。当然我们也可以手动指定region的大小，使用“-XX:G1HeapRegionSize”手动指定region的大小。推荐是默认不设置。

2.物理隔离OR逻辑隔离

G1保留了年轻代和老年代的概念，但是不再是物理隔离了。它们都可以是(不连续)的region集合。
默认年轻代对堆内存的占比是5%。如果堆内存是4096M，那么年轻代占的200M的内存空间。对应的region个数也就是100个左右。当然通过“-XX:G1NewSizePercent”设置年轻代的初始占比。在系统的运行过程中，Jvm会不断给年轻代增加更多的region，最多不超过堆内存的60%。可以通过“-XX:G1MaxNewSizePercent”进行调整。年轻代中的Eden和Surviour对应的region和之前一样，默认是8：1：1。假设现在有1000个年轻代region，那么Eden占800个，surviour0占100个，surviour1占100个。

一个region之前是年轻代，但是如果region经过一次垃圾回收后可能变成老年代，因此region的功能区域是动态变化的。

3.大对象的处理

G1收集器对于对象什么时候会转移到老年代，基本的规则和之前一样。唯一不同的是大对象的处理。G1专门分配了一块区域来存储大对象，名称叫Humongous。而不是让对象直接进入老年代。在G1中如何判断一个对象是大对象呢？大对象的判定规则就是一个对象的所占内存占了region的50%以上。如果一个对象6M，那么就会横跨3个region来存储这些对象。
Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。
Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

---

三、G1的处理流程

1.具体步骤

1. 初始标记（STW）：暂停所有其他线程，并记录下Gc root的直接引用对象
2. 并发标记：用户线程和垃圾收集线程一起运行。初始标记阶段被标记对象的状态会发生改变。
3. 最终标记（STW）：处理在并发标记阶段，对象的状态发生改变的对象。使用三色标记里面原始快照的方式去处理。
4. 筛选回收（STW）：筛选回收阶段，首先会对各个region的回收价值和成本进行排序。根据用户所期望的STW停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来指定回收计划。这个XX:MaxGCPauseMillis是G1垃圾收集器的核心参数，如果不设置的话默认是200ms。比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

2.G1的特点

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
• 空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

毫无疑问， 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过， 这里设置的“期望值”必须是符合实际的， 不能异想天开， 毕竟G1是要冻结用户线程来复制对象的， 这个停顿时
间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒， 一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发Full GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

3.G1的垃圾收集分类

• YoungGC:YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC

• MixedGC:不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC

• Full GC:停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)

---

四：G1的核心参数

-XX:+UseG1GC:使用G1收集器
-XX:ParallelGCThreads:指定GC工作的线程数量
-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区
-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%，值配置整数，默认就是百分比)
-XX:G1MaxNewSizePercent:新生代内存最大空间
-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
-XX:MaxTenuringThreshold:最大年龄阈值(默认15)
-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了
-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。
-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

五：G1垃圾收集器优化建议

假设参数 -XX:MaxGCPauseMills 设置的最大停顿时间的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。
那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。
或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。
所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

五：什么场景适合使用G1

1. 50%以上的堆被存活对象占用
2. 对象分配和晋升的速度变化非常大
3. 垃圾回收时间特别长，超过1秒
4. 8GB以上的堆内存(建议值)
5. 停顿时间是500ms以内