4. 垃圾回收机制(GC)

本文内容基于个人对特定技术的理解和实践，或为对相关技术内容的整理与分享。请读者批判性阅读，如有疏漏或不准确之处，恳请斧正。

垃圾回收机制 (Garbage Collection - GC)

Heap与Method Area 内存中的死亡对象，需要通过垃圾回收器GC进行判断并回收。

对象存活判断

对象存活检测算法：

1. 引用计数法：一个对象被引用时，将计数器+1，引用失效时，计数器-1。GC时将计数器为0的对象标记为死亡。该方法存在循环引用的问题。

   结局方案：一方使用弱引用，从而避免循环增加计数；检查循环引用之间的对象有没有外部引用

2. 可达性分析算法：从根节点GC Roots（选定一些对象）出发，判断能否到达某个对象，如果无法到达，则标记为死亡。

缓刑阶段（Java 9 Deprecated / Java 21 Deprecation for Removal)

Object.finalize() 用于对象被垃圾回收器回收时执行一次自我清理的操作，例如打开了一个文件，然后在对象被回收时通过 finalize()回收这个文件。这种机制存在一些缺陷：

1. 打破了 GC 的回收逻辑，需要两次 GC 才能回收该对象，并且在 finalize 阶段，将其他对象指向当前对象会复活该对象。
2. Finalize 调用是随机的，无法预测和管理，例如一直创建对象并绑定到一个文件，但是对象没有回收，则 finalize() 不执行，导致内存耗尽。

其替代方式为：try-with-resources / java.lang.ref.Cleaner。

实现了 finalize 的对象会在 GC 中经历两次 GC 周期进行删除。在GC 的第一次标记中会判断对象是否实现finalize方法而决定直接回收还是放入到F-Queue中，然后通过Finalizer Thread 调用这些对象的finalize() 方法，如果这些对象产生了新的引用（复活），则移出队列，否则真正的回收。二次标记取决于对象是否重写了finalize() 方法。单线程并且低优先级的的 Finalizer 守护线程并不可靠，线程阻塞会导致对象积压，引发 OOM 甚至程序崩溃。

引用类型

Jdk1.2之后，Java判断对象存活的粒度从是否存在转变为了引用强度。可达性分析算法是判断两个对象之间的引用从而判断对象是否存活进而清除，而多种引用类型的引入弱化了部分引用的强度，提升了GC的回收率。

1. 强引用：表示被引用的对象依然存活，即将触发OOM也不会强制回收。
2. 软引用：根据可计算的保质期或者在Full GC（即将OOM） 时回收软引用对象。具体来说 GC 会采用LRU 策略并结合剩余堆内存空间计算出“保质期”， 而每个对象也会记录最近的被使用时间，在GC时会检测软引用对象是否超过保质期并回收。
3. 弱引用：只要GC开始工作，都会被回收
4. 虚引用：并非真正的引用，只是该对象被回收时会发送一条通知。

其中 软、弱、虚引用的对象被GC回收时，可以选择加入ReferenceQueue 中（虚引用必须加入），以便用户程序可以知晓某些资源需要被回收。

其执行流程为:

flowchart TDStart[新对象申请内存] --> Check1{内存够吗?}Check1 -- 够 --> Success[分配成功]Check1 -- 不够 --> Step1%% 第一道防线：常规 GCsubgraph Stage1 ["防线 1: 常规 GC"]Step1["触发 Minor/Mixed/Concurrent GC"]Action1["1. 回收 弱引用 WeakReference<br/>2. 回收 **过期** 的软引用"]Step1 --> Action1endAction1 --> Check2{够了吗?}Check2 -- 够了 --> SuccessCheck2 -- 不够 --> Step2%% 第二道防线：OOM 前的抢救subgraph Stage2 ["防线 2: 暴力抢救 (濒临 OOM)"]Step2["触发 Full GC (G1) 或 同步 GC (ZGC)"]Action2[**无条件清空 所有 软引用**]Step2 --> Action2endAction2 --> Check3{还是不够?}%% 结局Check3 -- 腾出空间了 --> SuccessCheck3 -- 真的没了 --> OOM((抛出 OOM))%% 样式调整style OOM fill:#ff0000,color:#fff,stroke:#333,stroke-width:2pxstyle Action2 fill:#ffcc00,stroke:#333,stroke-width:2px

GC算法

基础方法论

1. 标记-清除

   标记死亡对象后直接原地删除，优点速度快，缺点是容易产生碎片，导致大对象内存难以分配，被迫触发GC。

2. 标记-复制

   标记死亡对象后，将存活对象放置到另一块中，然后直接清空原始区域，优点没有内存碎片，缺点是浪费空间。

3. 标记-整理

   标记死亡对象后，将存活对象防止到内存区域的一侧，然后清理掉另外一侧，优点是内存空间仍完整可用，并且没有内存碎片，缺点是较为耗时。

分代收集

• 核心假设：

  1. 绝大多数对象都是“朝生夕死”的。
  2. 熬过越多次 GC 的对象越难消亡。

• 常规做法：

  • 新生代 (Young Gen)：对象存活率低，选用 标记-复制算法。
  • 老年代 (Old Gen)：对象存活率高、没有额外空间担保，一般选用 标记-清除 或 标记-整理。
  • 新生代的对象存活几个周期后，会被移入老年代，大对象可以直接分配到老年代，避免在新生代中频繁的移动。

• Card Table

  大部分的GC都基于上面的核心假设，采用分代的内存管理以及GC方式。其中Major/Young GC会对年轻代对象进行扫描，以找到其中需要回收的垃圾对象，但是有一部分存活对象只有老年代的引用（跨代引用）。为了避免在 Minor GC 时全量扫描老年代来查找这些引用，可以使用Card Table 记录记录老年代引用了年轻代对象。

  JVM 按照512B的格式将整个堆内存分块为一个个的 Card，并用Card Table 表示。如果区域的老年代引用了年轻代，则通过写屏障技术，更新其CardTable中所在位置的元素。

• Remembered Set

  记忆集是一个更加抽象的概念，表示非收集区域指向收集区域的指针集合，在G1收集器中采用了RSet 在年轻代Region中记录指向自身的老年代Region地址，这样做的好处是回收某个Region时不需要扫描全部内存区域，缺点是信息需要存储的更多，浪费了可用内存。

并发收集相关算法

三色标记算法

三色标记法通过白色（未访问）、灰色（已访问，但是其引用目标未完全访问），黑色（完全访问）三种颜色标记对象，主要分为三个阶段，三个阶段后如果对象还是白色，则认为可以回收：

1. 初始标记：STW, 将GC Roots直接引用的对象， 标记为灰色（未访问其子节点）
2. 并发标记：解除STW, 应用线程与GC线程并发执行，将灰色集合中的一个对象标记为黑色，并将其引用的所有白色对象标记为灰色，重复此步骤直到灰色集合清空。
3. 重新标记： STW（可选）不断重复第二步，直到队列为空。

对象消失问题

由于并发阶段用户线程是可以正常执行的，所以这个过程中，用户线程对于对象图的修改操作会导致对象消失的问题，当以下两个事件同时发生就会产生对象消失问题。

1. 插入条件：一个黑色节点指向了白色节点；
2. 删除条件：并且所有灰色节点删除了对于该白色节点的引用

也就是说在并发标记阶段由于用户的修改导致了一个存活节点被判定为可以回收，不同的GC 采用了不同的策略：

• CMS（增量更新），破坏条件 1，黑色节点产生的新引用后会被重新标记为灰色，必须设置STW 最终标记阶段进行重新扫描，导致性能低下。实现方式是在赋值操作前添加了写屏障的代码以记录该灰色节点。
• G1 (SATB原始快照)，破坏条件 2，通过写屏障保留被删除的引用，并加入到集合中，等待 STW 的最终标记阶段扫描少量的SATB 队列。对于新分配的对象则直接标记为黑色。
• ZGC（染色指针&读屏障），破坏条件 1， 当一个白色节点赋值给一个黑色节点之前，读屏障的会立即检查白色节点指针，并将其染成当前周期的标记色。
• Generational Shenandoah（SATB + Load Barrier）：与G1 一致，采用SATB ，只回收GC开始前的对象。

垃圾收集器

选择合适的垃圾收集器有助于提升程序性能，相反不合适的垃圾收集器可能会降低程序性能，一般由以下三个指标来衡量GC的优化效果。

• 吞吐量：表明程序执行的有效时间，越高越好

$$
\text{吞吐量} = \frac{\text{运行用户代码时间}}{\text{运行用户代码时间} + \text{GC 垃圾回收时间}}
$$

• 暂停时间：GC时程序暂停(STW)的最长时间，越小越好
• 内存占用：GC所需要的额外的内存开销，以及所适合的堆内存大小，越小越好

对于 G1 来说，其追求的是可控的暂停时间，所以三个指标比较均衡，而 ZGC 与 Shenandoah 为了追求极低的暂停时间，需要消耗更多的 CPU 与内存，导致吞吐量与内存占用略差于 G1。

CMS 简述

CMS(Concurrent Mark Sweep) 用于 Major GC，一般与ParNew 的 Young GC 组合使用。主要采用三色标记算法，在初始标记时较短的STW，并发标记和清除性能尚可，最终标记可能稍长时间的 STW。其存在 CPU 占用高、无法处理浮动垃圾等缺点，但是其采用了标记-清除算法导致了过多的内存碎片产生，以及预留内存（浮动垃圾）不足，导致在 GC 运行时内存又不足以分配，而产生的严重的并发失败问题：将会强行启动 Serial Old （JDK8 标记-整理），使用单线程对老年代进行标记-整理，可能会 STW 几十秒到几分钟。

G1 简述

G1 (Garbage First) 是一个分代分区（Region之间标记-复制，整体看作标记-整理） 的垃圾收集器，其特点是支持配置最大停顿时间，一次GC时会尽力满足该时间内完成垃圾回收。G1 支持 Young GC 模式以及 Mixed GC 模式，会根据GC停顿时间进行年轻代区域大小的划分，确保当年轻代满了之后可以在一次Young GC 内回收完毕。

当堆内存占用超过 45% 时，G1 执行一次并发标记以计算 Region 价值，随后切换到 Mixed GC 模式，按照 Region 价值顺序执行多次 Mixed GC （每一次都STW，但是尽量满足最大暂停时间）以降低堆内存占用到45% 以下。

当内存分配速度超过GC 速度时，也会触发 Full GC，但是采用了多线程的方式，性能优于 CMS，且大对象会直接分配到Humongous Region中（逻辑参考老年代，GC 时会直接释放空间），避免拷贝开销。

从指标来看，G1 不追求极低的暂停时间，而是通过可控的暂停时间下，尽量保证吞吐量。

ZGC 简述

ZGC (Z Garbage Collector) 是一款基于分页（ZPage）和染色指针技术的低延迟垃圾收集器。

在内存布局方面，采用了动态大小的ZPage 作为管理单位并对齐到 OS Page，从而提升 TLB 访问效率。实现了全流程的并发（标记、转移、重映射），核心依赖与染色指针存储对象状态，配合读屏障来解决并发冲突：

• 并发标记阶段，利用读屏障实现强三色不变性，应用线程读取对象引用，则将其标记为当前标记色
• 并发转移阶段，将对象复制到新页，并利用 Forward Table 记录对象的新地址。如果应用程序访问存活对象，则会被读屏障拦截，立即复制该对象并修正旧地址的引用，称为自愈能力。
• 并发重映射阶段，修正旧地址的引用，ZGC 会将这一步合并到下一次 GC 的并发标记阶段。

从指标来看，ZGC 可以达到极低的暂停时间，但是会带来GC并发线程的CPU以及额外空间（Forward Table）的内存占用，非常适合大内存且对响应时间敏感的场景。

Generational Shenandoah 简述

1. 目标与ZGC 类似，设计为超低延迟（10ms 级别）的并发垃圾收集器，支持多种回收算法：
   1. 自适应回收
   2. 设定回收堆大小的阈值。
   3. 紧凑型回收，距离上一次回收后内存分配的阈值来确定立即进行下一次回收
2. 支持在较低版本的JDK8 / JDK 11使用超低延迟的方案。
3. 采用了CardTable 以支持分代，并使用SATB方式，只回收GC开始前存活的对象
4. Forwarding Pointer ：对象头上会添加“自我指针”，保存着GC后的对象所在位置，当访问到旧对象的时候，会被读屏障拦截，重新定位到新的地址。

三者的STW差异

G1 的Young GC 是STW的，其停顿预测模型会根据停顿时间通过Parallel 方式快速回收，其中较为耗时的部分是将存活对象复制到其他的Region ，如果将停顿时间设置过短，就会导致分配的年轻代区域空间过小，最终导致OOM。

而 ZGC 与 Shenandoah 采用了并发标记、转移的方式，并结合染色指针+写屏障/自我指针+读屏障的方式，即使在并发过程中应用线程访问了对象，也可以被屏障拦截立即纠错应用指针，所以可以降低STW时间。