面试再问垃圾收集器，把这篇文章扔给面试官

四大垃圾回收器

• 串行垃圾回收器（Serial）：为单线程环境设置并且只使用一个线程进行垃圾回收，会暂停所有的用户线程，不适合服务器环境；
• 并行垃圾回收器（Parallel）：Serial垃圾回收器的多线程版本，会开启多个线程进行垃圾回收，仍然会暂停所有的用户线程，速度较快，适用于科学计算或者大数据处理；
• 并发垃圾回收器（CMS）：用户线程和垃圾回收线程同时执行（不一定是并行，可能是交替执行），不需要暂停用户线程，适用于对响应时间要求严格的应用；
• G1垃圾回收器：将堆内存分割成不同的区域（Region）然后进行垃圾回收，并不存在明显的新生代和老年代；

默认垃圾回收器、配置

• 查看默认的垃圾回收器：java -XX:+PrintCommandLineFlags -version，Java8默认使用ParallelGC

Serial收集器

(-XX:+UseSerialGC -XX:+UseSerialOldGC)

Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。

大家看名字就知道这个收集器是一个单线程收集器了。它 的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工 作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。

新生代采用复制算法，老年代采用标记-整理算法

但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。

Serial 收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。

它主要有两大用途：一种用途是在JDK1.5 以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案

那种运行在Windows上的客户端程序，建议采用Serial垃圾回收器，单CPU单线程垃圾回收即可

Serial垃圾收集器依然是JVM运行在Client模式下默认的新生代垃圾收集器

Parallel Scavenge收集器

(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算 法、回收策略等等）和Serial收集器类似。

默认的收集线程数跟cpu核数相同，当然也可以用参数(XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。

CMS等垃圾收集器的关注点更多的是用户线程的停 顿时间（提高用户体验）。

所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

新生代采用复制算法，老年代采用标记-整理算法

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。

使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)

ParNew收集器

(-XX:+UseParNewGC)

ParNew现在一般都是用在新生代的垃圾回收器

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

新生代采用复制算法，老年代采用标记-整理算法

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收 集器）配合工作

默认给自己设置的垃圾回收线程的数量就是跟CPU的核数是一样的

使用“-XX:ParallelGCThreads”参数， 通过他可以设置线程的数量

CMS收集器

(-XX:+UseConcMarkSweepGC(old))

CMS是用在老年代的垃圾回收器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

它非常符合在注重用户体 验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程 （基本上）同时工作。

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

CMS是老年代垃圾回收器，基于标记-清除算法实现，新生代默认使用ParNew收集器，基于复制算法

能与CMS搭配使用的新生代垃圾收集器有Serial收集器和ParNew收集器，这2个收集器都采用标记复制算法，都会触发STW事件，停止所有的应用线程，不同之处在于，Serial是单线程执行，ParNew是多线程执行

整个过程分为四个步骤：

初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。

这个过程是支持多线程的（JDK7之前单线程，JDK8之后并行，可通过参数
CMSParallelInitialMarkEnabled调整）

并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但 是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的 对象状态发生改变。

重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对 象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。

主要用到三色标记里的增量更新算法做重新标记。

并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑 色不做任何处理。

并发重置：重置本次GC过程中的标记数据

在整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，因此从总体上看，CMS收集器的内存回收过程是与用户线程一起并发执行的

主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

对CPU资源敏感（会和服务抢资源），是比较耗费CPU资源；CMS默认启动的垃圾回收线程的数量是（CPU核数 + 3）/ 4

我们用最普通的2核4G机器和4核8G机器来计算一下，假设是2核CPU，本来CPU资源就有限，结果此时CMS还会有个“(2 + 3) / 4” = 1个垃圾回收线程，去占用宝贵的一个CPU

无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

在并发清理阶段，CMS只不过是回收之前标记好的垃圾对象

但是这个阶段系统一直在运行，可能会随着系统运行让一些对象进入老年代，同时还变成垃圾对象，这种垃圾对象是“浮动垃圾”

系统程序可能先把某些对象分配在新生代，然后可能触发了一次Minor GC，一些对象进入了老年代，然后短时间内又没人引用这些对象了

它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生

如果内存碎片太多，会导致后续对象进入老年代找不到可用的连续内存空间了，然后触发Full GC。

所以CMS不是完全就仅仅用“标记-清理”算法的，因为太多的内存碎片实际上会导致更加频繁的Full GC。

CMS有一个参数是“-XX:+
UseCMSCompactAtFullCollection”，默认就打开了

他意思是在Full GC之后要再次进行“Stop the World”，停止工作线程，然后进行碎片整理，就是把存活对象挪到一起，空出来大片 连续内存空间，避免内存碎片。 还有一个参数是“
-XX:CMSFullGCsBeforeCompaction”，这个意思是执行多少次Full GC之后再执行一次内存碎片整理的工作，默认 是0，意思就是每次Full GC之后都会进行一次内存整理

CMS垃圾回收的触发时机

其中有一个就是当老年代内存占用达到一定比例了，就自动执行GC。

“
-XX:CMSInitiatingOccupancyFaction”参数可以用来设置老年代占用多少比例的时候触发CMS垃圾回收，JDK 1.6里面默认的值是 92%。

也就是说，老年代占用了92%空间了，就自动进行CMS垃圾回收，预留8%的空间给并发回收期间，系统程序把一些新对象放入老年代 中。

那么如果CMS垃圾回收期间，系统程序要放入老年代的对象大于了可用内存空间，此时会如何？

这个时候，会发生Concurrent Mode Failure，就是说并发垃圾回收失败了，我一边回收，你一边把对象放入老年代，内存都不够了。

此时就会自动用“Serial Old”垃圾回收器替代CMS，就是直接强行把系统程序“Stop the World”，重新进行长时间的GC Roots追 踪，标记出来全部垃圾对象，不允许新的对象产生

然后一次性把垃圾对象都回收掉，完事儿了再恢复系统线程。

所以在生产实践中，这个自动触发CMS垃圾回收的比例需要合理优化一下，避免“Concurrent Mode Failure”问题

concurrent mode failure

该问题是在执行CMS GC的过程中同时业务线程将对象放入老年代，而此时老年代空间不足，或者在做Minor GC的时候，新生代Survivor空间放不下，需要放入老年代，而老年代也放不下而产生的

CMS的相关核心参数

1. -XX:+UseConcMarkSweepGC：启用cms

2. -XX:ConcGCThreads：并发的GC线程数

3. -XX:+
UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）

4.
-XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一 次

5.
-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）

6. -XX:+
UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设 定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整

7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段

8. -XX:+
CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW

9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

G1收集器

G1垃圾回收器是可以同时回收新生代和老年代的对象的，不需要两个垃圾回收器配合起来运作

(-XX:+UseG1GC)

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

G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。

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

Region的大小必须是2的倍数

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

默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个 Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多 的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和 Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100 个，s1对应100个。 一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能 可能会动态变化。

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

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开 销。 Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

垃圾回收的过程

G1收集器一次GC的运作过程大致分为以下几个步骤：

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

这个过程是需要进入“Stop the World”

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

从GC Roots开始追踪所有的存活对象

这个并发标记阶段还是很耗时的，因为要追踪全部的存活对象。

但是这个阶段是可以跟系统程序并发运行的，所以对系统程序的影响不太大。

而且JVM会对并发标记阶段对对象做出的一些修改记录起来，比如说哪个对象被新建了，哪个对象失去了引用

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

这个阶段会进入“Stop the World”，系统程序是禁止运行的，但是会根据并发标记 阶段记录的 那些对象修改，最终标记一下有哪些存活对象，有哪些是垃圾对象

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期 望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个 Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得 知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集 合)，尽量把GC导致的停顿时间控制在我们指定的范围内。

这个阶段其实也可以做到与用户程序一起并发执行，但 是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老 年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样 回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。

(注意：CMS回收阶 段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并 发收集，Shenandoah可以看成是G1的升级版本)

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

并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短StopThe-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式 让java程序继续执行。

分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。

空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部 上来看是基于“复制”算法实现的。

可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了 追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"XX:MaxGCPauseMillis"指定)内完成垃圾收集

毫无疑问， 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不 同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。

不过， 这里设置的“期望值”必须是符合实际的， 不能异想 天开， 毕竟G1是要冻结用户线程来复制对象的， 这个停顿时 间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒， 一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很 正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导 致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆 积。

很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发 Full GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的

垃圾收集分类

YoungGC

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

MixedGC

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

什么时候触发新生代+老年代的混合垃圾回收？

G1有一个参数，是“
-XX:InitiatingHeapOccupancyPercent”，他的默认值是45%

意思就是说，如果老年代占据了堆内存的45%的Region的时候，此时就会尝试触发一个新生代+老年代一起回收的混合回收阶段

Full GC

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

如果在进行Mixed回收的时候，无论是年轻代还是老年代都基于复制算法进行回收，都要把各个Region的存活对象拷贝到别的Region 里去

此时万一出现拷贝的过程中发现没有空闲Region可以承载自己的存活对象了，就会触发 一次失败。

参数设置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)

-XX:G1MaxNewSizePercent:新生代内存最大空间

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

-XX:MaxTenuringThreshold:最大年龄阈值(默认15)

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合 收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能 就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这 个值，存活对象过多，回收的的意义不大。

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

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都 是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清 理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立 即停止混合回收，意味着本次混合回收就结束了。

什么场景适合使用G1

1. 50%以上的堆被存活对象占用

2. 对象分配和晋升的速度变化非常大

3. 垃圾回收时间特别长，超过1秒

4. 8GB以上的堆内存(建议值)

5. 停顿时间是500ms以内

ZGC收集器

(-XX:+UseZGC)

参考文章：
https://wiki.openjdk.java.net/display/zgc/Main http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf

ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于是Azul System公司开发的 C4（Concurrent Continuously Compacting Collector） 收集器

ZGC目标

ZGC的目标主要有4个：

1.支持TB量级的堆。我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求吧。

2.最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，

Major GC一般都需要100ms以上（G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反），之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关，而Root数量和堆大小是没有任何关系的。

3.奠定未来GC特性的基础。

4.最糟糕的情况下吞吐量会降低15%。这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。

另外，Oracle官方提到了它最大的优点是：它的停顿时间不会随着堆的增大而增长！也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下

不分代(暂时)

单代，即ZGC「没有分代」。我们知道以前的垃圾回收器之所以分代，是因为源于“「大部分对象朝生夕死」”的假设，事实上大部分系统的对象分配行为也确实符合这个假设。

那么为什么ZGC就不分代呢？因为分代实现起来麻烦，作者就先实现出一个比较简单可用的单代版本，后续会优化