JVM垃圾回收器-优快云博客

一、分代垃圾收集器代表CMS

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。从名字中的 Mark Sweep 这两个词可以看出，CMS 收集器是由标记-清除算法实现的。它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。

垃圾回收过程

1. 初始标记: 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快

2. 并发标记: 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。

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

4. 并发清除: 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

这是一款优秀的垃圾收集器：并发收集、低停顿。但是它有下面三个明显的缺点：

CMS 收集器缺点

1. 吞吐量大大小依赖CPU资源。对 CPU 资源非常敏感。因此在 CPU 资源紧张的情况下，CMS 的性能会大打折扣。默认情况下，CMS 启用的垃圾回收线程数是（CPU数量 + 3)/4，当 CPU 数量很大时，启用的垃圾回收线程数占比就越小。但如果 CPU 数量很小，例如只有 2 个 CPU，垃圾回收线程占用就达到了 50%，这极大地降低系统的吞吐量，无法接受。

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

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

二、分区垃圾回收器代表G1

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器，以极高概率满足 GC 停顿时间要求的同时，还具备高吞吐量性能特征。引入了基于区域（Region）的垃圾回收策略。它是从 JDK 1.7 版本开始引入的。

G1垃圾收集器的主要目标是实现更短的停顿时间和更高的吞吐量。

G1 收集器特点

被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征，在 JDK 9 时取代 CMS 成为了默认的垃圾收集器。它具备以下特点：

1. 增量：G1 可以以增量方式执行垃圾回收，这意味着它不需要一次性回收整个堆空间，而是可以逐步、增量地清理。有助于控制停顿时间，尤其是在处理大型堆时。

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

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

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

5. 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。

G1 收集器的分代设计思想

G1 是基于分代的思想进行设计的。它将堆内存分为多个大小相等的区域（Region），每个区域都可以是 Eden 区、Survivor 区或者 Old 区。

可以通过 -XX:G1HeapRegionSize=n 来设置 Region 的大小，可以设定为 1M、2M、4M、8M、16M、32M（不能超过）。

G1 有专门分配大对象的 Region 叫 Humongous 区，而不是让大对象直接进入老年代的 Region 中。在 G1 中，大对象的判定规则就是一个大对象超过了一个 Region 大小的 50%，比如每个 Region 是 2M，只要一个对象超过了 1M，就会被放入 Humongous 中，而且一个大对象如果太大，可能会横跨多个 Region 来存放。

G1 垃圾回收过程

它的设计思想是将堆内存划分为多个大小相等的区域（Region），每个区域都可以是Eden、Survivor 或 Old 区域。G1垃圾收集器通过并发、增量和并行的方式，以区域为粒度进行垃圾回收，其工作过程如下：

1. 初始标记（Initial Mark）：G1垃圾收集器会首先标记出GC Roots能直接关联到的对象，并记录下这些对象的存活状态。在此阶段，应用程序的执行会停顿下来。

2. 并发标记（Concurrent Marking）：G1垃圾收集器并发进行标记工作，在应用程序运行的同时，标记剩余的存活对象。在这个阶段，G1会进行跨区域的引用扫描，标记存活对象。

3. 最终标记（Final Mark）：在并发标记阶段结束后，G1会做一次最终标记来修正并发标记期间有可能发生的引用变化。该阶段的停顿时间会较短。

4. 筛选回收（Live Data Counting）：G1根据各个区域内的垃圾量和存活对象数量等信息，选择最有价值的区域进行垃圾收集。这个阶段被称为G1的"Garbage-First"策略。

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region (Garbage-First)这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

G1进行并发的垃圾清理工作，在应用程序运行的同时，回收垃圾区域中的无用对象。

G1垃圾收集器在整个垃圾回收过程中，会控制垃圾回收的停顿时间，尽量减少对应用程序的影响。它可以根据应用程序的需要动态调整各个阶段的时间比例，以达到更好的性能和吞吐量。

三、了解7种垃圾收集器

7种作用于不同分代的收集器，其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括Serial Old、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。

1. Serial收集器（复制算法)：新生代单线程收集器，标记和清理都是单线程，优点是简单高效；

2. Serial Old收集器 (标记-整理算法)：老年代单线程收集器，Serial收集器的老年代版本；

3. ParNew收集器 (复制算法)：新生代收并行集器，实际上是Serial收集器的多线程版本，在多核4. CPU环境下有着比Serial更好的表现；

4. Parallel Scavenge收集器 (复制算法)：新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量 = 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间，尽快完成程序的运算任务，适合后台应用等对交互相应要求不高的场景；

5. Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先，Parallel Scavenge收集器的老年代版本；

6. CMS(Concurrent Mark Sweep)收集器（标记-清除算法）：老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。

7. G1(Garbage First)收集器 (标记-整理算法)：Java堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。此外，G1收集器不同于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代。