浅谈JVM垃圾回收器相关知识点

Posted 默辨

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了浅谈JVM垃圾回收器相关知识点相关的知识，希望对你有一定的参考价值。

万字长文总结JVM垃圾回收器相关知识点



一、先说JVM内存模型

说到JVM知识点，首先第一步需要做的就是认识JVM是什么，以及对应的JVM内存模型。

模型图片都大同小异，记住关键点即可

1、JVM大致分为堆、线程栈、本地方法栈、程序计数器、方法区等几个大块

2、线程栈是一个先进后出的数据结构，线程栈内部分为一个一个的栈帧。栈帧内部主要包含局部变量表、操作数栈、动态链接、方法出口等，类比理解为记录方法执行顺序的容器。

在理解了线程栈帧间交互的基础上，有兴趣的小伙伴可以看看这个案例：终于弄明白 i = i++和 i = ++i 了

3、方法区主要存放类的类元信息，类比理解为User类的模板，即user.getClass()。该区域还包含一些常量

4、堆主要是存放我们new出来的对象

我们可以把堆抽象为面向对象，栈帧抽象为面向过程。




二、引出JVM调优的目标——对象

Java作为面向对象语言，自然离不开创建大量的对象。大部分情况对象都是存放在栈上，但是也可以存在堆上，这就可以引出下面的一些对象分配的方法论。

栈

1、逃逸分析分配在栈上

通过逃逸分析确定该对象不会被外部访问，如果不会被外部引用，表示不会逃逸，则可以将该对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中。JVM对于这种情况可以通过开启逃逸分析参数（-XX:+DoEscapeAnalysis）来优化对象内存分配位置，使其通过标量替换优先分配在栈上，JDK7之后默认开启逃逸分析，如果要关闭使用参数（-XX:-DoEscapeAnalysis）。


标量替换：通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间，这样就不会因为没有一大块连续空间导致对象内存不够分配。JDK7之后默认开启。

标量与聚合量：标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。JAVA中对象就是可以被进一步分解的聚合量。



堆

2、大量的对象被分配在eden区

eden区满了后会触发minor gc，可能会有99%以上的对象成为垃圾被回收掉，剩余存活的对象会被挪到为空的那块survivor区，下一次eden区满了后又会触发minor gc，把eden区和survivor区垃圾对象回收，把剩余存活的对象一次性挪动到另外一块为空的survivor区。在满足一定条件后，最终对象进入老年代。

虚拟机采用了分代收集（后文会解释这个说法是不准确的）的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。

如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。



3、大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。



4、动态年龄判断

当前存放对象的Survivor区域里（其中一块区域，放对象的那块s区），一批对象的总大小大于这块Survivor区域内存大小的50%（-XX:TargetSurvivorRatio可以指定），那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n（含）以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年龄判断机制一般是在minor gc之后触发的。

总结一句话，就是Survivor区域对象超过空间的指定大小（可参数设置），就直接将相对年龄最大的对象转移到老年代（前文第二点进入老年代的条件侧重的是，在空间充足的情况下根据参数设置的绝对年龄）。



补充：

对象存活代数只能小于等于15：

这跟对象头的内存布局有关，分配给对象用来计数存活代数的空间只有4bit：无锁、偏向锁、轻量级锁、重量级锁，完整的锁升级！


老年代空间分配担保机制：

该机制不涉及对象分配，年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间。

如果老年代剩余空间大于年轻代空间的所有对象，直接跳过其他操作，完成该次minor gc。

如果老年代剩余空间小于年轻代空间的所有对象（表示空间不够用），此时判断“-XX:-HandlePromotionFailure”（jdk1.8默认含有该设置）的参数是否设置。如果没有配置，直接进行full gc（包含minor gc），full gc之后老年代剩余空间还是小于年轻代所有存活对象占用空间，则OOM。

如果老年代剩余空间小于年轻代空间的所有对象（表示空间不够用），并且设置了对应的空间担保机制参数，就会将老年代剩余空间和之前minor gc后进入老年代的平均大小进行比较，如果剩余空间大于平均值，则还是回到之前的minor gc。否则就进入full gc，full gc之后老年代剩余空间还是小于年轻代所有存活对象占用空间，则OOM。

该机制的目的为为full gc添加一层判断，继而减少full gc的频率，减少程序的STW时间。




三、寻找垃圾对象算法

上面有说到，对象的创建，有创建自然就会有回收。这就可以引入如何寻找垃圾的方法

1、引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。 所谓对象之间的相互引用问题，如下面代码所示：除了对象objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为0，于是引用计数算法无法通知 GC 回收器回收他们。



2、可达性分析算法

将GC Roots 对象作为起点，从这些节点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的对象都是垃圾对象

GC Roots根节点：线程栈的本地变量、静态变量、本地方法栈的变量等等





四、回收垃圾对象算法

垃圾找到了，那如何处理这些垃圾？这就引出对应的垃圾收集理论。

1、分代收集理论

该理论是在JDK8之前的主流垃圾回收器的垃圾对象回收算法理论

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象（近99%）死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。



在该理论的基础上，就可以引出老生常谈的三个垃圾回收算法

标记-复制算法

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。


标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象（一般选择这种）；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法，比较简单，但是会带来两个明显的问题：

  1. 效率问题（如果需要标记的对象太多，效率不高）
  2. 空间问题（标记清除后会产生大量不连续的碎片）

标记-整理算法

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。


这三个算法在分代收集算法体现的垃圾回收器上灵活使用，针对不同代、区域使用不同的算法。



2、分区收集理论

不再严格的将堆内存进行大块内存的切分，而是切分成一个一个的小块（G1里的Region）

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间region。

每一个小区间都独立使用，独立回收，这种算法的好处是可以控制一次回收多少个小区间



3、增量收集算法

如果一次性将所有垃圾进行处理，需要造成系统长时间的停顿，那么我们可以让垃圾收集线程饿应用线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量垃圾收集算法的基础仍然是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

使用这种方式的缺点为，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。




五、处理垃圾对象算法的垃圾回收器

回收垃圾对象的方法论是有了，那么就一定会有具体的垃圾回收器来实现这个垃圾回收算法。这就好比有了类，自然就需要new一个类，创建一个具体的对象

1、传统垃圾回收器

虚线以上是处理年轻代对象，虚线以下是处理老年代对象

可以将上面的垃圾回收器集中理解一下。JVM刚开始发展必然是单线程开始，所以研制了Serial - Serial Old这一组垃圾回收期。后随着技术的不断发展，开始研发对应的多线程垃圾回收期Parallel - Parallel Old。由于Parallel Old中full gc时间过长，于是优化了 Parallel Old老年代的垃圾回收器，引入了CMS，但由于CMS与 Parallel不兼容，于是为CMS垃圾回收器引入了ParNew垃圾回收器，用来配合处理年轻代的垃圾对象。

当然，根据图片我们也能看到Serial和CMS也能配合使用、ParNew和Serial Old也能配合使用、Parallel和Serial Old也能配合使用


以上垃圾回收器基本都是新生代采用复制算法，老年代采用标记-整理算法的逻辑。



2、CMS（重要）

这里需要着重说一下CMS垃圾回收器，因为这款垃圾回收器，你能在未来的G1、ZGC等垃圾回收器上看到影子

1）清理流程

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

  • 初始标记： 暂停所有的其他线程（STW），并记录下gc roots直接能引用的对象，速度很快。
  • 并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
  • 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。
  • 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理（见下面三色标记算法详解）
  • 并发重置：重置本次GC过程中的标记数据。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

  • 对CPU资源敏感（会和服务抢资源）；
  • 无法处理浮动垃圾（在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了）；
  • 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让JVM在执行完标记清除后再做整理
  • 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用Serial Old垃圾收集器来回收，此时触发了上面的那条红线，这是我们不愿意看到的情形。



2）并发标记——三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

这里我们引入“三色标记”来给大家解释下，把GC Roots可达性分析遍历对象过程中遇到的对象， 按照“是否访问过”这个条件标记成以下三种颜色：

  • 黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。

  • 灰色： 表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。

  • 白色： 表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。


下图表示为以a节点为root节点，向下进行三色标记扫描的过程中。此时A对象内部调用了B对象，B对象内部又包含了C对象和D对象。当前时刻为，根节点a对象完成第一轮扫描，A对象被标记为黑色节点，并发标记阶段A节点向下遍历，找到存在B对象引用，发现B节点内部还有C和D两个节点，所以把B节点标记为灰色，并向下开始遍历，遍历完C节点之后，发现C内部没有其他引用，于是标记为黑色，于此同时B的另一个节点D还没有开始遍历，所以D节点还是最开始的白色。前文描述的就是下文的场景。

接下来会遍历D节点，如果D节点内部不存在其他的引用，这个时候D节点同样也会被标记为黑色，最后向上回溯，以至于B节点也变成黑色。这个过程中没有存在引用的对象，自然也就不会变色，即还是原始的白色。垃圾回收的时候就保留黑色，清除白色。



3）重新标记——多标、漏标

1、并发标记的时候不是垃圾，并发清理的时候是垃圾（多标-浮动垃圾）

在并发标记过程中，如果由于方法运行结束导致部分局部变量（gc root）被销毁，这个gc root引用的对象之前又被扫描过（被标记为非垃圾对象），那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记（还有并发清理）开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。


2、并发标记的时候是垃圾，并发清理的时候不是垃圾（漏标-读写屏障）

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（Incremental Update） 和原始快照（Snapshot At The Beginning，SATB）

  • 增量更新：

当黑色对象插入新的指向白色对象的引用关系时， 就将这个新插入的引用记录下来， 等并发扫描结束之后， 再将这些记录过的引用关系中的黑色对象为根， 重新扫描一次。 这可以简化理解为， 黑色对象一旦新插入了指向白色对象的引用之后， 它就变回灰色对象了。即以引用关系中的黑色对象为起点，再次进行节点的扫描，避免漏标。

  • 原始快照：

当灰色对象要删除指向白色对象的引用关系时， 需要将这个要删除的引用记录下来， 在并发扫描结束之后， 再以这些记录过的引用关系中的灰色对象为根， 重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色（目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾）

以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过写屏障实现的。


在Java HotSpot VM中，对并发标记时对漏标的处理方案如下：

  • CMS：写屏障 + 增量更新
  • G1、Shenandoah：写屏障 + 原始快照
  • ZGC：读屏障



为什么G1用SATB？CMS用增量更新？

SATB相对增量更新效率会高（当然SATB可能造成更多的浮动垃圾），因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的Region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。



3、G1

1）基础介绍

G1 （Garbage-First）是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征

G1将Java堆划分为多个大小相等的独立区域（Region），JVM目标是不超过2048个Region（JVM源码里TARGET_REGION_NUMBER 定义），实际可以超过该值，但是不推荐。

一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。

G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。即老年代和年轻代逻辑上分代，物理上不分。


G1垃圾收集器对于对象什么时候会转移到老年代与分代收集理论相同，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。

Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。



2）清理流程

G1收集器一次GC（主要值Mixed GC）的运作过程大致分为以下几个步骤：

  • 初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

  • 并发标记（Concurrent Marking）：同CMS的并发标记

  • 最终标记（Remark，STW）：同CMS的重新标记

  • 筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region（Collection Set，要回收的集合），尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。（注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本）


G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region（这也就是它的名字Garbage-First的由来），比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。



被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点（即CMS的本质）：

  • 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
  • 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
  • 空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
  • 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。



3）YoungGC

YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC


4）MixedGC

不是FullGC，老年代的堆占有率达到参数（-XX:InitiatingHeapOccupancyPercent）设定的值则触发，回收所有的Young和部分Old（根据期望的GC停顿时间确定old区垃圾收集的优先顺序）以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC


5）Full GC

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




4、ZGC

1）基础介绍

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

ZGC的Region可以看作大、 中、 小三类容量：

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



2）清理流程

ZGC的运作过程大致可划分为以下四个大的阶段：

  • 并发标记（Concurrent Mark）：与G1一样，并发标记是遍历对象图做可达性分析的阶段，它的初始标记（Mark Start）和最终标记（Mark End）也会出现短暂的停顿，与G1不同的是， ZGC的标记是在指针上而不是在对象上进行的， 标记阶段会更新颜色指针（后文有详解）中的Marked 0、 Marked 1标志位。
  • 并发预备重分配（Concurrent Prepare for Relocate）：这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region，将这些Region组成重分配集（Relocation Set）。ZGC每次回收都会扫描所有的Region，用范围更大的扫描成本换取省去G1中记忆集的维护成本。
  • 并发重分配（Concurrent Relocate）：重分配是ZGC执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表（Forward Table），记录从旧对象到新对象的转向关系。ZGC收集器能仅从引用上就明确得知一个对象是否处于重分配集之中，如果用户线程此时并发访问了位于重分配集中的对象，这次访问将会被预置的内存屏障（读屏障）所截获，然后立即根据Region上的转发表记录将访问转发到新复制的对象上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指针的“自愈”（Self-Healing）能力。
  • 并发重映射（Concurrent Remap）：重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用，但是ZGC中对象引用存在“自愈”功能，所以这个重映射操作并不是很迫切。ZGC很巧妙地把并发重映射阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成，反正它们都是要遍历所有对象的，这样合并就节省了一次遍历对象图的开销。一旦所有指针都被修正之后， 原来记录新旧对象关系的转发表就可以释放掉了。



3）颜色指针

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

每个对象有一个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位）。

颜色指针的三大优势：

  1. 一旦某个Region的存活对象被移走之后，这个Region立即就能够被释放和重用掉，而不必等待整个堆中所有指向该Region的引用都被修正后才能清理，这使得理论上只要还有一个空闲Region，ZGC就能完成收集。
  2. 颜色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量，ZGC只使用了读屏障。
  3. 颜色指针具备强大的扩展性，它可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据，以便日后进一步提高性能。



4）存在的问题

ZGC最大的问题是浮动垃圾。ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。假如ZGC全过程需要执行10分钟，在这个期间由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只能在下次GC的时候进行回收，这些只能等到下次GC才能回收的对象就是浮动垃圾。

ZGC没有分代概念，每次都需要进行全堆扫描，导致一些“朝生夕死”的对象没能及时的被回收。


解决方案

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




六、如何选择

垃圾回收器这么多，那如何选择呢？

  1. 优先调整堆的大小让服务器自己来选择
  2. 如果内存小于100M，使用串行收集器
  3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
  4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选
  5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器
  6. 4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC

以上是关于浅谈JVM垃圾回收器相关知识点的主要内容，如果未能解决你的问题，请参考以下文章

《深入理解JAVA虚拟机》垃圾回收时为什么会停顿

最新 JVM 垃圾回收器 Shenandoah GC 的实践案例

JVM中的垃圾回收器及垃圾收集算法描述

浅谈PHP5中垃圾回收算法

带你整理面试过程中关于 JVM 的运行内存划分垃圾回收算法和 4种引用类型的相关知识点

JVM——垃圾回收