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