垃圾收集器之ZGC收集器

ZGC收集器(-XX:+UseZGC)

ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器。JDK 11只支持linux系统，JDK 14才支持了macOs和Windows系统

一 特点

1. 支持TB量级的堆。

这应该可以满足未来十年内，所有JAVA应用的需求了 吧。

2. 最大GC停顿时间不超10ms。

• 目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右， Major GC一般都需要100ms以上
• G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反

3. 最糟糕的情况下吞吐量会降低15%。

它的停顿时间不会随着堆的增大而增长！也就是说，几十G堆的停顿时间是 10ms以下，几百G甚至上T堆的停顿时间也是10ms以下

4. 不分代(暂时)

分代的原因是因为每个对象的生命周期不同，我们需要回收的时间也不同。ZGC不分代是因为暂时还没有实现这个功能，实现起来比较麻烦。

5. ZGC的Region可以具有大、 中、 小三类容量

小型Region（Small Region） ： 容量固定为2MB， 用于放置小于256KB的小对象。

中型Region（Medium Region） ： 容量固定为32MB， 用于放置大于等于256KB但小于4MB的对象。

大型Region（Large Region） ： 容量不固定， 可以动态变化， 但必须为2MB的整数倍， 用于放置4MB或 以上的大对象。 每个大型Region中 ，只会存放一个大对象

二 ZGC存在的问题

• ZGC最大的问题是浮动垃圾。1 ZGC没有分代概念，每次都需要进行全堆扫描，导致一些“朝生夕死”的对象没能及时的被回收。 所以就不存在Young GC、Old GC，所有的GC行为都是Full GC
• ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。

解决方案

目前唯一的办法是增大堆的容量，使得程序得到更多的喘息时间，但是这个也是一个治标不治本的方案。如果需要从根 本上解决这个问题，还是需要引入分代收集，让新生对象都在一个专门的区域中创建，然后专门针对这个区域进行更频繁、更快的收集。

三 ZGC运作过程

1. 并发标记（Concurrent Mark）

• 相当于SMS收集器的初始标记+并发标记+重新标记。
• 初始标记 (Mark Start)和最终标记(Mark End)也会出现短暂的停顿
• G1不同的是， ZGC的标记是在指针上而不是在对象上进行的， 标记阶段会更新染色指针中的Marked 0、 Marked 1标志位。

2. 并发预备重分配（Concurrent Prepare for Relocate）

• 这个阶段需要根据特定的查询条件统计得出本次收 集过程要清理哪些Region，将这些Region组成重分配集（Relocation Set）。
• ZGC每次回收都会扫描所有的 Region，用范围更大的扫描成本换取省去G1中记忆集的维护成本。

3. 并发重分配（Concurrent Relocate）

• 重分配是ZGC执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表（Forward Table），记录从旧对象到新对象的转向关系。
• 如果用户线程此时并 发访问了位于重分配集中的对象，这次访问将会根据Region上的转发表记录将访问转发到新复制的对象上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指 针的“自愈”（Self-Healing）能力。
• ZGC的颜色指针因为“自愈”（Self‐Healing）能力，所以只有第一次访问旧对象会变慢， 一旦重分配集中某个Region的存活对象都复制完毕 后， 这个Region就可以立即释放用于新对象的分配，但是转发表还得留着不能释放掉， 因为可能还有访问在使用这个转发表。

4. 并发重映射（Concurrent Remap）

• 重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用，
• 但 是ZGC中对象引用存在“自愈”功能，所以这个重映射操作并不是很迫切。
• ZGC很巧妙地把并发重映射阶段要做的 工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成，反正它们都是要遍历所有对象的，这样合并就节 省了一次遍历对象图的开销。一旦所有指针都被修正之后， 原来记录新旧对象关系的转发表就可以释放掉了。

2，3，4 步相当于是实现了CSM的并发清除，但是是使用的复制算法，

G1 在这一步是STW的，直接复制完需要存活的对象，修正对象的引用到新引用上就可以。ZGC需要再保留一份旧对象到新对象的转向关系，而且还需要再做一次旧数据的重映射。

四 ZGC触发时机

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

• 定时触发，默认为不使用，可通过ZCollectionInterval参数配置。

• 预热触发，最多三次，在堆内存达到10%、20%、30%时触发，主要时统计GC时间，为其他GC机制使用。

• 分配速率，基于正态分布统计，计算内存99.9%可能的最大分配速率，以及此速率下内存将要耗尽的时间点， 在耗尽之前触发GC（耗尽时间 - 一次GC最大持续时间 - 一次GC检测周期时间）。

• 主动触发，（默认开启，可通过ZProactive参数配置） 距上次GC堆内存增长10%，或超过5分钟时，对比距上 次GC的间隔时间跟（49 * 一次GC的最大持续时间），超过则触发。

五 如何选择垃圾收集器

1. 优先调整堆的大小让服务器自己来选择

2. 如果内存小于100M，使用串行收集器

3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择

4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选

5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

6. 4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC

JDK 1.8默认使用 Parallel(年轻代和老年代都是)

JDK 1.9默认使用 G1