“最粉嫩”的JVM垃圾回收器及算法，抗极限面试，倒背如流

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

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

目前最常用的两种垃圾回收器，也不用多说，肯定是CMS和G1，一般面试官会问下CMS和G1的区别以及各自的特点，不太会深入问实现原理，毕竟Java面试可问的知识点实在太多了，都一个个深入问1个小时的面试时间根本不够。

串行的垃圾回收器就不说了，这里专门讲下并发的垃圾回收器

CMS（Concurrent Mark Sweep）回收器

顾名思义，这是并发的垃圾回收器，这种回收器是一种以获取最短的回收停顿时间为目的的垃圾收集器，目前很大一部分Java的互联网应用或者B/S系统的服务器上，由于这类应用尤其在意相应速度，希望系统停顿时间越短越好，这样用户体验也会更好，CMS就非常符合这类应用的需求。

从名字就可以看出，这种回收器是基于标记清除的算法实现，它的运作过程相对串行的垃圾回收器相对复杂点，分为以下4个步骤

初始标记：很短，仅仅只是标记下GC Root能直接关联的对象，速度极快。

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

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

并发清除：由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，一般来说，CMS 的内存回收过程是与用户线程一起执行的。-XX:+UseConcMarkSweepGC ，表示新生代使用ParNew，老年代的用 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 发生这样情况会很卡。

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

该垃圾回收器适合回收堆空间几个 G至20G。

G1（Garbage First）

随着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 作为老年代的一部分来进行看待。

开启参数 -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)算法来解决。

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

筛选回收：负责更新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 尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。

并发标记

三色标记算法

说到并发标记，就不能不提下并发标记中的三色标记算法，它是一种描述追踪式回收器的有效的办法，利用它可以推演回收器的正确性。

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

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

我们将对象分为三种类型：

黑色：根对象，或者该对象与它的子对象都被扫描过。

灰色：对本身被扫描，但是还没扫描完该对象的子对象。

白色：未被扫描对象，如果扫描完所有对象之后，最终为白色的为不可达对象，既垃圾对象。

以上图为例，简单说下三色标记的实现原理，首先如上图所示，线程1已完成所有标记，所有对象都被标记成黑色；线程2还处于半完成状态，其中对象B本身已被扫描，但是还没有扫描该对象的子对象。

由于垃圾回收的线程和正常业务线程都在执行中，并没有中断，如果此时业务代码如下：A.c = C B.c = null 则如下图

此时线程1由于已经完成所有扫描，则对象C被遗漏标记为黑色；而线程2完成扫描，将对象B标记为黑色，线程2此时也完成所有扫描，问题就来了，对象C被漏标了。

对象C被漏标的直接后果就是被回收。然而它的确还需要被对象A引用，这就是三色标记中的漏标问题。

如何解决并发标记中的漏标问题？

CMS的解决方案

Incremental Update 增量更新算法：

当一个白色对象被一个黑色对象引用，将黑色对象重新标记为灰色，让垃圾回收器重新扫描。

G1的解决方案

最后

我想问下大家当初选择做程序员的初衷是什么？有思考过这个问题吗？高薪？热爱？

既然入了这行就应该知道，这个行业是靠本事吃饭的，你想要拿高薪没有问题，请好好磨练自己的技术，不要抱怨。有的人通过培训可以让自己成长，有些人可以通过自律强大的自学能力成长，如果你两者都不占，还怎么拿高薪？

架构师是很多程序员的职业目标，一个好的架构师是不愁所谓的35岁高龄门槛的，到了那个时候，照样大把的企业挖他。为什么很多人想进阿里巴巴，无非不是福利待遇好以及优质的人脉资源，这对个人职业发展是有非常大帮助的。

如果你也想成为一名好的架构师，那或许这份Java核心架构笔记你需要阅读阅读，希望能够对你的职业发展有所帮助。

中高级开发必知必会：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
备注Java）**
[外链图片转存中…(img-U5afj8YU-1713577902158)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！