深入了解JVM垃圾回收机制

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。
-《深入理解Java虚拟机：JVM高级特性与最佳实践（第三版）》

要对Java程序进行性能调优，就不得不理解JVM内部的垃圾回收机制。JVM就像一位勤劳的环卫工人，帮我们清理Java程序运行过程中产生的各种垃圾。接下来就让我们深度剖析这位环卫工人清理垃圾的过程。从而能帮我减少无用垃圾的产生。

1、什么是JVM垃圾回收

垃圾回收(Garbage Collection) 是Java虚拟机(JVM)垃圾回收器提供的一种用于在空闲时间不定时回收无任何对象引用的对象占据的内存空间的一种机制。

2、如何判断某个对象是否存活

主要通过以下两种方式判断

• 引用计数算法（基本不用）
  给堆中每个对象添加一个引用计数器，当对象被创建并初始化赋值后，计数器的值设为1。每当对象被引用一次，计数器的值就加1（a = b，则b的计数器值加1）。当引用失效时（一个对象的某个引用超过了生命周期（出作用域后）或者被设置为一个新值时），计数器的值就减1。当计数器的值为0时，说明该对象不存活，可以被回收。当一个对象被回收时，它引用的任何对象对应计数值减1。
  优点： 原理简单，判定效率高。
  缺点： 难以检测互相循环引用，增加了程序执行的开销。

• 可达性分析算法
  通过一系列称为 “GC Roots” 的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为 “引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。可以被回收。
  在Java中，可作为GC Root的对象包括以下几种：

  • 虚拟机栈（栈帧中的本地变量表）中引用的对象，如方法参数、局部变量、临时变量等。
  • 方法区中静态属性引用的对象，如类的引用类型静态变量。
  • 方法区中常量引用的对象，如字符串常量池里的引用。
  • 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
  • Java虚拟机内部引用，如基本数据类型对应的Class对象、异常对象、系统类加载器等。
  • 被同步锁（Synchrozed）持有的对象。
  • 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

  如果对虚拟机的内存布局与运行流程有所了解的话，这些作为 GCRoots 都很好理解，它们是程序运行时的源头，程序的正常运行必须依赖它们，而与这些源头没有任何关系的对象，即可视为可回收对象。就好比“瓜从藤上掉下来了，那这瓜肯定也没有用了” 。

垃圾回收器会从GC Root对象开始遍历，将引用到对象标记为存活。未标记到的对象就是垃圾对象，后续可以清除。

标记阶段需要注意以下关键点：
1、开始标记前，需要暂停应用线程，避免线程在标记过程改变对象的引用关系。暂停应用线程以便JVM进行垃圾回收这种情况称为安全点，这样会触发Stop The World (STW) 暂停。
2、暂停时间的长短取决于存活对象的多少。
3、未标记的对象不一定会被回收，确定被回收至少要经历两次标记过程：
（1）如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。
（2）如果对象被判定为有必要执行finalize()方法，这个对象将会被放置在一个名为F-Queue队列中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。finalize()方法是对象逃脱死亡命运的最后一次机会（系统只会自动调用一次对象的finalize()方法），稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可。
4、GC判断对象是否可达看的是强引用。

标记阶段完成后，GC就进入删除对象阶段。

3、垃圾回收算法

标记-清除算法

“标记-清除”（Mark-Sweep）算法是最早出现也是最基础的垃圾收集算法。分为 “标记” 和 “清除” 两个阶段。标记实际上就是使用可达性分析法判定垃圾对象的标记过程。在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。为什么说该算法是最基础的呢？因为后续的收集算法通过对该算法进行优化得到的。

优点：

• 不需要移动对象，仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效。

缺点：

• 执行效率不稳定： 如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低。
• 内存空间的碎片化： 标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

标记-复制算法

标记-复制算法将内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优点：

• 分配内存时不用考虑有空间碎片的复杂情况。
• 只需要移动堆顶指针，按顺序分配即可。

缺点：

• 将可用内存缩小为了原来的一半，空间浪费大。
  

标记-整理算法

标记-整理算法与标记-清除算法的本质差异在于前者是一种移动式的回收算法，而后者是非移动式的。两者标记过程一样。但标记-整理算法后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

优点：

• 整理之后的内存新对象分配只需要通过指针碰撞便能完成。
• 空闲区域的位置始终是可知的，不会有内存碎片问题。

缺点：

• 移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行。

4、JVM分代堆内存结构（基于JDK1.8）

Java的堆内存分为新生代和老年代两个区域，默认情况下新生代占1/3的空间，老年代占2/3的空间。新生代又分为Eden区和Survivor区，Survivor 又分为 S0、S1 区 默认各占 8/10 与 1/10，1/10 的空间。即 Eden ：S0 ：S1 = 8 : 1 : 1 。

新生代

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。回收时采用标记-复制算法，将Eden区存活对象复制到一个S0区，然后清空Eden区，当这个S0区也存放满时，则将Eden区和S0区存活对象复制到S1区，然后清空Eden和这个S0区，若S1区存放满时，则将Eden区和S1区存活对象复制到S0区， 然后清空Eden和S1区，如此往复。除了第一次放入S0区对象年龄初始化为1，后续每次复制对象年龄都会加1。

老年代

在年轻代中经历了一定次数的垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。以下情况也会直接将对象放入老年代：

直接分配：

• HotSpot虚拟机提供了-XX：PretenureSizeThreshold 参数 (只对Serial和ParNew两款新生代收集器有效) ，指定大于该设置值的对象直接在老年代分配。避免在Eden区及两个Survivor区之间来回复制，产生大量的内存复制操作。
• 超过 Eden 大小的对象。
• 如果新生代分配失败，一个大数组或者大字符串。

从年轻代晋升：

• 新生代分配担保，当 Survivor 区内存不够所有存活对象分配时，就需要将 Survivor 无法容纳的对象分配到老年代去，这种机制就叫分配担保。
• 对象年龄超过虚拟机 MaxTenuringThreshold 的设置值，默认值为15。
• 在Survivor空间中相同年龄所有对象大小的总和大于 Survivor空间的一半，年龄大于或等于该年龄的对象就直接进入老年代。

5、垃圾回收器

在讲垃圾回收器之前，我们先了解在垃圾收集器的上下文语境中，并行和并发的区别：

• 并行（Parallel）： 并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线程在协同工作，通常默认此时用户线程是处于等待状态。
• 并发（Concurrent）： 并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行。由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。

Serial收集器（新生代收集器）

Serial收集器是最基础、历史最悠久的收集器，通过名字可知这个收集器是一个单线程工作的收集器。且该收集器在进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束，即 “Stop The World”。这对很多应用来说都是不能接受的，所以一般的情况都不会使用该收集器。但它简单而高效的优点对于运行在客户端模式下的虚拟机来说是一个很好的选择。

ParNew收集器（新生代收集器）

ParNew收集器实质上是Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX： PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致，在实现上这两种收集器也共用了相当多的代码。

由于存在线程交互的开销，ParNew收集器在单核心处理器的环境中绝对不会有比Serial收集器更好的效果。但是随着处理器的核心数量增加，ParNew对于垃圾收集时系统资源的高效利用还是很有好处的。它默认开启的收集线程数与处理器核心数量相同，可通过 -XX：ParallelGCThreads 参数来限制垃圾收集的线程数。

Parallel Scavenge收集器（新生代收集器）

Parallel Scavenge收集器是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器。表面上看，Parallel Scavenge和ParNew的特性有诸多相似之处。但Parallel Scavenge收集器的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。吞吐量是指处理器用于运行用户代码的时间与处理器总消耗时间（运行用户代码时间 + 运行垃圾收集时间）的比值。例如，在虚拟机完成某个任务中，运行用户代码加上垃圾收集一共耗费了100分钟，而其中垃圾收集花了1分钟，那吞吐量就是99%。

关注停顿时间和关注吞吐量的收集器分别适用于不同场景。

• 停顿时间短： 适合需要与用户交互或需要保证服务响应质量的程序，良好的响应速度能提升用户体验。
• 高吞吐量： 可以最高效率地利用处理器资源，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的分析任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis 参数以及直接设置吞吐量大小的 -XX：GCTimeRatio 参数。

Serial Old收集器（老年代收集器）

Serial Old是Serial收集器的老年代版本，同样是一个单线程收集器，使用标记-整理算法。
该收集器主要用途如下：

• 客户端模式
  供HotSpot虚拟机使用。
• 服务端模式
  在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用。
  作为CMS 收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。
  

Parallel Old收集器（老年代收集器）

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，同样也是基于标记-整理算法实现。该收集器是直到JDK1.6时才提供的，主要是和Parallel Scavenge搭配使用。

CMS收集器（老年代收集器）

CMS（Concurrent Mark Sweep）收集器以获取最短回收停顿时间为目标。适用于关注服务的响应速度，以给用户带来良好的交互体验的Java应用。如互联网网站或者基于浏览器的B/S系统的服务端。

从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于标记-清除算法实现的，它的运作 过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤：

• 初始标记（CMS initial mark） ：需要 “Stop The World”，仅仅只是标记GC Roots能直接关联到的对象，速度很快。
• 并发标记（CMS concurrent mark）： 从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，即不用 “Stop The World”，可以与垃圾收集线程一起并发运行。
• 重新标记（CMS remark） ： 需要 “Stop The World”，该步骤主要是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。并且停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
• 并发清除（CMS concurrent sweep） ： 清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
  

CMS是一款优秀的收集器，并发收集，低停顿，是HotSpot虚拟机追求低停顿的第一次成功尝试，但该收集器至少也有三个明显的缺点：

• 由于存在并发标记，CPU占用比较高，所以对处理器资源非常敏感。
• 无法处理“浮动垃圾”，有可能出现“Con-current Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC的产生。
• 由于CMS收集器是基于标记-清除算法，所以会出现空间碎片的情况。

Garbage First收集器（整堆收集器）

Garbage First（简称G1）收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式，是一款主要面向服务端应用的垃圾收集器。

• 面向局部收集： G1可以面向堆内存任何部分来组成回收集，不再区分属于哪个分代，而是根据哪块内存中存放的垃圾数量最多，回收收益最大来进行收集。
• 基于Region的内存布局： G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的 Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

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

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

6、总结

本文主要分析了jvm垃圾回收算法，以及基于这些回收算法实现的垃圾收集器。不得不说，正是这些垃圾收集器，给我们编写java代码带来了极大的方便。所以了解他们的原理也是一个很重要的知识点。
最后，对于文中有什么问题或者意见的地方，欢迎提出交流~

参考资料

《深入理解Java虚拟机：JVM高级特性与最佳实践（第三版）》
https://www.jianshu.com/p/5261a62e4d29
https://xie.infoq.cn/article/9d4830f6c0c1e2df0753f9858
https://juejin.cn/post/6844904057602064391