【java基础系列】之垃圾回收器及回收算法

本章和大家聊一下jvm的垃圾收集器以及对应的垃圾收集算法，可能大部分同学对于GC方面的了解程度还停留在面试那一级别，如果问起什么三色标记算法，可能有些同学就不知道啦，下面就和大家一起整体了解下GC和它的一些延伸知识点

你懂的越多，你不懂的越多

点击图片进入我的博客

垃圾收集算法

本章大概介绍几个常见的垃圾收集算法：复制算法、标记-清除、标记-整理、分代回收

标记-清除算法

算法分为"标记"和“清除”两个阶段：首先扫描所有对象标记出需要回收的对象，在标记完成后扫描回收所有被标记的对象，所以需要扫描两遍。回收效率略低，如果大部分对象是朝生夕死，那么回收效率降低，因为需要大量标记对象和回收对象

它的主要问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾回收动作。回收的时候如果需要回收的对象越多，需要做的标记和清除的工作越多，所以标记清除算法适用于老年代。

复制算法

为了解决标记-清除算法带来的碎片问题，复制算法就被提出来了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yWJPM1Lz-1607582278753)(https://www.keepting.cn/static/upload/20201208/67vxgA-Z8_8U-KXJiRGYhPm4.png)]

只是这种算法的代价是将内存缩小为了原来的一半。但是要注意：内存移动是必须实打实的移动（复制），所以对应的引用（直接指针）需要调整。

复制回收算法适合于新生代，因为大部分对象朝生夕死，那么复制过去的对象比较少，效率自然就高，另外一半的一次性清理是很快的。

标记-整理算法

为了解决复制算法的缺陷，充分利用内存空间，便推出了标记-整理算法：首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记整理算法虽然没有内存碎片，但是效率偏低。

我们看到标记整理与标记清除算法的区别主要在于对象的移动。对象移动不单单会加重系统负担，同时需要全程暂停用户线程才能进行，同时所有引用对象的地方都需要更新（直接指针需要调整）。所以看到，老年代采用的标记整理算法与标记清除算法，各有优点，各有缺点。

Generational Collection（分代收集）算法

分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

目前大部分垃圾收集器对于新生代都采取复制算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间（一般称作做From区和To区，也可以叫做S0和S1），每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。

HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有10%的内存会被 “浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）

而由于老年代的特点是每次回收都只回收少量对象，一般使用的是标记-整理算法（压缩法）。

垃圾收集器

回收器名称	回收对象和算法	回收器类型
Serial	新生代，复制算法	单线程(串行)
Parallel Scavenge	新生代，复制算法	并行的多线程回收器
ParNew	新生代，复制算法	并行的多线程回收器
Serial Old	老年代，标记整理算法	单线程(串行)
Parallel Old	老年代，标记整理算法	并行的多线程回收器
CMS	老年代，标记清除算法	并发的多线程回收器
G1	标记整理 + 化整为零	并发的多线程回收器

简单说下前4个不太常用的，重点说下最常用的CMS和G1：

• Serial/Serial Old收集器 是最基本最古老的收集器，它是一个单线程收集器，并且在它进行垃圾收集时，必须暂停所有用户线程。Serial收集器是针对新生代的收集器，采用的是Copying算法，Serial Old收集器是针对老年代的收集器，采用的是Mark-Compact算法。它的优点是实现简单高效，但是缺点是会给用户带来停顿。

• ParNew收集器 是Serial收集器的多线程版本，使用多个线程进行垃圾收集。

• Parallel Scavenge收集器 是一个新生代的多线程收集器（并行收集器），它在回收期间不需要暂停其他用户线程，其采用的是Copying算法，该收集器与前两个收集器有所不同，它主要是为了达到一个可控的吞吐量。

• Parallel Old收集器 是Parallel Scavenge收集器的老年代版本（并行收集器），使用多线程和Mark-Compact算法。

目前最常用的两种垃圾回收器，也不用多说，肯定是CMS和G1，java11推出了一个ZGC（据说回收效率很高，作为了解吧，其实用的不多）。

CMS（Concurrent Mark Sweep）回收器

顾名思义，这是并发的垃圾回收器，这种回收器是一种以获取最短的回收停顿时间为目的的垃圾收集器，其实最短停顿时间是大部分应用
进行垃圾回收时关注的点。这种回收器是基于标记清除的算法实现，它的运作过程相对串行的垃圾回收器相对复杂点，分为以下4个步骤

• 初始标记：进行的时间很短，只标记和GC Root有直接关联的对象，速度极快。

• 并发标记：和用户线程同时进行，标记GC Root开始关联的所有对象，开始遍历整个可达分析的路径对象，这个时间比较长，所以并发。

• 重新标记：短暂，为了修正在并发标记期间因用户线程产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标 记阶段稍长一些，但远比并发标记的时间短。

• 并发清除：由于整个过程中耗时最长的并发标记和并发清除过程，GC线程都可以与用户线程一起工作，所以一般来说，CMS 的内存回收过程是与用户线程一起执行的。-XX:+UseConcMarkSweepGC ，表示新生代使用ParNew，老年代的用CMS。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b5rNverL-1607582278763)(https://www.keepting.cn/static/upload/20201209/uEX6XuQfwpE1cotWW3WOgFyO.png)]

• CPU 敏感：CMS 对CPU资源敏感，毕竟采用了并发的收集、当处理核心数不足 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 发生这样情况会很卡。

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

G1（Garbage First）

随着JVM内存的增大，STW（Stop The World）的时间成为GC 急迫解决的问题，但是如果按照传统的分代模型，总跳不出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 作为老年代的一部分来进行看待。

开启参数：-XX:+UseG1GC
分区大小 ：-XX:+G1HeapRegionSize，一般建议逐渐增大该值，随着 size 增加，垃圾的存活时间更长，GC 间隔更长，但每次 GC 的时间也会更长。
最大GC暂停时间 ：-XX:MaxGCPauseMillis，设置最大GC暂停时间的目标（单位毫秒），这是个软目标，JVM会尽最大可能实现它。

运行过程如下：

• 初始标记：只标记一下与GC Roots有直接关联的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时能正确地在可用的 Region 中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。要达到GC与用户线程并发运行，必须要解决回收过程中新对象的分配，所以G1为每一个Region 区域设计了两个名为TAMS（Top at Mark Start）的指针，从 Region 区域划出一部分空间用于记录并发回收过程中的新对象。这样的对象认为它们是存活的，不纳入垃圾回收范围。

• 并发标记：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户线程并发执行。当扫描完成以后，并发时有引用变动的对象，这些对象会漏标，漏标的对象会被一个叫做SATB(snapshot at the beginning)算法来解决。

• 最终标记：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后的那些漏标对象。

• 筛选回收：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分 Region 的存活对象复制到空的Region中，再清理掉整个旧 Region 的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

总结：

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

2. 分代收集：与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但它能够采用不同的方式 去处理新创建的对象和已经存活了一段时间、熬过多次 GC 的老对象以获取更好的收集效果。

3. 空间整合：与 CMS 的“标记-清理”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着 G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

4. 缩短停顿时间：-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1 尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。

三色标记算法（拓展）

接下来我们了解一个扩展知识点：三色标记算法

在介绍三色标记算法之前，我们先看下之前标记清除算法的缺陷，标记清除算法会设置一个标志位来记录对象是否被使用。最开始所有的标记位都是0，如果发现对象是可达的就会置为1，一步步下去就会呈现一个类似树状的结果。等标记的步骤完成后，会将未被标记的对象统一清理，再次把所有的标记位 设置成0方便下次清理。

它的最大的问题是 GC 执行期间需要把整个程序完全暂停，不能异步进行 GC 操作。因为在不同阶段标志位0和1有不同的含义，那么新增的对象无论标记为什么都有可能意外删除这个对象。对实时性要求高的系统来说，这种需要长时间挂起的标记清扫法是不可接受的。所以就需要一个算法来解决 GC 运行时程序长时间挂起的问题，然后三色标记法就被提出来了。三色标记最大的好处是可以异步执行，以中断时间极少的代价或者完全没有中断来进行整个GC。

在三色标记算法中我们将对象分为三种类型：

• 黑色：根对象，或者该对象与它的子对象都被扫描过。
• 灰色：对本身被扫描，但是还没扫描完该对象的子对象。
• 白色：未被扫描对象，如果扫描完所有对象之后，最终为白色的为不可达对象，既垃圾对象。

假设有3个对象A、B、C，引用关系为A->B->C，那么标记过程如下：

• 首先扫描到A，把A标记为灰色
• 扫描到B，把B标记为灰色，同时A的子对象（只有B）已全部扫描，故将A标记为黑色。
• 重复已上步骤

多标-浮动垃圾

假设当前遍历到B（将B标记为灰色），此时用户线程执行：A.b=null，将A对B的引用删除了（如下图），此时B和C已经是垃圾了，但是G标记线程依然会向下进行，最终将B、C标记为黑色，这部分本该回收但是未被回收的垃圾称为“浮动垃圾”，浮动垃圾并不会影响应用程序的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记开始后的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能会变为垃圾，这也算是浮动垃圾的一部分。

漏标问题

假如当前刚好扫描到B，即将扫描C，然后这时用户线程修改了引用关系：将A引用指向了C（A->C），比如：A.c=C，将B的引用指向了其他对象，或者干脆指向null，那么此时就会变成下图的样子，那么当标记线程标记完B后，发现B没有引用的对象，便将B标记为黑色，所以此时C就被漏标了，导致的最终结果就是C被回收掉，然而它的确还需要被对象A引用，这就是三色标记中的漏标问题。

不难分析，漏标只有同时满足以下两个条件时才会发生：

• 条件一：灰色对象 断开了 白色对象的引用，即灰色对象 原来成员变量的引用 发生了变化。
• 条件二：黑色对象 重新引用了 该白色对象，即黑色对象 成员变量增加了 新的引用。

对于漏标问题，CMS和G1分别有不同的解决方案

CMS的解决方案

CMS提供的解决方案是：Incremental Update 增量更新算法，这种做法的思路是：不要求保留原始快照，而是针对新增的引用，将其记录下来等待遍历，即增量更新（Incremental Update）当一个白色对象被一个黑色对象引用，将黑色对象重新标记为灰色，让垃圾回收器重新扫描。

增量更新破坏了条件二：【黑色对象 重新引用了 该白色对象】，从而保证了不会漏标。

G1的解决方案

STAB（snapshot at the beginning）算法：
这种做法的思路是：尝试保留开始时的对象图，即原始快照（Snapshot At The Beginning，SATB），当某个时刻 的GC Roots确定后，当时的对象图（快照）就已经确定了。

比如 当时 A是引用着B的，那后续的标记也应该是按照这个时刻的对象图走（A引用着B）。如果期间发生变化，则可以记录起来，保证标记依然按照原本的视图来（关于JVM如何保存快照，有兴趣的同学可以自己去研究下，这里就不说了，贪多嚼不烂）。

SATB破坏了条件一：【灰色对象 断开了 白色对象的引用】，从而保证了不会漏标。

扫描所有GC Roots 这个操作（即初始标记）通常是需要STW的，否则有可能永远都扫不完，因为并发期间可能增加新的GC Roots。

对应 G1 的垃圾回收过程中的：最终标记( Final Marking)对用户线程做另一个短暂的暂停，用于处理并发阶段结后仍遗留下来的最后那少量的 SATB 记录(漏标对象)。

对比两种方案

SATB 算法是关注引用的删除。（B对C 的引用）

Incremental Update 算法关注引用的增加。（A->C 的引用）

G1 如果使用 Incremental Update 算法，因为变成灰色的成员还要重新扫，重新再来一遍，效率太低了。所以 G1 在处理并发标记的过程比 CMS 效率要高，这个主要是解决漏标的算法决定的。

总结

本节我们了解了常见的垃圾回收算法、垃圾收集器以及GC中的三色标记算法，目前用CMS和G1是比较常用的收集器，但是在使用过程中也可能出现一些奇怪的问题，考虑下这些垃圾回收器的底层原理，可能帮助你解决这些问题。