JVM 垃圾回收器

jvm
10

JVM 有哪些垃圾回收器

在jvm中，实现了多种垃圾收集器，包括：

  • 串行垃圾收集器

  • 并行垃圾收集器

  • CMS（并发）垃圾收集器

  • G1垃圾收集器

1.串行垃圾收集器

Serial和Serial Old串行垃圾收集器，是指使用单线程进行垃圾回收，堆内存较小，适合个人电脑

  • Serial 作用于新生代，采用复制算法

  • Serial Old 作用于老年代，采用标记-整理算法

垃圾回收时，只有一个线程在工作，并且java应用中的所有线程都要暂停（STW），等待垃圾回收的完成。

2.并行垃圾收集器

Parallel New和Parallel Old是一个并行垃圾回收器，JDK8默认使用此垃圾回收器

  • Parallel New作用于新生代，采用复制算法

  • Parallel Old作用于老年代，采用标记-整理算法

垃圾回收时，多个线程在工作，并且java应用中的所有线程都要暂停（STW），等待垃圾回收的完成。

3.CMS（并发）垃圾收集器

JDK 1.5 时引入，JDK9 被标记弃用，JDK14 被移除

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器，该回收器是针对老年代垃圾回收的，是一款以获取最短回收停顿时间为目标的收集器，停顿时间短，用户体验就好。其最大特点是在进行垃圾回收时，应用仍然能正常运行。

CMS垃圾收集器是第一个关注 GC 停顿时间（STW 的时间）的垃圾收集器。之前的垃圾收集器，要么是串行的垃圾回收方式，要么只关注系统吞吐量。

CMS 垃圾收集器之所以能够实现对 GC 停顿时间的控制，其本质来源于对「可达性分析算法」的改进，即三色标记算法。在 CMS 出现之前，无论是 Serious 垃圾收集器，还是 ParNew 垃圾收集器，以及 Parallel Scavenge 垃圾收集器，它们在进行垃圾回收的时候都需要 Stop the World，无法实现垃圾回收线程与用户线程的并发执行。

CMS 垃圾收集器通过三色标记算法，实现了垃圾回收线程与用户线程的并发执行，从而极大地降低了系统响应时间，提高了强交互应用程序的体验。它的运行过程分为 4 个步骤，包括：

  • 初始标记

  • 并发标记

  • 重新标记

  • 并发清除

初始标记，指的是寻找所有被 GCRoots 引用的对象，该阶段需要「Stop the World」。这个步骤仅仅只是标记一下 GC Roots 能直接关联到的对象，并不需要做整个引用的扫描，因此速度很快。

并发标记，指的是对「初始标记阶段」标记的对象进行整个引用链的扫描，该阶段不需要「Stop the World」。 对整个引用链做扫描需要花费非常多的时间，因此通过垃圾回收线程与用户线程并发执行，可以降低垃圾回收的时间。

这也是 CMS 能极大降低 GC 停顿时间的核心原因，但这也带来了一些问题，即：并发标记的时候，引用可能发生变化，因此可能发生漏标（本应该回收的垃圾没有被回收）和多标（本不应该回收的垃圾被回收）了。

重新标记，指的是对「并发标记」阶段出现的问题进行校正，该阶段需要「Stop the World」。正如并发标记阶段说到的，由于垃圾回收算法和用户线程并发执行，虽然能降低响应时间，但是会发生漏标和多标的问题。所以对于 CMS 来说，它需要在这个阶段做一些校验，解决并发标记阶段发生的问题。

并发清除，指的是将标记为垃圾的对象进行清除，该阶段不需要「Stop the World」。 在这个阶段，垃圾回收线程与用户线程可以并发执行，因此并不影响用户的响应时间。

【疑问】为什么Java8没有用CMS作为默认垃圾收集器呢？

CMS 的优点是：并发收集、低停顿。但缺点也很明显：

①、对 CPU 资源非常敏感，因此在 CPU 资源紧张的情况下，CMS 的性能会大打折扣。

默认情况下，CMS 启用的垃圾回收线程数是（CPU数量 + 3)/4，当 CPU 数量很大时，启用的垃圾回收线程数占比就越小。但如果 CPU 数量很小，例如只有 2 个 CPU，垃圾回收线程占用就达到了 50%，这极大地降低系统的吞吐量，无法接受。

②、CMS 采用的是「标记-清除」算法，会产生大量的内存碎片，导致空间不连续，当出现大对象无法找到连续的内存空间时，就会触发一次 Full GC，这会导致系统的停顿时间变长。

③、CMS 无法处理浮动垃圾，当 CMS 在进行垃圾回收的时候，应用程序还在不断地产生垃圾，这些垃圾会在 CMS 垃圾回收结束之后产生，这些垃圾就是浮动垃圾，CMS 无法处理这些浮动垃圾，只能在下一次 GC 时清理掉。

4.G1垃圾回收器

放单独一个板块讲

G1垃圾回收器

G1（Garbage-First Garbage Collector）在 JDK 1.7 时引入，在 JDK 9 时取代 CMS 成为了默认的垃圾收集器。G1 有五个属性：分代、增量、并行、标记整理、STW。

  • 应用于新生代和老年代，在JDK9之后默认使用G1

  • 划分成多个区域，每个区域都可以充当 eden，survivor，old， humongous，其中 humongous 专为大对象准备

补充知识：

新生代（Eden+Survivor）的初始占比是5%堆内存

G1会根据垃圾回收的停顿时间目标，动态增加新生代的Region数量。但是新生代最大占比不超过堆内存的60%

  • 采用复制算法

  • 响应时间与吞吐量兼顾

  • 分成三个阶段：新生代回收、并发标记、混合收集

  • 如果并发失败（即回收速度赶不上创建新对象速度），会触发 Full GC

阶段一：Young Collection(年轻代垃圾回收)

  • 初始时，所有区域都处于空闲状态，分成大小均等的区域，每个区域都可以是Eden、Survivor、old

  • 创建了一些对象，挑出一些空闲区域作为伊甸园区存储这些对象

  • 当伊甸园需要垃圾回收时，挑出一个空闲区域作为幸存区，用复制算法复制存活对象，需要暂停用户线程（STW）

存活对象会被复制到survivor区

  • 随着时间流逝，伊甸园的内存又有不足

  • 将伊甸园以及之前幸存区中的存活对象，采用复制算法，复制到新的幸存区，其中较老对象晋升至老年代

清理后效果

阶段二：Young Collection + Concurrent Mark (年轻代垃圾回收+并发标记)

当老年代占用内存超过阈值(默认是45%)后，触发并发标记（标记老年代里面存活的对象），这时无需暂停用户线程

  • 并发标记之后，会有重新标记阶段解决漏标问题，此时需要暂停用户线程。

  • 这些都完成后就知道了老年代有哪些存活对象，随后进入混合收集阶段。此时不会对所有老年代区域进行回收，而是根据暂停时间目标优先回收价值高（存活对象少）的区域（这也是 Gabage First 名称的由来）。

阶段三：Mixed Collection (混合垃圾回收)

混合收集阶段中，参与复制的有eden、survivor、old

这样就完成了一次混合收集，混合收集可能要执行多次，第一次我们在预定时间内只回收到了3个老年代，后续再多执行几次混合收集，把剩下的老年代重新标记，逐渐释放内存。

当执行多次混合回收后，又进入下一轮的新生代回收、并发标记、混合收集。

G1也有可能出现并发失败的情况，就会触发full GC，那么回收时间就很多了（数秒至数分钟），不过经历了多次【新生代回收，并发标记，混合收集】，一般不会触发full GC。

触发并发失败的原因：

  1. G1启动并发标记周期后，若在触发Mixed GC之前，老年代空间已被完全填满，G1会放弃当前标记周期并触发Full GC。

  2. 并发标记线程数（-XX:ConcGCThreads）过少，导致标记速度小于应用的内存分配速率，进而引发老年代溢出。

如果一个对象太大了，一个区域装不下，会开辟一块连续的空间存储巨型对象

总结：