JVM系列之垃圾回收器（二）

Garbage First 收集器

初始标记（Initial Marking）: 标记GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程
并发标记（Concurrent Marking）: 从GC Roots进行可达性分析，找出存活的对象，与用户线程并发
执⾏最终标记（Final Marking）: 修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程
筛选回收（Live Data Counting and Evacuation）:对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

特点：
1、G1是⼀款主要面向服务端应用的垃圾收集器，并行+并发。
2、更先进, CMS继承者和替代者。G1是一个面向全堆的收集器，不再需要其他新生代收集器的配合工作。
3、JDK9 中G1成为服务端模式下的默认垃圾收集器。
4、G1收集器的Mixed GC模式：它可以面向堆内存任何部分来组成回收集进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。
优点:
1、低延时，可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片断内，消耗在垃圾收集 上的时间不得超过N毫秒）
2、空间整合（整体上属于“标记-整理”算法，不会导致空间碎片）
缺点:
1、耗内存：G1收集器要比其他的传统垃圾收集器有着更高的内存占用负担。根据经验，G1至少要耗费大约相当于Java堆容量10%至20%的额外内存来维持收集器工作。（每个Region都维护有自己的记忆集，操作复杂，Region数量多）
2、如果内存回收的速度赶不上内存分配的速度，G1收集器也要被迫冻结用户线程执行，导致Full GC而产生长时间“Stop The World”
参数：
-XX:+UseG1GC 指定G1 gc
-XX：MaxGCPauseMillis 指定停顿时间，默认200毫秒，该值不是越低越好，低会导致gc频繁，垃圾回收缓慢，最终占满堆引发Full GC 反而降低性能（100-300ms相对合理）

Garbage First 设计目标

建立起“停顿时间模型”的收集器，停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间大概率不超过N毫秒这样的目标。

Garbage First 实现方式

基于Region：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的
Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬
过多次收集的旧对象都能获取很好的收集效果。
Humongous区域：专门用来存储大对象，G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX：G1HeapRegionSize
设定，取值范围为1MB～32MB，且应为2的N次幂。而对于那些超过了整个Region容量
的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都
把Humongous Region作为老年代的一部分来看待。

低延迟垃圾收集器-ZGC 收集器

特点：
1、JDK11 中新加⼊的具有实验性质的低延迟垃圾收集器，是由Oracle公司研发的。
2、ZGC目标希望在尽可能对吞吐量影响不太大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。
3、ZGC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低延迟为首要目标的一款垃圾收集器。
优点：低延时，吞吐量高（超越G1）
缺点：实验室状态，还未完全成熟