Garbage First（简称G1）收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。被Oracle官方称为“全功能的垃圾收集器”（Fully-Featured GarbageCollector）。JDK 9服务端模式下的默认垃圾收集器，而CMS则沦落至被声明为不推荐使用（Deprecate）的收集器。本文将对G1进行简单的介绍。
一 回顾G1之前的垃圾收集器(经典垃圾收集器)
上图展示了七种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用，图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器。
对以上除G1外的收集器进行下简单介绍：
1 Serial收集器
- Serial 新生代收集器 单线程工作的收集器 使用复制算法
- Serial Old是Serial收集器的老年代版本 单线程收集器，使用标记-整理算法
Serial/Serial Old收集器运行示意图
2 ParNew 收集器
新生代收集器，就是Serial收集器的多线程版本。除了serial收集器外，目前只有它能与CMS收集器配合工作。
ParNew/Serial Old收集器运行示意图
3 Parallel Scavenge收集器
- 新生代收集器，基于标记-复制算法实现，也是能够并行收集的多线程收集器
- 自适应调节策略是Parallel Scavenge收集器与ParNew收集器的一个重要区别
-XX:+UseAdaptiveSizePolicy是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。 - 更关注可控制的吞吐量 Throughput
- 如果虚拟机完成某个任务，用户代码加上垃圾收集总共耗费了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%
- 应用场景(高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间)
高吞吐量可以最高效率的利用CPU时间，尽快的完成程序的运算任务等，当应用程序运行在具有多个CPU上，对暂停时间没有特别高的要求时，即程序主要在后台进行计算，而不需要与用户进行太多交互；例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序（停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序，良好的响应速度能提升用户体验，此种场景CMS效果更好）
4 Parallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。
Parallel Scavenge/Parallel Old收集器运行示意图
4 CMS 收集器
- CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。 目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于标记-清除算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤，包括：
- 初始标记（CMS initial mark）
- 并发标记（CMS concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS concurrent sweep）
- 其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
Concurrent Mark Sweep收集器运行示意图
- CMS是老年代垃圾收集器，在收集过程中可以与用户线程并发操作。它可以与Serial收集器和Parallel New收集器搭配使用。CMS牺牲了系统的吞吐量来追求收集速度，适合追求垃圾收集速度的服务器上。
- CMS是一款基于标记-清除算法实现的收集器，这意味着收集结束时会有大量空间碎片产生
- 在2019年12月，已经被最新的JDK移除了（https://openjdk.java.net/jeps/363）
二 初识G1
下面这个是G1的官方文档，想学习G1垃圾回收器的，看官方文档是最靠谱的
G1的发展历史：
2004年发布的那篇论文在这里：http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.6386&rep=rep1&type=pdf
2017年，G1成为jdk9之后默认的垃圾收回器了
三 为什么需要G1？
Hotspot之前已经携带了Serial, Paralel, CMS等收集器，为什么还需要研发一个新的G1呢？垃圾收集的三个性能指标: footprint（内存占用）, max pause time（最大停顿时间）, throughput（吞吐量）似乎像CAP一样不能同时满足。在服务端更注重的是短停顿时间，也就是stop-the-world的时间，一段时间内的总停顿时间也是一个衡量指标。Mark-Sweep, Mark-Compact均需要和清理区域大小成比例的工作量，而Copying算法则需要一般是一半的空间用于存放每次copy的活对象。CMS的Initial Marking和Remarking两个STW阶段在Heap区越来越大的情况下需要的时间越长，并且由于内存碎片，需要压缩的话也会造成较长停顿时间。所以需要一种高吞吐量的短暂停时间的收集器，而不管堆内存多大（现代的堆越来越大了，32G，64G的很平常）。
而G1正是达成了这种目标的垃圾收集器，它在官方文档是这样描述的：
“Garbage-First（G1）垃圾收集器的目标是具有大量内存的多处理器计算机。 它尝试以极高的可能性满足垃圾收集暂停时间目标，同时几乎不需要配置即可实现高吞吐量。G1的目标是使用当前的目标应用程序和环境在延迟和吞吐量之间达到最佳平衡，其特点包括：
- 堆大小最大为 10 GB或更大，其中超过 50％ 的Java堆占用实时数据。
- 对象分配和升级的速率可能会随时间而显着变化。
- 堆中有大量碎片。
- 可预测的暂停时间目标不超过几百毫秒，避免了长时间的垃圾收集暂停。
G1取代了并发标记清除（CMS）收集器。 它也是默认的收集器。”
四 内存布局
传统的GC收集器将连续的内存空间划分为新生代、老年代和永久代（JDK 8去除了永久代，引入了元空间Metaspace）
G1的内存布局已经完全不一样了
- 如上图所示，G1将堆分成若干个等大的区域（region）。每个Region占有一块连续的虚拟内存地址.每个Region的大小可以通过参数-XX：G1HeapRegionSize设定，取值范围为1MB～32MB，且应为2的N次幂。默认将整堆划分为2048个分区。
- 新年代和老年代不再物理隔离，都是逻辑概念。在G1中有一种特殊的区域，叫Humongous区域。如果一个对象占用的空间超过了Region容量50%以上，G1收集器就认为这是一个巨型对象。G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。
- 每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
