G1（Garbage First）垃圾收集器是目前垃圾回收技术最前沿的成果之一。

G1 同 CMS 垃圾回收器一样，关注最小时延的垃圾回收器，适合大尺寸堆内存的垃圾收集。

G1 最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集及 CMS 的很多缺陷。

官方推荐使用 G1 来代替 CMS。

我们本篇重点了解 G1 收集器：

1. G1 概述

2. G1 堆内存

3. G1 回收流程

4. G1 GC 模式

5. G1 推荐用例

目录

  • G1 收集器概述
  • G1 的堆内存算法
    • 1. G1 之前的 JVM 内存模型
    • 2. G1收集器的内存模型
  • G1回收流程
    • 1. G1 收集器的阶段（步骤）
  • G1 的 GC 模式
    • 1. YoungGC 年轻代收集
    • 2. mixed gc
  • G1 的推荐用例

G1 收集器概述

HotSpot 团队一直努力朝着高效收集、减少停顿 (STW: Stop The World) 的方向努力，贡献了从串行 Serial 收集器、到并行收集器 Parallerl 收集器，再到 CMS 并发收集器，乃至如今的 G1 在内的一系列优秀的垃圾收集器。

G1(Garbage First) 垃圾收集器，是关注最小时延的垃圾回收器，也同样适合大尺寸堆内存的垃圾收集，官方推荐选择使用 G1 来替代 CMS 。

1. G1 收集器的最大特点

  • G1最大的特点是引入分区的思路，弱化了分代的概念。
  • 合理利用垃圾收集各个周期的资源，解决了其他收集器、甚至 CMS 的众多缺陷。

2. G1 的改进（相比较 CMS ）

  • 算法： G1 基于标记–整理算法, 不会产生空间碎片，在分配大对象时，不会因无法得到连续的空间，而提前触发一次 FULL GC 。
  • 停顿时间可控： G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象。
  • 并行与并发：G1 能更充分的利用 CPU 多核环境下的硬件优势，来缩短 stop the world 的停顿时间。

3. CMS 和 G1 的区别

  • CMS 中，堆被分为 PermGen，YoungGen，OldGen ；而 YoungGen 又分了两个 survivo 区域。在 G1 中，堆被平均分成几个区域 (region) ，在每个区域中，虽然也保留了新老代的概念，但是收集器是以整个区域为单位收集的。
  • G1 在回收内存后，会立即同时做合并空闲内存的工作；而 CMS ，则默认是在 STW（stop the world）的时候做。
  • G1 会在 Young GC 中使用；而 CMS只能在 O 区使用。

4. G1 收集器的应用场景

目前，CMS 还是默认首选的 GC 策略。

G1 垃圾收集算法，主要应用在多 CPU 大内存的服务中，在满足高吞吐量的同时，尽可能的满足垃圾回收时的暂停时间。

在以下场景中，G1 更适合：

  • 服务端多核 CPU、JVM 内存占用较大的应用（至少大于4G）；
  • 应用在运行过程中，会产生大量内存碎片、需要经常压缩空间；
  • 想要更可控、可预期的 GC 停顿周期，防止高并发下应用雪崩现象。

G1 的堆内存算法

1. G1 之前的 JVM 内存模型

  • 新生代：伊甸园区 (eden space) + 2个幸存区
  • 老年代
  • 持久代 (perm space)：JDK1.8 之前
  • 元空间 (metaspace)：JDK1.8 之后取代持久代

2. G1收集器的内存模型

2.1 G1 堆内存结构

堆内存会被切分成为很多个固定大小区域（Region），每个是连续范围的虚拟内存。

堆内存中一个区域 (Region) 的大小，可以通过 -XX:G1HeapRegionSize 参数指定，大小区间最小 1M 、最大 32M ，总之是 2 的幂次方。

默认是将堆内存按照 2048 份均分。

2.2 G1 堆内存分配

每个 Region 被标记了 E、S、O 和 H，这些区域在逻辑上被映射为 Eden，Survivor 和老年代。

存活的对象从一个区域转移（即复制或移动）到另一个区域。区域被设计为并行收集垃圾，可能会暂停所有应用线程。如上图所示，区域可以分配到 Eden，survivor 和老年代。

此外，还有第四种类型，被称为巨型区域（Humongous Region）。

Humongous 区域主要是为存储超过 50% 标准 region 大小的对象设计，它用来专门存放巨型对象。如果一个 H 区装不下一个巨型对象，那么 G1 会寻找连续的 H 分区来存储。为了能找到连续的 H 区，有时候不得不启动 Full GC 。

G1 回收流程

在执行垃圾收集时，G1 以类似于 CMS 收集器的方式运行。

1. G1 收集器的阶段，大致分为以下步骤：

1.1 G1 执行的第一阶段：初始标记 ( Initial Marking )

这个阶段是 STW(Stop the World ) 的，所有应用线程会被暂停，标记出从 GC Root 开始直接可达的对象。

1.2 G1 执行的第二阶段：并发标记

从 GC Roots 开始，对堆中对象进行可达性分析，找出存活对象，耗时较长。

当并发标记完成后，开始最终标记 ( Final Marking ) 阶段。

1.3 最终标记

标记那些在并发标记阶段发生变化的对象，将被回收。

1.4 筛选回收

首先，对各个 Regin 的回收价值和成本进行排序，根据用户所期待的 GC 停顿时间，来指定回收计划，回收一部分 Region 。

G1 中提供了 Young GC、Mixed GC 两种垃圾回收模式，这两种垃圾回收模式，都是 Stop The World(STW) 的。

G1 的 GC 模式

1. YoungGC 年轻代收集

在分配一般对象（非巨型对象）时，当所有 eden region 使用达到最大阀值、并且无法申请足够内存时，会触发一次 YoungGC 。

每次 younggc 会回收所有Eden 、以及 Survivor 区，并且将存活对象复制到 Old 区以及另一部分的 Survivor 区。

YoungGC 的回收过程：

  • 根扫描，跟 CMS 类似，Stop the world，扫描 GC Roots 对象；
  • 处理 Dirty card，更新 RSet；
  • 扫描 RSet ，扫描 RSet 中所有 old 区，对扫描到的 young 区或者 survivor 区的引用；
  • 拷贝扫描出的存活的对象到 survivor2/old 区；
  • 处理引用队列、软引用、弱引用、虚引用。

2. mixed gc

当越来越多的对象晋升到老年代 old region 时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即 mixed gc ，该算法并不是一个 old gc ，除了回收整个 young region ，还会回收一部分的 old region 。

这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些 old region 进行收集，从而可以对垃圾回收的耗时时间进行控制。

G1 没有 fullGC 概念，需要 fullGC 时，调用 serialOldGC 进行全堆扫描（包括 eden、survivor、o、perm）。

G1 的推荐用例

G1 的第一个重要特点：是为用户的应用程序的提供一个低GC延时和大内存GC的解决方案。

这意味着堆大小 6GB 或更大，稳定和可预测的暂停时间将低于 0.5 秒。

如果应用程序使用 CMS 或 ParallelOld 垃圾回收器，具有一个或多个以下特征，将有利于切换到 G1：

  • Full GC 持续时间太长或太频繁；
  • 对象分配率或年轻代升级老年代很频繁；
  • 不期望的很长的垃圾收集时间或压缩暂停（超过 0.5 至 1 秒）。

注意：

如果你正在使用 CMS 或 ParallelOld 收集器，且应用程序没有遇到长时间的垃圾收集暂停，则保持当前收集器就可以了。升级 JDK ，并不需要更新收集器为 G1 。

以上，是 G1 垃圾收集器的解析，欢迎评论区留言交流或拓展。

如果觉得有用，请顺手关注+点赞+转发支持下，谢谢。

作者简介

陈睿 |mikechen, 10 年 + 大厂架构经验，「mikechen 的互联网架构」系列文章作者，专注于互联网架构技术。

阅读「mikechen 的互联网架构」40W 字技术文章合集

Java 并发|JVM|MySQL|Spring|Redis|分布式|高并发

— end —