G1与ZGC垃圾回收器

G1

-XX:+UseG1GC

概念

jdk8中也支持G1垃圾回收器，在JDK9时默认使用的是G1垃圾回收器。它适用于堆内存>8G 的场景。

G1垃圾收集器让我们忘记年龄分代的概念，但其实它还是有年龄分代的概念

G1将一整块堆内存，平均分成了默认2048个独立区域Region，JVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)，实际可以超过该值，但是不推荐。

其中年轻代默认占总堆内存的5%，最大占60%，这其中Eden区域Survivor区的比例还是8:1:1

首先创建对象，对象都是存放在Eden区的Region中，当放满后可能会触发MinorGC，将存活对象使用复制算法移动到Survivor区，然后程序继续运行，存活对象在Survivor区来回复制，当分代年龄达到15后就复制到老年代的Region中。对于大对象直接存放在Humongous区的Region中，当一个对象占用内存大于了Region内存是50%就是大对象。

从上面的执行过程中我们可以发现，每经过一次GC，Region的角色都会动态改变，可能从Old区变为空闲区，再变为Eden区。

垃圾收集过程

和CMS垃圾回收器类似，也有初始标记、并发标记。区别是CMS叫重新标记，G1叫最终标记，但其实是一样的；还有就是G1是筛选回收是STW的，充当了CMS的并发清理和并发重置阶段。

• 初始标记

• 并发标记

• 最终标记

  G1是使用的本地快照SATB的方式来处理漏标问题的

• 筛选回收

  G1会对要回收的Region进行回收价值和成本计算， 在后台维护一个回收优先级列表。再根据用户期望的GC最大停顿时间( -XX:MaxGCPauseMillis默认200ms)来进行回收内存，在回收时会优先回收存活对象较少的Region，因为如果存活对象少，在采用复制算法将存活对象复制到另一个Region中耗时要少。如果一个Region100的对象，其中95个对象都是存活对象，那么复制的意义就不大，而且复制95个对象很耗时。垃圾回收时如果达到了GC最大停顿时间那么剩余的Region就会等下一次GC再去进行回收。

垃圾收集分类

• MinorGC

  年轻代默认占总堆内存的5%，其中还有Survivor区，大概Eden区初始占4%左右。当Eden区的Region放满对象后可能就会触发一次MinorGC。

  因为它会计算这一次如果进行MinorGC过程中大概STW的耗时，默认STW最大停顿时间是200ms，如果这一次只需要50ms，那么就不会进行MinorGC，会增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，如果这一次MinorGC过程中SWT耗时接近200ms了，那么就开始进行MinorGC。

• MixGC

  当老年代的Region使用率占了总堆内存的45%(默认是45% 靠-XX:InitiatingHeapOccupancyPercent设置)，则触发mixGC，回收所有年轻代、部分老年代、部分大对象区。当然这里只是部分的Region区是会根据期望GC停顿时间来确定Region的优先回收顺序。

• FullGC

  当进行MixGC 使用复制算法，发现没有空闲的Region来支持进行复制时，则触发FullGC

  停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。

关键参数

G1的参数大部分都不建议我们修改，使用默认就可以

# 使用G1垃圾回收器
-XX:+UseG1GC

# 指定GC的线程数
-XX:ParallelGCThreads

# 指定一个Region的大小 1MB~32MB，且必须是2的N次幂 默认是将堆内存平均划分为2048个Region 
-XX:G1HeapRegionSize

# 目标暂停时间，单位毫秒
-XX:MaxGCPauseMillis

# 新生代内存初始空间，默认整堆5%，值配置整数，默认就是百分比
-XX:G1NewSizePercent

# 新生代最大内存空间，默认占堆60%
-XX:G1MaxNewSizePercen

# 对象动态年龄判断，Survivor区的填充容量(默认50%)
# Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
-XX:TargetSurvivorRatio

# 最大分代年龄阀值，默认15
-XX:MaxTenuringThreshold

# 老年代使用率达到了总堆内存阀值则触发MixGC，默认45%
-XX:InitiatingHeapOccupancyPercent

# 默认85%，一个Region中的存活对象低于85%才会回收这个Region，如果存活对象太多了则不回收
-XX:G1MixedGCLiveThresholdPercent

# 在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
-XX:G1MixedGCCountTarget

# 默认5%，在进行MixGC 复制存活对象时不断会有空闲Region出来，当空闲Region数量达到总堆内存的5%就结束本次MixGC
-XX:G1HeapWastePercent

G1垃圾回收器优化建议

主要是调整-XX:MaxGCPauseMills参数，如果这个时间设置很大，那么系统运行很久才会触发MinorGC，年轻代可能都占用了堆内存的60%了，然后就会有很多存活对象，这时Survivor区放不下就会进入到老年代区，或者是触发动态年龄判断机制，对象也直接进入到老年代区。

所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少，避免存活对象太多快速进入老年代，频繁触发mixed gc.

ZGC

参考文章：https://wiki.openjdk.java.net/display/zgc/Main

http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf

下面这些JDK版本有ZGC垃圾回收器

内存布局

ZGC收集器是一款基于Region内存布局的， 暂时不设分代的， 使用了读屏障、 颜色指针等技术来实现可并发的标记-整理算法的， 以低延迟为首要目标的一款垃圾收集器。

ZGC的Region可以具有如图3-19所示的大、 中、 小三类容量：

• 小型Region（Small Region） ： 容量固定为2MB， 用于放置小于256KB的小对象。
• 中型Region（Medium Region） ： 容量固定为32MB， 用于放置大于等于256KB但小于4MB的对象。
• 大型Region（Large Region） ： 容量不固定， 可以动态变化， 但必须为2MB的整数倍， 用于放置4MB或以上的大对象。 每个大型Region中只会存放一个大对象， 这也预示着虽然名字叫作“大型Region”， 但它的实际容量完全有可能小于中型Region， 最小容量可低至4MB。 大型Region在ZGC的实现中是不会被重分配（重分配是ZGC的一种处理动作， 用于复制对象的收集器阶段， 稍后会介绍到）的， 因为复制一个大对象的代价非常高昂。

NUMA

UMA即Uniform Memory Access Architecture，所有cpu都去访问同一块内存区域，可能会频繁产生争抢

NUMA就是Non Uniform Memory Access Architecture。将某一块内存区域有限分配给某个cpu去使用

运作过程

其中向下的黑色箭头是STW过程

• 并发标记Comcurrent Mark

  包括初始标记和最终标记，也是可达性分析算法，与G1和CMS不同的是，ZGC不是标记在对象头中，而是标记在对象的引用指针的。

  标记阶段会更新颜色指针

• 并发预备重分配Concurrent Prepare for Reloc

  统计要清理的Region，组成一个重分配集Relocation Set。

  ZGC每次都会去扫描所有的Region，用更大的扫描成本去换取G1中记忆集的维护成本

• 并发重分配Concurrent Relocate

  把重分配集Relocation Set中的存活对象复制到新的Region中，并为重分配集中每个Region维护一个转发表Forward Table。记录旧对象地址到新地址的转向关系。

  如果用户线程要读取对象被复制到了一个新的Region中去了，从当前旧的地址引用中我们就能知道一个对象是否在重分配集中，如果在则会经过读屏障 --> 转发表 -->新地址引用，并同时修正该引用的值使其执行对象的新地址，ZGC讲这种称为指针自愈

• 并发重映射Concurrent Remap

  重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用。因为ZGC有指针自愈的功能，就将并发重映射阶段合并到下一次并发标记阶段了，因为他们都需要遍历所有对象

颜色指针

Colored Pointers，即颜色指针，如下图所示，ZGC的核心设计之一。以前的垃圾回收器的GC信息都保存在对象头中，而ZGC的GC信息保存在指针中。

64位的指针不需要全部用来寻址，取其中的42位来进行寻址就可以了，42位就能够满足4TB内存的寻址

每个对象有一个64位指针，这64位被分为：

• 18位：预留给以后使用；
• 1位：Finalizable标识，此位与并发引用处理有关，它表示这个对象只能通过finalizer才能访问；
• 1位：Remapped标识，设置此位的值后，对象未指向relocation set中（relocation set表示需要GC的Region集合）；
• 1位：Marked1标识；
• 1位：Marked0标识，和上面的Marked1都是标记对象用于辅助GC；
• 42位：对象的地址（所以它可以支持2^42=4T内存）

为什么有2个mark标记？

每一个GC周期开始时，会交换使用的标记位，使上次GC周期中修正的已标记状态失效，所有引用都变成未标记。

GC周期1：使用mark0, 则周期结束所有引用mark标记都会成为01。

GC周期2：使用mark1, 则期待的mark标记10，所有引用都能被重新标记。

通过对配置ZGC后对象指针分析我们可知，对象指针必须是64位，那么ZGC就无法支持32位操作系统，同样的也就无法支持压缩指针了（CompressedOops，压缩指针也是32位）。

读屏障

之前的垃圾收集器是采用的写屏障，而ZGC使用的是读屏障

在标记和移动对象阶段，从堆中读取一个对象时会经过读屏障，根据这个对象的地址引用来判断这个指针是Bad Color还是Good Color，如果是Bad Color读屏障则把读出的指针更新到对象的新地址上，并且把堆里的这个指针“修正”到原本的字段里。如果指针是Good Color，那么正常往下执行即可

判断对象是Bad Color还是Good Color的依据是什么呢？就是根据上一段提到的Colored Pointers的4个颜色位。当加上读屏障时，根据对象指针中这4位的信息，就能知道当前对象是Bad/Good Color了。

ZGC触发时机

ZGC目前有4中机制触发GC：

• 定时触发，默认为不使用，可通过ZCollectionInterval参数配置。
• 预热触发，最多三次，在堆内存达到10%、20%、30%时触发，主要时统计GC时间，为其他GC机制使用。
• 分配速率，基于正态分布统计，计算内存99.9%可能的最大分配速率，以及此速率下内存将要耗尽的时间点，在耗尽之前触发GC（耗尽时间 - 一次GC最大持续时间 - 一次GC检测周期时间）。
• 主动触发，（默认开启，可通过ZProactive参数配置） 距上次GC堆内存增长10%，或超过5分钟时，对比距上次GC的间隔时间跟（49 * 一次GC的最大持续时间），超过则触发。

安全点与安全区域

安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样JVM就可以安全的进行一些操作,比如GC等，所以GC不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发。

这些特定的安全点位置主要有以下几种:

1. 方法返回之前
2. 调用某个方法之后
3. 抛出异常的位置
4. 循环的末尾

大体实现思想是当垃圾收集需要中断线程的时候， 不直接对线程操作， 仅仅简单地设置一个标志位， 各个线程执行过程时会不停地主动去轮询这个标志， 一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。 轮询标志的地方和安全点是重合的。

安全区域又是什么？

Safe Point 是对正在执行的线程设定的。

如果一个线程处于 Sleep 或中断状态，它就不能响应 JVM 的中断请求，再运行到 Safe Point 上。

因此 JVM 引入了 Safe Region。

Safe Region 是指在一段代码片段中，引用关系不会发生变化。在这个区域内的任意地方开始 GC 都是安全的。