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 标记复制算法

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

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

优点：

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

缺点：

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

3.3 标记整理算法

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

1. 标记垃圾。
2. 需要清除向右边走，不需要清除的向左边走。
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工作阶段

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

优点

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

缺点

1. 内存碎片问题
   • 标记-清除算法不整理内存，长期运行后老年代可能出现碎片，导致 Full GC 时被迫触发单线程的 Serial Old 收集器（压缩整理），造成长时间STW。
2. CPU资源敏感
   • 并发阶段占用CPU资源（与用户线程竞争），可能导致应用吞吐量下降，尤其在多核资源不足时。
3. 浮动垃圾（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叫做巨型对象，如果对象非常大，会开辟一块连续的空间存储巨型对象

优点

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

缺点

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