深入理解JVM：垃圾回收

╰+哭是因爲堅強的太久メ 2023-07-02 07:29 1阅读 0赞

## **一、学习垃圾回收**的必要性 ##

当需要排查各种内存溢出问题、当垃圾收集成为系统达到更高并发的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

## 二、JVM内存分配与回收 ##

垃圾回收主要是在虚拟机内存的堆上。堆示意图如下：

![format_png][]

上图所示的 eden 区、s0("From") 区、s1("To") 区都属于新生代，tentired 区属于老年代。

### 两种垃圾回收 ###

*  **新生代 GC（Minor GC）**:指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。
 *  **老年代 GC（Major GC/Full GC）**:指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。

### 为对象分配内存 ###

上图所示的 eden 区、s0("From") 区、s1("To") 区都属于新生代，tentired 区属于老年代

大多数情况，首先对象会在Eden上面进行内存分配。如果没有足够的空间的时候。就先执行一次Minor GC，这个GC一般是发生在eden和s0("from")，如果有存活的对象就进入s1，并且对象的年龄会加1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。经过这次GC，eden和s0区都被清空，然后交换s1和s0，存活的对象同样会经历下一次的Minor GC，如果还存活，那么年龄会+1，Minor GC会一直重复这样的过程，直到“To”区被填满，"To"区被填满之后，会将所有对象移动到老年代中。

### 堆内存的常见分配策略 ###

（1）对象优先在Eden区分配（2）大对象直接进入老年代（3）长期存活的对象将进入老年代

### 动态对象年龄的判定 ###

为了更好的适应不同程序的内存情况，虚拟机不是永远要求对象年龄必须达到了某个值才能进入老年代，如果 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需达到要求的年龄。

## 三、对象已经死亡？ ##

### 可达性分析 ###

这个算法的基本思想就是通过一系列的称为 **“GC Roots”** 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的。

![72762049.jpg][]![uploading.gif][]正在上传…重新上传取消

可作为GC Roots对象：

（1）虚拟机栈（栈帧中的本地变量表）中引用的对象。

（2）方法区中类静态属性引用的对象。

（3）方法区中常量引用的对象。

（4）本地方法栈中JNI（即本地方法）引用的对象。

### 对象是否死亡 ###

（1）第一次标记：可达性分析不可达的对象被筛选。筛选的条件是此对象是否有必要执行finalize方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。

（2）第二次标记：将被筛选出的对象放置在一个F-Queue队列中，之后GC将堆F-Queue进行第二次小规模标记。这个队列会执行finalize方法。

对象也可以拯救自己，就是在finalize方法中将自己与引用链上任何一个对象关联即可，就可移出队列。

但是只能拯救自己依次，因为任何一个对象finalize方法只会被系统调用一次。

## 四、引用 ##

（1）强引用：Obeject obj = new Object();这类引用垃圾收集器永远不会回收掉被引用的对象。

（2）软引用：还有用但非必须的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围进行第二次回收。

（3）弱引用：只能生存到下一次垃圾收集发生之前。当垃圾回收器工作时，无论内存是否够用，都会被回收

（4）虚引用：最弱。虚引用主要用来跟踪对象被垃圾回收的活动。

## 五、垃圾回收算法 ##

### （1）标记 - 清除 算法 ###

该算法分为“标记”和“清除”阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：效率低下和产生内存碎片。

![å¬ä¼å·][format_png 1]

### （2）复制算法 ###

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

![å¬ä¼å·][format_png 2]

这个算法目前用于分代算法中的新生代中使用，在新生代中并不是按照1：1进行划分的，而是分为（eden+s0）和s1两部分。

### （3）标记 - 整理算法 ###

根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

![æ è®°-æ´çç®æ³][-]

这个算法用于老年代使用，

### （4）分代收集算法 ###

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

**比如在新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。**

## **六、垃圾收集器** ##

**（1）Serial收集器**

这是一个单线程的收集器，当它进行垃圾收集工作的时候，必须暂停其他所有工作线程。

![46873026.jpg][]![uploading.gif][]正在上传…重新上传取消

优点：简单而高效。

缺点：会给用户带来不良的体验，有停顿感。

**（2）ParNew收集器**

这是一个serial的多线程版本，

![ParNew æ¶éå¨][ParNew]

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

**并行和并发概念补充：**

*  **并行（Parallel）** ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
 *  **并发（Concurrent）**：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。

**（3）Parallel Scavenge收集器**

Parallel Scavenge 收集器也是使用复制算法的多线程收集器，

**Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。**

（1）（2）（3）新生代采用复制算法，老年代采用标记-整理算法。

**（4）Serial Old收集器**

**Serial 收集器的老年代版本**，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

**（5）Parallel Old收集器**

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

**（6）CMS收集器**

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

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

采用**标记-清除”算法**

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

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

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

**并发清除：** 开启用户线程，同时 GC 线程开始对为标记的区域做清扫

![CMS åå¾æ¶éå¨][CMS]

**（7）G1收集器**

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

被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备一下特点：

*  **并行与并发**：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
 *  **分代收集**：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
 *  **空间整合**：与 CMS 的“标记--清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
 *  **可预测的停顿**：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

G1 收集器的运作大致分为以下几个步骤：

*  **初始标记**
 *  **并发标记**
 *  **最终标记**
 *  **筛选回收**

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

参考：[https://snailclimb.gitee.io/javaguide/\#/docs/java/jvm/JVM%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6?id=\_4-%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8][https_snailclimb.gitee.io_javaguide_docs_java_jvm_JVM_E5_9E_83_E5_9C_BE_E5_9B_9E_E6_94_B6_id_4-_E5_9E_83_E5_9C_BE_E6_94_B6_E9_9B_86_E5_99_A8]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9teS1ibG9nLXRvLXVzZS5vc3MtY24tYmVpamluZy5hbGl5dW5jcy5jb20vMjAxOS0zJUU1JUEwJTg2JUU3JUJCJTkzJUU2JTlFJTg0LnBuZw?x-oss-process=image/format,png
[72762049.jpg]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzcyNzYyMDQ5LmpwZw?x-oss-process=image/format,png
[uploading.gif]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jc2RuaW1nLmNuL3JlbGVhc2UvcGhvZW5peC93cml0ZS9hc3NldHMvdXBsb2FkaW5nLmdpZg
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzYzNzA3MjgxLmpwZw?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzkwOTg0NjI0LmpwZw?x-oss-process=image/format,png
[-]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3Lzk0MDU3MDQ5LmpwZw?x-oss-process=image/format,png
[46873026.jpg]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzQ2ODczMDI2LmpwZw?x-oss-process=image/format,png
[ParNew]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzIyMDE4MzY4LmpwZw?x-oss-process=image/format,png
[CMS]: https://imgconvert.csdnimg.cn/aHR0cDovL215LWJsb2ctdG8tdXNlLm9zcy1jbi1iZWlqaW5nLmFsaXl1bmNzLmNvbS8xOC04LTI3LzgyODI1MDc5LmpwZw?x-oss-process=image/format,png
[https_snailclimb.gitee.io_javaguide_docs_java_jvm_JVM_E5_9E_83_E5_9C_BE_E5_9B_9E_E6_94_B6_id_4-_E5_9E_83_E5_9C_BE_E6_94_B6_E9_9B_86_E5_99_A8]: https://snailclimb.gitee.io/javaguide/#/docs/java/jvm/JVM%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6?id=_4-%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8