G1 垃圾收集器深入剖析(图文超详解)

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

G1 同 CMS 垃圾回收器一样，关注最小时延的垃圾回收器，适合大尺寸堆内存的垃圾收集。但是，G1 最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集及 CMS 的很多缺陷。

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

通过本篇，我们可以了解掌握 G1 收集器的基本概念、堆内存、回收流程、GC模式、推荐用例等核心知识。

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 ---