GC垃圾收集器

在垃圾收集器的体系中，按照分代收集和分区收集的分类方式，不同的收集器有着各自的特点和适用场景。分代收集器基于对象的存活周期不同，将堆内存划分为不同的代，针对各代特点采用不同的回收算法。分区收集器将堆内存划分为多个独立的区域（分区），可以独立管理和回收这些分区。

GC垃圾收集器的JVM配置参数：

• -XX:+UseSerialGC：年轻代和老年代都用串行收集器
• -XX:+UseParNewGC：年轻代使用 ParNew，老年代使用 Serial Old
• -XX:+UseParallelGC：年轻代使用 ParallerGC，老年代使用 Serial Old
• -XX:+UseParallelOldGC：新生代和老年代都使用并行收集器
• -XX:+UseConcMarkSweepGC：表示年轻代使用 ParNew，老年代的用 CMS
• -XX:+UseG1GC：使用 G1垃圾回收器
• -XX:+UseZGC：使用 ZGC 垃圾回收器

分代收集-年轻代收集器

Serial收集器

处理GC的只有一条线程，并且在垃圾回收的过程中暂停一切用户线程。最简单的垃圾回收器，但千万别以为它没有用武之地。因为简单，所以高效，它通常用在客户端应用上。因为客户端应用不会频繁创建很多对象，用户也不会感觉出明显的卡顿。相反，它使用的资源更少，也更轻量级。

ParNew收集器

ParNew是Serial的多线程版本。由多条GC线程并行地进行垃圾清理。清理过程依然要停止用户线程。ParNew 追求“低停顿时间”，与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。

Parallel Scavenge收集器

另一个多线程版本的垃圾回收器。它与ParNew的主要区别是：

• Parallel Scavenge：追求CPU吞吐量，能够在较短时间完成任务，适合没有交互的后台计算。弱交互强计算。
• ParNew：追求降低用户停顿时间，适合交互式应用。强交互弱计算。

分代收集-老年代收集器

Serial Old收集器

与年轻代的 Serial 垃圾收集器对应，都是单线程版本，同样适合客户端使用。年轻代的 Serial，使用复制算法。老年代的 Old Serial，使用标记-整理算法。

Parallel Old收集器

Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

CMS收集器

并发标记清除(Concurrent Mark Sweep,CMS)垃圾回收器，是一款致力于获取最短停顿时间的收集器，使用多个线程来扫描堆内存并标记可被清除的对象，然后清除标记的对象。在下面两种情形下会暂停工作线程：

• 在老年代中标记引用对象的时候

• 在做垃圾回收的过程中堆内存中有变化发生

对比与并行垃圾回收器，CMS回收器使用更多的CPU来保证更高的吞吐量。如果我们可以有更多的CPU用来提升性能，那么CMS垃圾回收器是比并行回收器更好的选择。使用

-XX:+UseConcMarkSweepGC参数来开启使用CMS垃圾回收器。

主要流程如下：

• 初始标记(CMS initial mark)：仅标记出GC Roots能直接关联到的对象。需要Stop-the-world
• 并发标记(CMS concurrenr mark)：进行GC Roots遍历的过程，寻找出所有可达对象
• 重新标记(CMS remark)：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。需要Stop-the-world
• 并发清除(CMS concurrent sweep)：清出垃圾

CMS触发机制：当老年代的使用率达到80%时，就会触发一次CMS GC。

• -XX:CMSInitiatingOccupancyFraction=80
• -XX:+UseCMSInitiatingOccupancyOnly

优点

• 并发收集
• 停顿时间最短

缺点

• 并发回收导致CPU资源紧张

  在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低程序总吞吐量。CMS默认启动的回收线程数是：（CPU核数 + 3）/ 4，当CPU核数不足四个时，CMS对用户程序的影响就可能变得很大。

• 无法清理浮动垃圾

  在CMS的并发标记和并发清理阶段，用户线程还在继续运行，就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留到下一次垃圾收集时再清理掉。这一部分垃圾称为“浮动垃圾”。

• 并发失败（Concurrent Mode Failure）

  由于在垃圾回收阶段用户线程还在并发运行，那就还需要预留足够的内存空间提供给用户线程使用，因此CMS不能像其他回收器那样等到老年代几乎完全被填满了再进行回收，必须预留一部分空间供并发回收时的程序运行使用。默认情况下，当老年代使用了 80% 的空间后就会触发 CMS 垃圾回收，这个值可以通过 -XX*** CMSInitiatingOccupancyFraction 参数来设置。

  这里会有一个风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：Stop The World，临时启用 Serial Old 来重新进行老年代的垃圾回收，这样一来停顿时间就很长了。

• 内存碎片问题

  CMS是一款基于“标记-清除”算法实现的回收器，这意味着回收结束时会有内存碎片产生。内存碎片过多时，将会给大对象分配带来麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。

  为了解决这个问题，CMS收集器提供了一个 -XX:+UseCMSCompactAtFullCollection 开关参数（默认开启），用于在 Full GC 时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的，这样停顿时间就会变长。还有另外一个参数 -XX:CMSFullGCsBeforeCompaction，这个参数的作用是要求CMS在执行过若干次不整理空间的 Full GC 之后，下一次进入 Full GC 前会先进行碎片整理（默认值为0，表示每次进入 Full GC 时都进行碎片整理）。

作用内存区域：老年代

适用场景：对停顿时间敏感的场合

算法类型：标记-清除

分代收集-新生代和老年代收集

G1收集器

G1（Garbage First）回收器采用面向局部收集的设计思路和基于Region的内存布局形式，是一款主要面向服务端应用的垃圾回收器。G1设计初衷就是替换 CMS，成为一种全功能收集器。G1 在JDK9 之后成为服务端模式下的默认垃圾回收器，取代了 Parallel Scavenge 加 Parallel Old 的默认组合，而 CMS 被声明为不推荐使用的垃圾回收器。G1从整体来看是基于 标记-整理 算法实现的回收器，但从局部（两个Region之间）上看又是基于 标记-复制 算法实现的。

G1 回收过程

G1 回收器的运作过程大致可分为四个步骤：

• 初始标记（会STW）：仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改TAMS（Top at Mark Start）指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
• 并发标记：从 GC Roots 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理在并发时有引用变动的对象。
• 最终标记（会STW）：对用户线程做短暂的暂停，处理并发阶段结束后仍有引用变动的对象。
• 清理阶段（会STW）：更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，必须暂停用户线程，由多条回收器线程并行完成的。

G1收集器中的堆内存被划分为多个大小相等的内存块（Region），每个Region是逻辑连续的一段内存，结构如下：

每个Region被标记了E、S、O和H，说明每个Region在运行时都充当了一种角色，其中H是以往算法中没有的，它代表Humongous（巨大的），这表示这些Region存储的是巨型对象（humongous object，H-obj），当新建对象大小超过Region大小一半时，直接在新的一个或多个连续Region中分配，并标记为H。

Region

堆内存中一个Region的大小可以通过 -XX:G1HeapRegionSize参数指定，大小区间只能是1M、2M、4M、8M、16M和32M，总之是2的幂次方。如果G1HeapRegionSize为默认值，则在堆初始化时计算Region的实际大小，默认把堆内存按照2048份均分，最后得到一个合理的大小。

GC模式

young gc

发生在年轻代的GC算法，一般对象（除了巨型对象）都是在eden region中分配内存，当所有eden region被耗尽无法申请内存时，就会触发一次young gc，这种触发机制和之前的young gc差不多，执行完一次young gc，活跃对象会被拷贝到survivor region或者晋升到old region中，空闲的region会被放入空闲列表中，等待下次被使用。

• -XX:MaxGCPauseMillis：设置G1收集过程目标时间，默认值200ms
• -XX:G1NewSizePercent：新生代最小值，默认值5%
• -XX:G1MaxNewSizePercent：新生代最大值，默认值60%

mixed gc

当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即mixed gc，该算法并不是一个old gc，除了回收整个young region，还会回收一部分的old region，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些old region进行收集，从而可以对垃圾回收的耗时时间进行控制。

full gc

• 如果对象内存分配速度过快，mixed gc来不及回收，导致老年代被填满，就会触发一次full gc，G1的full gc算法就是单线程执行的serial old gc，会导致长时间的暂停，需要进行不断的调优，尽可能的避免full gc。

G1垃圾回收器 应用于大的堆内存空间。它将堆内存空间划分为不同的区域，对各个区域并行地做回收工作。G1在回收内存空间后还立即对空闲空间做整合工作以减少碎片。CMS却是在全部停止(stop the world,STW)时执行内存整合工作。对于不同的区域G1根据垃圾的数量决定优先级。使用 -XX:UseG1GCJVM 参数来开启使用G1垃圾回收器。

主要流程如下：

• 初始标记(Initial Marking)：标记从GC Root可达的对象。会发生STW
• 并发标记(Concurrenr Marking)：标记出GC Root可达对象衍生出去的存活对象，并收集各个Region的存活对象信息。整个过程gc collector线程与应用线程可以并行执行
• 最终标记(Final Marking)：标记出在并发标记过程中遗漏的，或内部引用发生变化的对象。会发生STW
• 筛选回收(Live Data Counting And Evacution)：垃圾清除过程，如果发现一个Region中没有存活对象，则把该Region加入到空闲列表中

-XX:InitiatingHeapOccupancyPercent：当老年代大小占整个堆大小百分比达到该阈值时，会触发一次mixed gc。

优点：

• 并行与并发，充分发挥多核优势
• 分代收集，所以不需要与其它收集器配合即可工作
• 空间整合，整体来看基于”标记-整理算法“，局部采用”复制算法“都不会产生内存碎片
• 可以指定GC最大停顿时长

缺点：

• 需要记忆集来记录新生代和老年代之间的引用关系
• 需要占用大量的内存，可能达到整个堆内存容量的20%甚至更多

作用内存区域：跨代

适用场景：作为关注停顿时间的场景的收集器备选方案

算法类型：整体来看基于”标记-整理算法“，局部采用"复制算法"

ZGC收集器

Z Garbage Collector，简称 ZGC，是 JDK 11 中新加入的尚在实验阶段的低延迟垃圾收集器。它和 Shenandoah 同属于超低延迟的垃圾收集器，但在吞吐量上比 Shenandoah 有更优秀的表现，甚至超过了 G1，接近了“吞吐量优先”的 Parallel 收集器组合，可以说近乎实现了“鱼与熊掌兼得”。

与CMS中的ParNew和G1类似，ZGC也采用标记-复制算法，不过ZGC对该算法做了重大改进：ZGC在标记、转移和重定位阶段几乎都是并发的，这是ZGC实现停顿时间小于10ms目标的最关键原因。ZGC垃圾回收周期如下图所示：

ZGC只有三个STW阶段：初始标记，再标记，初始转移。其中，初始标记和初始转移分别都只需要扫描所有GC Roots，其处理时间和GC Roots的数量成正比，一般情况耗时非常短；再标记阶段STW时间很短，最多1ms，超过1ms则再次进入并发标记阶段。即，ZGC几乎所有暂停都只依赖于GC Roots集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加。与ZGC对比，G1的转移阶段完全STW的，且停顿时间随存活对象的大小增加而增加。

ZGC 的内存布局

与 Shenandoah 和 G1 一样，ZGC 也采用基于 Region 的堆内存布局，但与它们不同的是， ZGC 的 Region 具有动态性，也就是可以动态创建和销毁，容量大小也是动态的，有大、中、小三类容量:

• 小型 Region (Small Region)：容量固定为 2MB，用于放置小于 256KB 的小对象
• 中型 Region (M edium Region)：容量固定为 32MB，用于放置大于等于 256KB 但小于 4MB 的对象
• 大型 Region (Large Region)：容量不固定，可以动态变化，但必须为 2MB 的整数倍，用于放置 4MB 或以上的大对象。每个大型 Region 中只会存放一个大对象，这也预示着虽然名字叫作“大型 Region”，但它的实际容量完全有可能小于中型 Region，最小容量可低至 4MB

在 JDK 11 及以上版本，可以通过以下参数开启 ZGC：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC 。

Shenandoah收集器

Shenandoah 与 G1 有很多相似之处，比如都是基于 Region 的内存布局，都有用于存放大对象的 Humongous Region，默认回收策略也是优先处理回收价值最大的 Region。不过也有三个重大的区别：

• Shenandoah支持并发的整理算法，G1整理阶段虽是多线程并行，但无法与用户程序并发执行
• 默认不使用分代收集理论
• 使用连接矩阵 (Connection Matrix)记录跨Region的引用关系，替换掉了G1中的记忆级(Remembered Set)，内存和计算成本更低

Shenandoah 收集器的工作原理相比 G1 要复杂不少，其运行流程示意图如下：

可见Shenandoah的并发程度明显比G1更高，只需要在初始标记、最终标记、初始引用更新和最终引用更新这几个阶段进行短暂的“Stop The World”，其他阶段皆可与用户程序并发执行，其中最重要的并发标记、并发回收和并发引用更新详情如下：

• 并发标记( Concurrent Marking)
• 并发回收( Concurrent Evacuation)
• 并发引用更新( Concurrent Update Reference)

Shenandoah 的高并发度让它实现了超低的停顿时间，但是更高的复杂度也伴随着更高的系统开销，这在一定程度上会影响吞吐量，下图是 Shenandoah 与之前各种收集器在停顿时间维度和系统开销维度上的对比：

OracleJDK 并不支持 Shenandoah，如果你用的是 OpenJDK 12 或某些支持 Shenandoah 移植版的 JDK 的话，可以通过以下参数开启 Shenandoah：-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC 。