JVM垃圾回收

1. Java垃圾回收机制

为了让程序员更专注于代码的实现，而不用过多的考虑内存释放的问题，所以，在Java语言中，有了自动的垃圾回收机制，也就是我们熟悉的GC(Garbage Collection)。
有了垃圾回收机制后，程序员只需要关心内存的申请即可，内存的释放由系统自动识别完成。
当对象被认定为垃圾，就会用垃圾回收器采用对应的垃圾回收算法，自动垃圾回收

2. 怎么判定对象是垃圾

如果一个对象没有任何的引用指向它了，那么这个对象现在就是垃圾，如果定位了垃圾，则有可能会被垃圾回收器回收。
如何判定什么是垃圾？
- 引用计数法
- 可达性分析算法

2.1 引用计数法

概念

一个对象被引用了一次，在当前的对象头上递增一次引用次数，如果这个对象的引用次数为0，代表这个对象可回收

String demo = new String(“123”);

String demo = null;

优点

实时性较高，无需等到内存不够的时候，才开始回收，运行时根据对象的计数器是否为0，就可以直接回收。
在垃圾回收过程中，应用无需挂起。如果申请内存时，内存不足，则立刻报OOM错误。
区域性，更新对象的计数器时，只是影响到该对象，不会扫描全部对象。

缺点

每次对象被引用时，都需要去更新计数器，有一点时间开销。
浪费CPU资源，即使内存够用，仍然在运行时进行计数器的统计。
无法解决循环引用问题，会引发内存泄露。（最大的缺点）

循环引用

当对象间出现了循环引用的话，则引用计数法就会失效
在这里插入图片描述
先执行右侧代码的前4行代码

目前上方的引用关系和计数都是没问题的，但是，如果代码继续往下执行，如下图

虽然a和b都为null，但是由于a和b存在循环引用，这样a和b永远都不会被回收。

2.2 可达性分析算法

概念

会存在一个根节点【GC Roots】，引出它下面指向的下一个节点，再以下一个节点开始找出它下面的节点，依次往下类推。直到所有的节点全部遍历完毕。

根对象是那些肯定不能当做垃圾回收的对象，就可以当做根对象
局部变量，静态方法，静态变量，类信息
核心是：判断某对象是否与根对象有直接或间接的引用，如果没有被引用，则可以当做垃圾回收

在这里插入图片描述

GC ROOTS

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

/**
demo是栈帧中的本地变量，当 demo = null 时，由于此时 demo 充当了 GC Root 的作用，
demo与原来指向的实例 new Demo() 断开了连接，对象被回收。
*/
public class Demo {public static  void main(String[] args) {Demo demo = new Demo();demo = null;}
}

方法区中类静态属性引用的对象

/**
当栈帧中的本地变量 b = null 时，由于 b 原来指向的对象与 GC Root (变量 b) 断开了连接，
所以 b 原来指向的对象会被回收，而由于我们给 a 赋值了变量的引用，
a在此时是类静态属性引用，充当了 GC Root 的作用，它指向的对象依然存活!
*/
public class Demo {public static Demo a;public static  void main(String[] args) {Demo b = new Demo();b.a = new Demo();b = null;}
}

方法区中常量引用的对象

/**
常量 a 指向的对象并不会因为 demo 指向的对象被回收而回收
*/
public class Demo {public static final Demo a = new Demo();public static  void main(String[] args) {Demo demo = new Demo();demo = null;}
}

优点

有效处理循环引用
准确性高
无需频繁更新引用计数

缺点

遍历对象时需要暂停用户线程（STW），导致程序短暂卡顿。堆内存越大，停顿时间可能越长，对实时性要求高的应用（如交易系统）影响较大。
实现复杂度高需要维护正确的GC Roots集合，并处理多线程环境下的对象状态变化（如并发标记时的“浮动垃圾”）。并发收集器（如CMS、G1）需额外处理漏标、误标等问题，算法实现较为复杂。
若GC Roots定义不当（如遗漏某些根对象），可能导致内存泄漏或误回收。例如，未及时清理的静态变量可能长期占据内存。

3. 垃圾回收算法

3.1 标记清除算法

概念

标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。
- 根据可达性分析算法得出的垃圾进行标记
- 对这些标记为可回收的内容进行垃圾回收

[图片]

标记清除算法解决了引用计数算法中的循环引用的问题，没有从root节点引用的对象都会被回收。

缺点：

效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
（重要）通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。

3.2 标记复制算法

复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。
如果内存中的垃圾对象较多，需要复制的对象就较少，这种情况下适合使用该方式并且效率比较高，反之，则不适合。

在这里插入图片描述

将内存区域分成两部分，每次操作其中一个。
当进行垃圾回收时，将正在使用的内存区域中的存活对象移动到未使用的内存区域。当移动完对这部分内存区域一次性清除。
周而复始。

优点：

在垃圾对象多的情况下，效率较高
清理后，内存无碎片

缺点：

分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低

3.3 标记整理算法

标记整理算法是在标记清除算法的基础之上，做了优化改进的算法。
和标记清除算法一样，也是从根节点开始，对对象的引用进行标记
在清理阶段，并不是简单的直接清理可回收对象，而是将存活对象都向内存另一端移动，然后清理边界以外的垃圾，从而解决了碎片化的问题。

在这里插入图片描述

标记垃圾。
需要清除向右边走，不需要清除的向左边走。
清除边界以外的垃圾。

优缺点

同标记清除算法，解决了标记清除算法的碎片化的问题
同时，标记整理算法多了一步，对象移动内存位置的步骤，其效率也有一定的影响。
与复制算法对比：复制算法标记完就复制，但标记整理算法得等把所有存活对象都标记完毕，再进行整理

3.4 分代收集算法

概述

在java8时，堆被分为了两份：新生代和老年代【1：2】，在java7时，还存在一个永久代。
在这里插入图片描述

对于新生代，内部又被分为了三个区域。Eden区，S0区，S1区【8：1：1】
当对新生代产生GC：MinorGC【young GC】
当对老年代代产生GC：Major GC
当对新生代和老年代产生FullGC：新生代 + 老年代完整垃圾回收，暂停时间长，应尽力避免!

工作机制

新创建的对象，都会先分配到eden区
当伊甸园内存不足，标记（可达性分析）伊甸园与 from（现阶段没有）的存活对象
将存活对象采用复制算法复制到 to 中，复制完毕后，伊甸园和 from 内存都得到释放
经过一段时间后伊甸园的内存又出现不足，标记eden区域to区存活的对象，将存活的对象复制到from区
当幸存区对象熬过几次回收（最多15次），晋升到老年代（幸存区内存不足或大对象会导致提前晋升）

4. 垃圾收集器

4.1 CMS（并发）垃圾收集器

概念

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器，该回收器是针对老年代垃圾回收的，是一款以获取最短回收停顿时间为目标的收集器，停顿时间短，用户体验就好。其最大特点是在进行垃圾回收时，应用仍然能正常运行。

CMS工作阶段

初始标记（Initial Mark）：STW，标记GC Roots直接关联的对象。
并发标记（Concurrent Mark）：与用户线程并发，遍历老年代。
重新标记（Remark）：STW，修正并发标记期间的变更（使用增量更新或SATB）。
并发清除（Concurrent Sweep）：删除不可达对象，不整理内存。

在这里插入图片描述

优点

低停顿时间（Low Pause）
- 并发标记与清除：大部分标记（Mark）和清除（Sweep）阶段与用户线程并发执行，显著减少 Stop-The-World（STW）停顿时间，适合对延迟敏感的应用。
分代回收优化
- 主要针对老年代（Old Generation）设计，与新生代的 ParNew 收集器配合使用，形成分代回收体系，减少全局停顿频率。
标记-清除算法
- 采用标记-清除（Mark-Sweep）而非压缩（Compact），减少STW时间，但会导致内存碎片（需权衡）。

缺点

内存碎片问题
- 标记-清除算法不整理内存，长期运行后老年代可能出现碎片，导致 Full GC 时被迫触发单线程的 Serial Old 收集器（压缩整理），造成长时间STW。
CPU资源敏感
- 并发阶段占用CPU资源（与用户线程竞争），可能导致应用吞吐量下降，尤其在多核资源不足时。
浮动垃圾（Floating Garbage）
- 并发标记期间用户线程可能产生新垃圾（标记后新死亡的对象），需预留足够内存空间，否则可能触发并发失败（Concurrent Mode Failure），退化为Full GC。

4. 无法处理巨型对象

对占用连续内存的大对象（Humongous Object）支持不足，分配失败时易触发GC。

4.2 G1垃圾回收器

概述

应用于新生代和老年代，在JDK9之后默认使用 G1
划分成多个区域，每个区域都可以充当 eden，survivor，old， humongous，其中 humongous 专为大对象准备
采用复制算法
响应时间与吞吐量兼顾
分成三个阶段：新生代回收、并发标记、混合收集
如果并发失败（即回收速度赶不上创建新对象速度），会触发 Full GC

流程

Young Collection(年轻代垃圾回收)

初始时，所有区域都处于空闲状态
创建了一些对象，挑出一些空闲区域作为伊甸园区存储这些对象
当伊甸园需要垃圾回收时，挑出一个空闲区域作为幸存区，用复制算法复制存活对象，需要暂停用户线程
随着时间流逝，伊甸园的内存又有不足
将伊甸园以及之前幸存区中的存活对象，采用复制算法，复制到新的幸存区，其中较老对象晋升至老年代

Young Collection + Concurrent Mark (年轻代垃圾回收+并发标记)

当老年代占用内存超过阈值(默认是45%)后，触发并发标记，这时无需暂停用户线程
在这里插入图片描述

并发标记之后，会有重新标记阶段解决漏标问题，此时需要暂停用户线程。
这些都完成后就知道了有哪些存活对象，随后进入混合收集阶段。
此时不会对所有老年代区域进行回收
而是根据暂停时间目标优先回收价值高（存活对象少）的区域（ Gabage First 的由来）。

Mixed Collection (混合垃圾回收)

混合收集阶段中，参与复制的有 eden、survivor、old，下图显示了伊甸园和幸存区的存活对象复制
在这里插入图片描述

下图显示了老年代和幸存区晋升的存活对象的复制
在这里插入图片描述

复制完成，内存得到释放。进入下一轮的新生代回收、并发标记、混合收集

在这里插入图片描述

其中H叫做巨型对象，如果对象非常大，会开辟一块连续的空间存储巨型对象
在这里插入图片描述

优点

并行与并发结合
- 并行：利用多线程加速垃圾回收（如Young GC、Mixed GC）。
- 并发：标记阶段（Concurrent Marking）与用户线程并发执行，减少停顿时间（STW）。
可预测的停顿时间
- 通过将堆划分为多个 Region，优先回收垃圾比例最高的 Region（Garbage-First 策略），允许用户设置期望的最大停顿时间（-XX:MaxGCPauseMillis），适合对延迟敏感的应用。
内存分区模型
- 堆被划分为大小相等的 Region，支持动态分代（无需固定 Young/Old 区大小），灵活应对对象生命周期差异，减少内存碎片。
高效处理大对象
- 专门设计 Humongous Region 存储巨型对象（如大数组），避免大对象分配时对连续内存的依赖。
高吞吐量与低延迟平衡
- 适合大堆内存（如 4GB 以上），在吞吐量和延迟之间取得较好平衡，替代了传统的 CMS

缺点

内存占用较高
- 维护 Region 元数据（如存活对象标记、跨 Region 引用）需要额外内存，相比 CMS 等收集器内存开销更大。
Young GC 延迟较高
- Young GC 需要 STW 暂停，若 Eden Region 较多或对象存活率高，可能导致 Young GC 时间较长。
Mixed GC 依赖全局标记
- Mixed GC（回收部分 Old Region）依赖全局并发标记结果，若并发标记失败（如堆内存不足），可能退化为 Full GC（单线程的 Serial Old），导致长时间停顿。
配置调优复杂
- 需要根据应用负载调整参数（如 Region 大小、MaxGCPauseMillis、IHOP 阈值等），默认配置未必最优，调优门槛较高。
不适用于极小堆
- 对于堆内存较小的应用（如 < 4GB），G1 的分区管理开销可能抵消其优势，此时更适合使用 Parallel GC 或 CMS。