垃圾收集器之G1收集器

G1收集器(-XX:+UseG1GC)

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

image-20230228232909465

一 特点

1. 分代收集

  • 虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念

  • G1将Java堆划分为多个大小相等的独立区域（Region），一般Region大小等于堆大小除以2048，JVM最多可以有2048个Region。

  • 这些Region中包含了逻辑上的年轻代和老年代，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。

  • 默认年轻代对堆内存的占比是5%，可以通过“-XX:G1NewSizePercent”设置年轻代初始占比。

  • 在系统运行中，JVM会不停的给年轻代增加更多的Region，但最多新生代的占比不会超过60%，可以通过“

    -XX:G1MaxNewSizePercent”调整。

  • 年轻代中的Eden和 Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100 个，s1对应100个

  • 一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。

2. 并行与并发

  • 并行性: G1能充分利用CPU、多核环境下的硬件优势，通过多个GC线程同时工作，来缩短Stop-The-World停顿时间。
  • 并发性: G1拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况

并发和并行的区别

并行，指的是多个事情，在同一时间点上同时发生了。并行的多个任务之间是不互相抢占资源的，系统要有多个CPU才会出现并行

并发，指的是多个事情，在同一时间段内同时发生了。 并发的多个任务之间是互相抢占资源的，整个过程中看似是多个任务同时完成的的，但其实是CPU在多次切换。

3. 空间整合

  • G1将内存划分为一个个的region。 内存的回收是以region作为基本单位的。
  • Region之间是复制算法,但整体上实际可看作是标记- 整理算法,两种算法都可以避免内存碎片。

4. 可预测的停顿

  • 降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数”- XX:MaxGCPauseMillis“指定)内完成垃圾收集。
  • 这里设置的“期望值”必须是符合实际的， 它默认的停顿目标为两百毫秒， 一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 最终占满堆引发 Full GC反而降低性能。

二 GC的运作过程

1.初始标记（initial mark，STW）

暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快

2. 并发标记（Concurrent Marking）

同CMS的并发标记

3. 最终标记（Remark，STW）

同CMS的重新标记

4. 筛选回收（Cleanup，STW）

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

  • G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。
  • 比如说老年代此时有1000个 Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集 合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。
  • CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本

三 G1垃圾收集分类

1. YoungGC

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

2. MixedGC

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

3. Full GC

  • 停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用

  • 这个过程是非常耗时的。(Shenandoah优化成多线程收集了) 。Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

四 G1 大对象的处理

  • G1有专门分配 大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。
  • 在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放 入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。
  • Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开 销。

五 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%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

-XX 后面带的X越多，说明这个参数越不稳定，后面可能会被废弃掉，比如java –version，这种事最稳定的

六 G1垃圾收集器优化建议

调节 -XX:MaxGCPauseMills 这个参数的值，避免 -XX:MaxGCPauseMills过大用户体验不好，-XX:MaxGCPauseMills过小，垃圾堆积至占满整个堆，触发full GC。

  • 假设参数 -XX:MaxGCPauseMills 设置的值很小， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 最终占满堆引发 Full GC反而降低性能

  • 假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统停顿很久，用户体验不好。

七 G1的使用场景

1. 希望消除长时间的GC停顿（超过0.5-1秒）

对于类似Kafka的系统，因为他需要支持每秒处理百万级的消息，所以一般需要大内存机器来部署，比如三四十G，对于这么大的内存，minor GC 即使使用复制算法，也就不再快了，很可能会出现系统每运行一两分钟就会因为minor gc卡顿几秒钟没法处理新消息，这显然是不可以的。使用G1收集器就可以消除长时间的GC停顿，比如设置停顿时间是50ms，后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。

2. 想要更可控、可预期的GC停顿周期

3. 多核CPU，大内存

8GB以上的堆内存(建议值)，因为g1算法很复杂，内存不够大，就不要用了

4. ？？

  • 对象分配或者晋升的速度变化大 ？？

  • 实时数据占用超过一半的堆空间 ？？

八 CMS收集器和G1收集器的区别

1. 使用范围不一样

  • CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用
  • G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用

2. STW的时间

  • CMS收集器以最小的停顿时间为目标的收集器。只有初始标记和重新标记需要STW
  • G1收集器可预测垃圾回收的停顿时间（建立可预测的停顿时间模型）。除了初始标记和重新标记需要STW，筛选回收时也需要STW，不过停顿时间可预测

3. 垃圾碎片

  • CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片
  • G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。

4. 垃圾回收的过程不一样

  • CMS: 初始标记 + 并发标记 + 重新标记 + 并发清除
  • G1: 初始标记 + 并发标记 + 最终标记 + 筛选回收
JVM
#性能调优 #垃圾收集器
垃圾收集器之G1收集器
http://example.com/垃圾收集器之G1收集器/
作者
Panyurou
发布于
2022年9月15日
许可协议