G1收集器

JDK9将G1设置为默认的垃圾收集器，主要原因是：G1是一个低延迟垃圾回收器。

对于系统整体架构而言，往往会考虑响应能力和吞吐量两个方面。对java应用进行优化也主要是针对这两方面。

响应能力主要是指系统或应用返回请求数据的效率，对于要求响应能力的应用来说，长时间的停顿是不能接受的

吞吐量是指某个时间段能够处理的最大负载，比如每分钟处理多少事务，完成多少任务，对于要求吞吐量的应用来说，长时间的停顿是能接受的。高吞吐量关注的是系统处理任务的能力。

G1垃圾收集器

是面向服务端应用的垃圾收集器，有以下优点：

并行与并发：G1使用多个CPU来缩短Stop-The-World停顿的时间，与CMS一样可以通过并发的方式与java程序并行执行；

分代收集：与其他收集器一样，G1保留了分代收集的特性；

空间整合：整体是基于标记-整理，局部（Region之间）是基于复制算法实现的，保证了G1运行期间不会产生内存空间碎片；

可预测的停顿时间：减低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还建立了可预测的停顿时间模型。可以设定Stop-The-World的时间范围。

传统的垃圾收集器像Serial, Parallel, CMS全部都将Java堆分成三个固定内存大小的部分，如年轻代，年老代和永久代，所有的内存中的Java对象都在三个部分中结束。

heap区分成一定数量（代表性的2048）的小的heap区来分配对象。单个的区域可能是Eden区，Survivor区，Old区。所有逻辑的Eden区和Survivor区合称为Young代，所有的Old区组合在一起称为Old代：

G1收集器采用了不同的方法，它将整个Java堆分成2000个左右相同大小的堆区域（Region），这些区域集像以前的收集器一样被分配到不同的角色，如Eden, Survivor和Old, 但是没有固定的区域数量被明确固定在某个角色上，这将为内存使用上提供了更大的灵活性。

G1收集器的一个特性时能预测停顿时间。G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的由来）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

G1通过转移的方法将已被G1标识为区域当作可回收的垃圾进行回收，它把对象从1个或者多个区域中复制到单个区域，在复制的同时进行压缩对象和释放内存，所有的转移过程通过多个处理器并行处理以降低暂停时间和增加吞吐量。因此，每一次垃圾回收，G1收集器持续地在用户预定的暂停时间内减少内存碎片。相对而言，CMS收集器不会做压缩，而PARALlelOld收集器是对整个Java堆执行压缩，那么将导致较长停顿时间。

Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

参考：https://segmentfault.com/a/1190000007795862