6种虚拟机垃圾收集器，CMS和G1重点

本文转载自JVM(HotSpot) 7种垃圾收集器的特点及使用场景 - RedAnts - 博客园

1.CMS收集器 并发标记清除收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求

CMS收集器是基于“标记-清除”算法实现的。它的运作过程相对前面几种收集器来说更复杂一些，整个过程分为4个步骤：

（1）初始标记

（2）并发标记

（3）重新标记

（4）并发清除

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”.

CMS收集器主要优点：并发收集，低停顿。

CMS三个明显的缺点：

（1）CMS收集器对CPU资源非常敏感。CPU个数少于4个时，CMS对于用户程序的影响就可能变得很大，为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种。所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想

（2）CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中蓝年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK1.6中，CMS收集器的启动阀值已经提升至92%。

（3）CMS是基于“标记-清除”算法实现的收集器，手机结束时会有大量空间碎片产生。空间碎片过多，可能会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发FullGC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间变长了。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction,这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，标识每次进入Full GC时都进行碎片整理）

2. G1收集器

G1收集器的优势：

（1）并行与并发

（2）分代收集

（3）空间整理 （标记整理算法，复制算法）

（4）可预测的停顿（G1处处理追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经实现Java（RTSJ）的来及收集器的特征）

使用G1收集器时，Java堆的内存布局是整个规划为多个大小相等的独立区域（Region）,虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region的集合。

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

G1 内存“化整为零”的思路

在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为一下步骤：

（1）初始标记

（2）并发标记

（3）最终标记

（4）筛选回收

G1的底层结构
G1将内存划分为大小一致（1M ~ 32M）的小块内存，我们称每块内存为region。

这些region可以属于不同的内存分代，可以是老年代、Eden区、Survivor区，或者是H区用来代表大对象。如下图所示：

 
与这个底层内存结构相适应的有两个概念需要记住，分别是CSet和RSet。

 

CSet：也叫Collection Set，这个set中装着需要被回收的region。

RSet：也叫Remembered Set，每个region都有一个RSet，记录着有哪些region中有引用指向本region中的对象。这个set可以有效提高垃圾回收的效率。

并且需要注意的一点是，G1维护的内存中，青年代和老年代的比例并不是固定的，而是根据GC的表现进行动态调整。

比如，如果YGC的时间太长，就会将青年代的内存空间调的小一点。

G1的垃圾回收触发顺序
与之前介绍过的几种垃圾回收器组合相同，G1也存在YGC与FGC，不过，G1还有一种Mixed GC的机制。

这里有个JVM的参数需要注意一下：XX:InitiatingHeapOccupacyPercent，这个参数的默认值是45%。

当堆空间占用率小于这个参数的时候，只有YGC会被触发。在YGC的模式下，只有之前提到的被划分为Eden区的和Survivor区的region会被回收。

当堆空间的占用率超过这个参数指定的阈值后，Mixed GC就被触发了。 可以把Mixed GC就理解成CMS，因为Mixed GC与CMS很相似。也有四个阶段，与CMS想对应，分别是初始标记，并发标记，重新标记与并行筛选回收。

关于CMS的内容在这篇文章已经介绍过了。

当堆空间再也分配不下新对象的时候，FGC就会被触发。在G1中，我们要做的就是绝对不要让FGC被触发。

所以要记住，如果发现G1的FGC被触发了，就要调低Mixed GC的阈值，让Midxed GC提早工作，预留出充足的空间。

到这里关于G1的基本运行原理算是介绍完毕了，下面我们来探讨一个无论在CMS还是在G1中，都是一个绕不开的核心问题——如何做到在重新标记阶段，找到那些引用关系发生改变的对象呢？

这就不得不介绍下面的三色标记法了。

三色标记法
既然是三色标记法，顾名思义，就是用三种颜色来标记内存中的对象，这三种颜色表示不同的意义。

下面就是内存中的对象可能出现的三种颜色，以及它们表示的意义：

黑色：对象本身与其成员变量均已标记完成。
灰色：对象本身被标记了，但是它的成员变量还没有被标记完成
白色：未被标记的对象。

下面用张图直观的表示一下：

上面这张图中，B和C都是A的成员变量，D是B的成员变量。

由于A和C的本身以及它们的成员变量都被标记过了，所以它们自己就被标记为黑色。

而由于D是未被标记的白色，B只能是被部分标记的灰色。

用这种三色标记法，就可以保证，遍历完对象树之后，所有被标上颜色的对象，都是存活对象。

但是三色标记法也有其问题所在。

三色标记法的问题与解决办法
三色标记法就发生在CMS和G1的Mixed GC的并发标记阶段。

所以三色标记法没法解决引用关系发生改变的情况。

比如漏标问题，我们继续拿上面的图举例子。

如果发生了B对D的引用转移到了A中，就会成为下面这种情况。

由于A的新成员变量D是未被标记的白色，而理应是灰色的A已经被标成了黑色，这就会导致整个三色标记法规则的崩溃。

 

为了解决三色标记法的这种问题，CMS与Mixed GC选择了下面这两种不同的方式：

incremental update

增加了新引用的对象会被重新标记为灰色。

在重新标记阶段对这个对象重新进行扫描。

拿上面的例子来说，如果A新增加了一个指向D的引用，那么就把A重新标记为灰色，然后等重新标记阶段对A的所有引用（A->B、A->C、A->D）进行扫描。

这是CMS采用的解决方案。问题就在于，这个解决方法的效率并不高，仅仅由于新增了一个新的引用，就要把该对象所有的引用都扫描一遍。

因此提出了下面这种解决方案。

SATB

全称为Snapshot At The Beginning。

这个方法有三个步骤：

在开始标记的时候，会生成一个所有对象的快照图。
在并发标记的过程中，如果发生了引用消失的情况，就将这个引用存到一个堆栈中。
在重新标记阶段，会对这个堆栈中的所有引用进行扫描。
这种方法与之前提到过的RSet浑然天成。

在重新标记阶段，只需要扫描消失引用所指向的对象的RSet就能确定，这个对象有没有被别的引用指向了。

而G1中的Mixed GC就采用了这种方法来进行标记。

总结
本文从内存结构开始介绍了G1的运行原理，并且介绍了G1中不同的GC触发阶段。

后来介绍了G1与CMS中用来标记存活对象的三色标记法，以及如何修正并发标记过程中产生的引用变化的问题。
 

3.Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器。是单线程的收集器。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集完成。

Serial收集器依然是虚拟机运行在Client模式下默认新生代收集器，对于运行在Client模式下的虚拟机来说是一个很好的选择。

4.ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Worl、对象分配规则、回收策略等都与Serial 收集器完全一样。

ParNew收集器是许多运行在Server模式下的虚拟机中首选新生代收集器，其中有一个与性能无关但很重要的原因是，除Serial收集器之外，目前只有ParNew它能与CMS收集器配合工作。

5.Parallel Scavenge（并行回收）收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器

该收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即 吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

停顿时间越短就越适合需要与用户交互的程序，良好

的响应速度能提升用户体验，而高吞吐量则可用高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供两个参数用于精确控制吞吐量，分别是控制最大垃圾收起停顿时间的

-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数

Parallel Scavenge收集器还有一个参数：-XX:+UseAdaptiveSizePolicy。这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数，只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGVPauseMillis参数或GCTimeRation参数给虚拟机设立一个优化目标。

自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别

4.Serial Old 收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记整理算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

如果在Server模式下，主要两大用途：

（1）在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用

（2）作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

Serial Old收集器的工作工程

5.Parallel Old 收集器

Parallel Old 是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器在1.6中才开始提供。

ZGC（Z Garbage Collector） 是一款性能比 G1 更加优秀的垃圾收集器。ZGC 第一次出现是在  JDK 11 中以实验性的特性引入，这也是 JDK 11 中最大的亮点。在 JDK 15 中 ZGC 不再是实验功能，可以正式投入生产使用了，使用 –XX:+UseZGC 可以启用 ZGC。

JDK 16 发布后，GC 暂停时间已经缩小到 1 ms 以内，并且时间复杂度是 o(1)，这也就是说 GC 停顿时间是一个固定值了，并不会受堆内存大小影响。

1 内存多重映射

内存多重映射，就是使用 mmap 把不同的虚拟内存地址映射到同一个物理内存地址上。如下图：

ZGC 为了更灵活高效地管理内存，使用了内存多重映射，把同一块儿物理内存映射为 Marked0、Marked1 和 Remapped 三个虚拟内存。

当应用程序创建对象时，会在堆上申请一个虚拟地址，这时 ZGC 会为这个对象在 Marked0、Marked1 和 Remapped 这三个视图空间分别申请一个虚拟地址，这三个虚拟地址映射到同一个物理地址。

Marked0、Marked1 和 Remapped 这三个虚拟内存作为 ZGC 的三个视图空间，在同一个时间点内只能有一个有效。ZGC 就是通过这三个视图空间的切换，来完成并发的垃圾回收。

2 染色指针

2.1 三色标记回顾

我们知道 G1 垃圾收集器使用了三色标记，这里先做一个回顾。下面是一个三色标记过程中的对象引用示例图：

总共有三种颜色，说明如下：

• 白色：本对象还没有被标记线程访问过。

• 灰色：本对象已经被访问过，但是本对象引用的其他对象还没有被全部访问。

• 黑色：本对象已经被访问过，并且本对象引用的其他对象也都被访问过了。

三色标记的过程如下：

1. 初始阶段，所有对象都是白色。

2. 将 GC Roots 直接引用的对象标记为灰色。

3. 处理灰色对象，把当前灰色对象引用的所有对象都变成灰色，之后将当前灰色对象变成黑色。

4. 重复步骤 3，直到不存在灰色对象为止。

三色标记结束后，白色对象就是没有被引用的对象（比如上图中的 H  和 G），可以被回收了。

2.2 染色指针

ZGC 出现之前， GC 信息保存在对象头的 Mark Word 中。比如 64 位的 JVM，对象头的 Mark Word 中保存的信息如下图：

前 62位保存了 GC 信息，最后两位保存了锁标志。

ZGC 的一大创举是将 GC 信息保存在了染色指针上。染色指针是一种将少量信息直接存储在指针上的技术。在 64 位 JVM  中，对象指针是 64 位，如下图：

在这个 64 位的指针上，高 16 位都是 0，暂时不用来寻址。剩下的 48 位支持的内存可以达到 256 TB（2 ^48）,这可以满足多数大型服务器的需要了。不过 ZGC 并没有把 48 位都用来保存对象信息，而是用高 4 位保存了四个标志位，这样 ZGC 可以管理的最大内存可以达到 16 TB（2 ^ 44）。

通过这四个标志位，JVM 可以从指针上直接看到对象的三色标记状态（Marked0、Marked1）、是否进入了重分配集（Remapped）、是否需要通过 finalize 方法来访问到（Finalizable）。

无需进行对象访问就可以获得 GC 信息，这大大提高了 GC 效率。

3 内存布局

首先我们回顾一下 G1 垃圾收集器的内存布局。G1把整个堆分成了大小相同的 region，每个堆大约可以有 2048 个region，每个 region 大小为 1~32 MB （必须是 2 的次方）。如下图：

跟 G1 类似，ZGC 的堆内存也是基于 Region 来分布，不过 ZGC 是不区分新生代老年代的。不同的是，ZGC 的 Region 支持动态地创建和销毁，并且 Region 的大小不是固定的，包括三种类型的 Region ：

• Small Region：2MB，主要用于放置小于 256 KB 的小对象。

• Medium Region：32MB，主要用于放置大于等于 256 KB 小于 4 MB 的对象。

• Large Region：N * 2MB。这个类型的 Region 是可以动态变化的，不过必须是 2MB 的整数倍，最小支持 4 MB。每个 Large Region 只放置一个大对象，并且是不会被重分配的。

4 读屏障

读屏障类似于 Spring AOP 的前置增强，是 JVM 向应用代码中插入一小段代码，当应用线程从堆中读取对象的引用时，会先执行这段代码。注意：只有从堆内存中读取对象的引用时，才会执行这个代码。下面代码只有第一行需要加入读屏障。

Object o = obj.FieldA
Object p = o //不是从堆中读取引用
o.dosomething() //不是从堆中读取引用
int i =  obj.FieldB //不是引用类型

读屏障在解释执行时通过 load 相关的字节码指令加载数据。作用是在对象标记和转移过程中，判断对象的引用地址是否满足条件，并作出相应动作。如下图：

标记、转移和重定位这些过程请看下一节。

读屏障会对应用程序的性能有一定影响，据测试，对性能的最高影响达到 4%，但提高了 GC 并发能力，降低了 STW。

5 GC 过程

前面已经讲过，ZGC 使用内存多重映射技术，把物理内存映射为 Marked0、Marked1 和 Remapped 三个地址视图，利用地址视图的切换，ZGC 实现了高效的并发收集。

ZGC 的垃圾收集过程包括标记、转移和重定位三个阶段。如下图：

ZGC 初始化后，整个内存空间的地址视图被设置为 Remapped。

5.1 初始标记

从 GC Roots 出发，找出 GC Roots 直接引用的对象，放入活跃对象集合，这个过程需要 STW，不过 STW 的时间跟 GC Roots 数量成正比，耗时比较短。

5.2 并发标记

并发标记过程中，GC 线程和 Java 应用线程会并行运行。这个过程需要注意下面几点：

• GC 标记线程访问对象时，如果对象地址视图是 Remapped，就把对象地址视图切换到 Marked0，如果对象地址视图已经是 Marked0，说明已经被其他标记线程访问过了，跳过不处理。

• 标记过程中Java 应用线程新创建的对象会直接进入 Marked0 视图。

• 标记过程中Java 应用线程访问对象时，如果对象的地址视图是 Remapped，就把对象地址视图切换到 Marked0，可以参考前面讲的读屏障。

• 标记结束后，如果对象地址视图是 Marked0，那就是活跃的，如果对象地址视图是 Remapped，那就是不活跃的。

标记阶段的活跃视图也可能是 Marked1，为什么会采用两个视图呢？

这里采用两个视图是为了区分前一次标记和这一次标记。如果这次标记的视图是 Marked0，那下一次并发标记就会把视图切换到 Marked1。这样做可以配合 ZGC 按照页回收垃圾的做法。如下图：

第二次标记的时候，如果还是切换到 Marked0，那么 2 这个对象区分不出是活跃的还是上次标记过的。如果第二次标记切换到 Marked1，就可以区分出了。

这时 Marked0 这个视图的对象就是上次标记过程被标记过活跃，转移的时候没有被转移，但这次标记没有被标记为活跃的对象。Marked1 视图的对象是这次标记被标记为活跃的对象。Remapped 视图的对象是上次垃圾回收发生转移或者是被 Java 应用线程访问过，本次垃圾回收中被标记为不活跃的对象。

5.3 再标记

并发标记阶段 GC 线程和 Java 应用线程并发执行，标记过程中可能会有引用关系发生变化而导致的漏标记问题。再标记阶段重新标记并发标记阶段发生变化的对象，还会对非强引用（软应用，虚引用等）进行并行标记。

这个阶段需要 STW，但是需要标记的对象少，耗时很短。

5.4 初始转移

转移就是把活跃对象复制到新的内存，之前的内存空间可以被回收。

初始转移需要扫描 GC Roots 直接引用的对象并进行转移，这个过程需要 STW，STW 时间跟 GC Roots 成正比。

5.5 并发转移

并发转移过程 GC 线程和 Java 线程是并发进行的。上面已经讲过，转移过程中对象视图会被切回 Remapped 。转移过程需要注意以下几点：

• 如果 GC 线程访问对象的视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。

• 如果 GC 线程访问对象的视图是 Remapped，说明被其他 GC 线程处理过，跳过不再处理。

• 并发转移过程中 Java 应用线程创建的新对象地址视图是 Remapped。

• 如果 Java 应用线程访问的对象被标记为活跃并且对象视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。

5.6 重定位

转移过程对象的地址发生了变化，在这个阶段，把所有指向对象旧地址的指针调整到对象的新地址上。

6 垃圾收集算法

ZGC 采用标记 - 整理算法，算法的思想是把所有存活对象移动到堆的一侧，移动完成后回收掉边界以外的对象。如下图：

6.1 JDK 16 之前

在 JDK 16 之前，ZGC 会预留（Reserve）一块儿堆内存，这个预留内存不能用于 Java 线程的内存分配。即使从 Java 线程的角度看堆内存已经满了也不能使用 Reserve，只有 GC 过程中搬移存活对象的时候才可以使用。如下图：

这样做的好处是算法简单，非常适合并行收集。但这样做有几个问题：

• 因为有预留内存，能给 Java 线程分配的堆内存小于 JVM 声明的堆内存。

• Reserve 仅仅用于存放 GC 过程中搬移的对象，有点内存浪费。

• 因为 Reserve 不能给 GC 过程中搬移对象的 Java 线程使用，搬移线程可能会因为申请不到足够内存而不能完成对象搬移，这返回过来又会导致应用程序的 OOM。

6.2 JDK 16 改进

JDK 16 发布后，ZGC 支持就地搬移对象（G1 在 Full GC 的时候也是就地搬移）。这样做的好处是不用预留空闲内存了。如下图：

不过就地搬移也有一定的挑战。比如：必须考虑搬移对象的顺序，否则可能会覆盖尚未移动的对象。这就需要 GC 线程之间更好的进行协作，不利于并发收集，同时也会导致搬移对象的 Java 线程需要考虑什么可以做什么不可以做。

为了获得更好的 GC 表现，JDK 16 在支持就地搬移的同时，也支持预留（Reserve）堆内存的方式，并且 ZGC 不需要真的预留空闲的堆内存。默认情况下，只要有空闲的 region，ZGC 就会使用预留堆内存的方式，如果没有空闲的 region，否则 ZGC 就会启用就地搬移。如果有了空闲的 region， ZGC 又会切换到预留堆内存的搬移方式。

7 总结

内存多重映射和染色指针的引入，使 ZGC 的并发性能大幅度提升。

ZGC 只有 3 个需要 STW 的阶段，其中初始标记和初始转移只需要扫描所有 GC Roots，STW 时间 GC Roots 的数量成正比，不会耗费太多时间。再标记过程主要处理并发标记引用地址发生变化的对象，这些对象数量比较少，耗时非常短。可见整个 ZGC 的 STW 时间几乎只跟 GC Roots 数量有关系，不会随着堆大小和对象数量的变化而变化。

ZGC 也有一个缺点，就是浮动垃圾。因为 ZGC 没有分代概念，虽然 ZGC 的 STW 时间在 1ms 以内，但是 ZGC 的整个执行过程耗时还是挺长的。在这个过程中 Java 线程可能会创建大量的新对象，这些对象会成为浮动垃圾，只能等下次 GC 的时候进行回收。