jvm深度学习（10）：JVM 中常见的垃圾回收器

柔光的暖阳◎ 2023-03-01 12:42 14阅读 0赞

前言： 在新生代中，每次垃圾回收时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成回收。 而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

以下是各垃圾回收器之间的关系：

![20200725223054495.png][]

注意：图中CMS与Serial无关系，已打马赛克。

Oracle 官方也有对应英文解释 https://docs.oracle.com/en/java/javase/13/gctuning/ergonomics.html\#GUID-DB4CAE94-2041-4A16-90EC-6AE3D91EC1F1 （比较难理解，基于 java13 的）

### **Serial/Serial Old** ###

JVM 刚诞生就只有这种，最古老的，单线程，独占式，成熟，适合单 CPU，一般用在客户端模式下。  
这种垃圾回收器只适合几十兆到一两百兆的堆空间进行垃圾回收（可以控制停顿时间再 100ms 左右），但是对于超过这个大小的内存回收速度很慢，所 以对于现在来说这个垃圾回收器已经是一个鸡肋。

![20200727203116716.png][]

**注意：现在已经很少使用，但是比较有意思的是，当CMS垃圾回收器出现Concurrent Mode Failure（CMS进行垃圾回收时，预留的内存不够存放浮动垃圾时会出现），这时虚拟机将临时启用 Serial Old 来替代 CMS。**

**参数设置**

\-XX:+UseSerialGC 新生代和老年代都用串行收集器

**Stop The World（STW）**

**单线程进行垃圾回收时，必须暂停所有的工作线程**，直到它回收结束。这个暂停称之为“Stop The World”,但是这种 STW 带来了恶劣的用户体验,例如:应 用每运行一个小时就需要暂停响应 5 分。这个也是早期 JVM 和 java 被 C/C++语言诟病性能差的一个重要原因。所以 JVM 开发团队一直努力消除或降低 STW 的时间。

###    Parallel Scavenge（ParallerGC）/Parallel Old ###

![20200727203207969.png][]

为了提高回收效率，从 JDK1.3 开始，JVM 使用了多线程的垃圾回收机制，关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用 CPU 时间，尽快完成 程序的运算任务，主要适合在后台运算而不需要太多交互的任务。  
所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即**吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）**，虚拟机总 共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。  
        该垃圾回收器适合回收堆空间 上百兆~几个 G。

**参数设置**

JDK1.8 默认就是以下组合  
\-XX:+UseParallelGC 新生代使用 Parallel Scavenge，老年代使用 Parallel Old

收集器提供了两个参数用于精确控制吞吐量，分别控制的停顿时间的-XX:MaxGCPauseMillis 参数以及直接设置吞吐量大小的-XX:GCTimeRatio 参数。 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

![20200725224430513.png][]

**注意：千万不要异想天开地认为如果把这个参数的值设置得更小一点就能使得系统的垃圾收集速度变得更快，垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的:系统把新生代调得小一些，收集 300MB 新生代肯定比收集 500MB 快，但这也直接导致垃圾收集发生得更频繁，原来 10 秒 收集一次、每次停顿 100 毫秒，现在变成 5 秒收集一次、 每次停顿 70 毫秒。停顿时间的确在下降，但吞吐量也降下来了。 **

\-XX:GCTimeRatio

-XX:GCTimeRatio 参数的值则应当是一个大于 0 小于 100 的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。  
        例如：把此参数设置为 19, 那允许的最大垃圾收集时占用总时间的 5% (即 1/(1+19))， 默认值为 99，即允许最大 1% (即 1/(1+99))的垃圾收集时间。**由于与吞吐量关系密切，ParallelScavenge 是“吞吐量优先垃圾回收器”。**

\-XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy （默认开启）。这是一个开关参数， 当这个参数被激活之后，就不需要人工指定新生代的大小(-Xmn)、Eden 与 Survivor 区的 比例(-XX:SurvivorRatio)、 晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调 整这些参数以提供最合适的停顿时间或者最大的吞吐量。

![20200725224906277.png][]

### ParNew  ###

多线程垃圾回收器，与 CMS 进行配合，对于 CMS(CMS 只回收老年代)，新生代垃圾回收器只有 Serial 与 ParNew 可以选。和 Serial 基本没区别，唯一的区 别：多线程，多 CPU 的，停顿时间比 Serial 少。（在 JDK9 以后，把 ParNew 合并到了 CMS 了）  
大致了解下搭配关系即可，后续版本已经接近淘汰。

![20200725225052791.png][]

### Concurrent Mark Sweep （CMS）  ###

![20200725225225669.png][]

收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务 的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。  
        从名字（包含“Mark Sweep”）上就可以看出，CMS 收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些， 整个过程分为 4 个步骤，包括：

1.  **初始标记**\-短暂，仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快(STW)。
2.  **并发标记-**和用户的应用程序同时进行，进行 GC Roots 追踪的过程，标记从 GCRoots 开始关联的所有对象开始遍历整个可达分析路径的对象。这个时间比较长，所以采用并发处理（垃圾回收器线程和用户线程同时工作）.
3.  **重新标记**\-短暂，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短(STW)。
4.  **并发清除**  
    由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS 收集器的内存回收过程是与用 户线程一起并发执行的。  
    \-XX:+UseConcMarkSweepGC ，表示新生代使用 ParNew，老年代的用 CMS

**CMS产生三大问题**：

**CPU 敏感**：CMS 对处理器资源敏感，毕竟采用了并发的收集、当处理核心数不足 4 个时，CMS 对用户的影响较大。

**浮动垃圾**：由于 CMS 并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS 无法 在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这一部分垃圾就称为“浮动垃圾”。  
        由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。  
在 1.6 的版本中老年代空间使用率阈值(92%)。如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。

**会产生空间碎片**：标记 - 清除算法会导致产生不连续的空间碎片。  
        总体来说，CMS 是 JVM 推出了第一款并发垃圾收集器，所以还是非常有代表性。  
        但是最大的问题是 CMS 采用了标记清除算法，所以会有内存碎片，当碎片较多时，给大对象的分配带来很大的麻烦，为了解决这个问题，CMS 提供一个 参数：-XX:+UseCMSCompactAtFullCollection，一般是开启的，如果分配不了大对象，就进行内存碎片的整理过程。  
        这个地方一般会使用 Serial Old ，因为 Serial Old 是一个单线程，所以如果内存空间很大、且对象较多时,CMS 发生这样情况会很卡。

![20200725230104815.png][]

**CMS 总结：**  
        CMS 问题比较多，所以现在没有一个版本默认是 CMS，只能手工指定。但是它毕竟是第一个并发垃圾回收器，对于了解并发垃圾回收具有一定意义，所 以我们必须了解。  
        为什么 CMS 采用标记-清除，在实现并发的垃圾回收时，如果采用标记整理算法，那么还涉及到对象的移动（对象的移动必定涉及到引用的变化，这个需要暂停业务线程来处理栈信息，这样使得并发收集的暂停时间更长），所以使用简单的标记-清除算法才可以降低 CMS 的 STW 的时间。

该垃圾回收器适合回收堆空间几个 G~ 20G 左右。 在 JDK1.8 中，配置参数：

![20200725230546162.png][]

## Garbage First(G1)  ##

**设计思想**

随着 JVM 中内存的增大，STW 的时间成为 JVM 急迫解决的问题，但是如果按照传统的分代模型，总跳不出 STW 时间不可预测这点。  
        为了实现 STW 的时间可预测，首先要有一个思想上的改变。G1 将堆内存“化整为零”，将堆内存划分成多个大小相等独立区域（Region），每一个 Region 都可以根据需要，扮演新生代的 Eden 空间、Survivor 空间，或者老年代空间。回收器能够对扮演不同角色的 Region 采用不同的策略去处理，这样无论是 新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

**Region**

Region 可能是 Eden,也有可能是 Survivor,也有可能是 Old,另外 Region 中还有一类特殊的 Humongous 区域，专门用来存储大对象。 G1 认为只要大小超过 了一个 Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数-XX:G1HeapRegionSize 设定，取值范围为 1MB~32MB,且应为 2 的 N 次 幂。而对于那些超过了整个 Region 容量的超级大对象，将会被存放在 N 个连续的 Humongous Region 之中，G1 的进行回收大多数情况下都把 Humongous Region 作为老年代的一部分来进行看待。

![20200725230732276.png][]

**参数设置 ：**

**开启参数：**\-XX:+UseG1GC

**分区大小：**\-XX:+G1HeapRegionSize

![20200725231025706.png][]

翻译：

设置在使用垃圾优先(G1)收集器时细分Java堆的区域的大小。这个值可以在1mb到32mb之间。默认的区域大小是根据实时需要的堆大小决定的。

下面的例子展示了如何设置子分区的大小为16mb

一般建议逐渐增大该参数，随着 size 增加，垃圾的存活时间更长，GC 间隔更长，但每次 GC 的时间也会更长。

**最大GC 暂停时间**

MaxGCPauseMillis

![2020072523161620.png][]

翻译：

设置最大GC暂停时间的目标(毫秒)。这是一个软目标，JVM将尽最大努力实现它。默认情况下，没有最大暂停时间值。

下面的例子展示了如何设置最大目标暂停时间为500毫秒

**运行过程**

![20200725231753232.png][]

G1 的运作过程大致可划分为以下四个步骤:

1.  **初始标记( Initial Marking)**  
            仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的 Region 中分配新对象。 这个阶段需要停顿线程，但耗时很短，而且是借用进行 Minor GC 的时候同步完成的，所以 G1 收集器在这个阶段实际并没有额外的停顿。  
    TAMS 是么？                                                                                                                                                                           要达到 GC 与用户线程并发运行，必须要解决回收过程中新对象的分配，所以 G1 为每一个 Region 区域设计了两个名为 TAMS（Top at Mark Start）的指针， 从 Region 区域划出一部分空间用于记录并发回收过程中的新对象。这样的对象认为它们是存活的，不纳入垃圾回收范围。 
2.  **并发标记( Concurrent Marking)**  
            从 GC Root 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫 描完成以后，并发时有引用变动的对象，这些对象会漏标（后续再讲三色标记的时候会细讲这个问题），漏标的对象会被一个叫做 SATB(snapshot-at-the-beginning)算法来解决。
3.  **最终标记( Final Marking)**  
            对用户线程做另一个短暂的暂停，用于处理并发阶段结后仍遗留下来的最后那少量的 SATB 记录(漏标对象)。
4.  **筛选回收( Live Data Counting and Evacuation)**  
            负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个 Region 构 成回收集，然后把决定回收的那一部分 Region 的存活对象复制到空的 Region 中，再清理掉整个旧 Region 的全部空间。这里的操作涉及存活对象的移动， 是必须暂停用户线程，由多条收集器线程并行完成的。

**特点**

**并行与并发**：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿的时间，部分其他收集器 原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。  
**分代收集**：与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但它能够采用不同的方式 去处理新创建的对象和已经存活了一段时间、熬过多次 GC 的旧对象以获取更好的收集效果。  
空间整合：与 CMS 的“标记—清理”算法不同，G1 从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复 制”算法实现的，但无论如何，这两种算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运 行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。  
**追求停顿时间**：  
\-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1 尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。

**使用场景：**该垃圾回收器适合回收堆空间上百 G。一般在 G1 和 CMS 中间选择的话平衡点在 6~8G，只有内存比较大 G1 才能发挥优势。

参数：-XX:+UseG1GC

![20200725232349624.png][]

翻译：

启用垃圾优先(G1)垃圾收集器。它是一个服务器风格的垃圾收集器，针对具有大量RAM的多处理器机器。它满足GC暂停时间目标的可能性很高，同时保持良好的吞吐量。G1收集器推荐用于需要大量堆(大小约为6 GB或更大)且GC延迟要求有限(稳定且可预测的暂停时间低于0.5秒)的应用程序。

默认情况下，禁用此选项，并根据机器的配置和JVM的类型自动选择收集器。

**声明：本文为学习享学课堂三期JVM章节课后所做的学习总结，文中借鉴King老师上课笔记和课堂PPT。**

[20200725223054495.png]: /images/20230208/b249bdfe869442fa95f0682c456c1bdd.png
[20200727203116716.png]: /images/20230208/e6b282bf8fd44e79a08d0a2131d30cc0.png
[20200727203207969.png]: /images/20230208/71c9e471e01f4637aaf1da2e09e1a98c.png
[20200725224430513.png]: /images/20230208/37d7410a2c14483d9885d98e6f961b99.png
[20200725224906277.png]: /images/20230208/46a9c151c0254dc4828e536dedd58765.png
[20200725225052791.png]: /images/20230208/f5d47963768749438cca38cf585a6265.png
[20200725225225669.png]: /images/20230208/e07f32ec4d374b8090e65609968a6db2.png
[20200725230104815.png]: /images/20230208/47b5e50bf5194ee9a6c6b2d5cc21982d.png
[20200725230546162.png]: /images/20230208/38a58221950843e88f6c85b39d986a8b.png
[20200725230732276.png]: /images/20230208/d52bf7f8a85e4288880a170a55067739.png
[20200725231025706.png]: /images/20230208/71bc21cc762d49a5aedd55f8f7cba4c8.png
[2020072523161620.png]: /images/20230208/7925df015e134178a92e92067dbdaf50.png
[20200725231753232.png]: /images/20230208/5ac17d7ae0ae48bca6755c1c93b98645.png
[20200725232349624.png]: /images/20230208/3c0763b4901c40858b2e61af8e7162e6.png