垃圾回收器-G1垃圾回收器详解

  • Post author:
  • Post category:其他


gc的基本概念及cms垃圾回收器的分析可以参考该篇:

垃圾回收器-CMS及常用回收器分析

G1垃圾回收器概念

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

不同的是年轻代和年老代不再是连续的物理内存,而是分成了多个region区域。如下图所示:

G1将Java堆划分为多个大小相等的独立区域(Region),JVM最多可以有2048个Region。

Humongous区

G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样,唯一不同的是对大对象的处理,G1有专门分配 大对象的Region叫Humongous区,而不是让大对象直接进入老年代的Region中。

在G1中,大对象的判定规则就是一 个大对象超过了一个Region大小的50%。如果对象特别大会横跨多个region区。

Humongous区专门存放短期巨型对象,不用直接进老年代,可以节约老年代的空间,避免因为老年代空间不够的GC开 销。

Full GC的时候除了收集年轻代和老年代之外,也会将Humongous区一并回收。

G1回收器的完整过程

一共分为四步:

初始标记(initial mark,STW):暂停所有的其他线程,并记录下gc roots直接能引用的对象,速度很快

并发标记(Concurrent Marking):同CMS的并发标记

最终标记(Remark,STW):同CMS的重新标记

筛选回收(Cleanup,STW):筛选回收阶段首先对各个Region的回收价值和成本进行排序,根据用户所期 望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划

筛选回收过程详解

筛选回收阶段首先对各个Region的回收价值和成本进行排序,根据用户所期 望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划。

比如说老年代此时有1000个 Region都满了,但是因为根据预期停顿时间,本次垃圾回收可能只能停顿200毫秒,那么通过之前回收成本计算得 知,可能回收其中800个Region刚好需要200ms,那么就只会回收800个Region。

回收算法主要用的是复制算法,将一个region中的存活对象复制到另一个region中,这种不会像CMS那样 回收完因为有很多内存碎片还需要整理一次,G1采用复制算法回收几乎不会有太多内存碎片。

G1收集器在后台维护了一个优先列表,每次根据允许的收集时间,优先选择回收价值最大的Region。这也就是它的名字 Garbage-First的由来。

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使用,这 个过程是非常耗时的。

G1收集器常用参数设置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB,且必须是2的N次幂),默认将整堆划分为2048个分区 ,一般Region大小等于堆大小除以2048,比如堆大小为4096M,则Region大小为2M。


-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

这里不建议太小或者太大,原因及结果如下分析:

太小会造成: 很可能出现的结果就是由于停顿目标时间太短, 导 致每次选出来的回收集只占堆内存很小的一部分, 收集器收集的速度逐渐跟不上分配器分配的速度, 导致垃圾慢慢堆 积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间, 但应用运行时间一长就不行了, 最终占满堆引发 Full GC反而降低性能。

太大会造成:导致系统运行很久,年轻代可能都占用了堆内存的60%了,此时才 触发年轻代gc。 那么存活下来的对象可能就会很多,此时就会导致Survivor区域放不下那么多的对象,就会进入老年代中。

所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值,在保证他的年轻代gc别太频繁的同时,还得考虑 每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代,频繁触发mixed gc.,通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

-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次),在最后一个筛选回收阶段可以回收一 会,然后暂停回收,恢复系统运行,一会再开始回收,这样可以让系统不至于单次停顿时间过长。

什么场景适合使用G1

1. 存活对象占用 堆50%以上的空间

2. 对象分配和晋升的速度变化非常大

3. 垃圾回收时间特别长,超过1秒

4. 8GB以上的堆内存

5. 停顿时间是500ms以内

G1的优点

1.G1能充分利用CPU的优势,减少stw的时间

2.G1不需要和其他gc配合就可以管理整个gc堆

3.G1整体都是采用标记整理算法实现的


4.G1最大的优点就是可以让使用者明确确定垃圾收集在规定时间内完成

G1特点简单总结

1.G1不同于传统的cms等垃圾回收器,没有连续的年轻代和年老代,而是将jvm堆划分为了多个大小相等的区域。默认是2048块(XX:G1HeapRegionSize参数指定每块大小,必须是2次幂),每块大小为jvm堆内存/区域数量。

2.G1初始年轻代是占堆内存5%(-XX:G1NewSizePercent设置新生代初始占比),会随着系统运行变化增多(区域会在年轻代和年老老代变化),但不会超过60%(-XX:G1MaxNewSizePercent设置年轻代最大占比)。g1的Eden区同其他gc,默认都是8:1:1

3.G1在年轻代和年老代转移的区别在于大对象的处理,会将大对象分到humongous区(大对象判断标准为大于一个区域的50%),过大会横跨多个区域存放。full gc会在回收年轻代和老年代外,将humongous区一并回收

4.G1的回收过程:前面几步同cms一样,只有最后一步有些区别

最后会有一个筛选回收,会在用户的期望时间内完成gc,但这个可能不是全部,而是收集优先级较高的垃圾。回收算法是复制,不需要再向cms一样进行内存碎片整理。这里同cms不同的是,回收阶段不是同用户线程并发进行,而是stw。

5.G1的名称由来:Garbage-First。优先选择回收价值最大的区域。g1会维护一个队列,在这个队列里维护回收价值大的区域。

6.G1垃圾回收分类与cms等不同,younggc不是eden放满立即回收,会判断下回收时间,当到达阈值才会回收。多了一个mixedgc过程(回收所有年轻代和部分年老代和大对象区域)。full gc是单线程

7.G1处理高并发场景,40g的内存回收需要2秒钟,对于一个64g的服务器来说,两分钟就需要进行一次gc,而gc一次几秒钟显然影响到了业务。而采用g1的话设置100ms收集,这100ms就可以收集2g内存



版权声明:本文为qq_39404258原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。