垃圾回收机制

核心概念

垃圾回收（Garbage Collection）是 JVM 自动内存管理的核心机制。理解 GC 原理是 JVM 调优和面试的重中之重。

垃圾判定算法

1. 引用计数法（Reference Counting）

• 每个对象维护一个引用计数器

• 有引用指向时 +1，引用失效时 -1

• 计数为 0 时可回收

缺陷：无法解决循环引用问题

// 循环引用示例
public class CircularReferenceDemo {
    Object instance = null;

    public static void main(String[] args) {
        CircularReferenceDemo a = new CircularReferenceDemo();
        CircularReferenceDemo b = new CircularReferenceDemo();
        a.instance = b;
        b.instance = a;
        a = null;
        b = null;
        // 引用计数法无法回收 a 和 b 指向的对象
        System.gc();
    }
}

2. 可达性分析（Reachability Analysis）⭐

JVM 实际使用的算法。从 GC Roots 出发，能到达的对象为存活对象。

GC Roots 包括

1. 虚拟机栈中引用的对象（局部变量）

2. 方法区中类静态属性引用的对象（static 字段）

3. 方法区中常量引用的对象（final static 字段）

4. 本地方法栈中 JNI 引用的对象

5. JVM 内部引用（基本类型的 Class 对象、常驻异常对象等）

6. 被同步锁（synchronized）持有的对象

四种引用类型

// 1. 强引用 - 不会被回收
Object obj = new Object();

// 2. 软引用 - 内存不足时回收（适合做缓存）
SoftReference<Object> softRef = new SoftReference<>(new Object());

// 3. 弱引用 - 下次 GC 时回收
WeakReference<Object> weakRef = new WeakReference<>(new Object());

// 4. 虚引用 - 无法通过虚引用获取对象，用于跟踪回收活动
PhantomReference<Object> phantomRef =
    new PhantomReference<>(new Object(), new ReferenceQueue<>());

引用类型	回收时机	典型应用
强引用	不回收	普通对象引用
软引用	内存不足时	缓存
弱引用	下次 GC	WeakHashMap、ThreadLocal
虚引用	随时	堆外内存管理、回收跟踪

finalize() 方法

• 对象被判定不可达后，会检查是否覆盖了 finalize()

• 如果覆盖且未执行过，放入 F-Queue 队列，由 Finalizer 线程执行

• 不推荐使用：执行时机不确定，可能导致对象"复活"

• JDK 9 起已被标记为 @Deprecated

垃圾回收算法

1. 标记-清除（Mark-Sweep）

标记前:  [A] [B] [C] [D] [E] [F]
标记后:  [A] [×] [C] [×] [E] [×]   ← 标记不可达对象
清除后:  [A] [_] [C] [_] [E] [_]   ← 直接清除

• 优点：实现简单

• 缺点：产生内存碎片，分配大对象时可能触发提前 GC

2. 标记-复制（Mark-Copy）

From:    [A] [×] [C] [×] [E]
                  ↓ 复制存活对象
To:      [A] [C] [E] [_] [_]

• 优点：无内存碎片，分配速度快（指针碰撞）

• 缺点：可用内存减半

• 应用：新生代（Eden + S0 → S1）

3. 标记-整理（Mark-Compact）

标记后:  [A] [_] [C] [_] [E] [_]
整理后:  [A] [C] [E] [_] [_] [_]   ← 向一端移动

• 优点：无内存碎片

• 缺点：需要移动对象，开销较大

• 应用：老年代

4. 分代收集（Generational Collection）

                   对象分配
                      ↓
┌────────────────────────────────────┐
│  新生代 (Young Generation)         │ ← Minor GC（频繁、速度快）
│  Eden → S0/S1（标记-复制算法）      │    对象年龄 +1，达到阈值晋升
├────────────────────────────────────┤
│  老年代 (Old Generation)           │ ← Major GC / Full GC（较慢）
│  （标记-清除 或 标记-整理）          │
└────────────────────────────────────┘

对象晋升老年代的条件

1. 年龄达到阈值：默认 15 次 Minor GC（-XX:MaxTenuringThreshold）

2. 大对象直接进入老年代：-XX:PretenureSizeThreshold

3. 动态年龄判断：Survivor 中相同年龄对象大小总和 > Survivor 空间一半

4. Survivor 空间不足：Minor GC 后存活对象放不下

垃圾收集器

收集器总览

         新生代                        老年代
┌──────────────────┐        ┌──────────────────────┐
│  Serial           │───────▶│  Serial Old           │
│  ParNew           │───────▶│  CMS                  │
│  Parallel Scavenge│───────▶│  Parallel Old         │
└──────────────────┘        └──────────────────────┘

       整堆收集器
┌──────────────────────────────────────────────────┐
│  G1                                               │
│  ZGC                                              │
│  Shenandoah                                       │
└──────────────────────────────────────────────────┘

Serial / Serial Old

• 单线程收集器

• 收集时必须 Stop The World (STW)

• 适合：客户端模式、小内存应用

-XX:+UseSerialGC

ParNew

• Serial 的多线程版本

• 常与 CMS 配合使用

• 除了多线程外和 Serial 几乎一样

-XX:+UseParNewGC
-XX:ParallelGCThreads=4

Parallel Scavenge / Parallel Old

• 吞吐量优先收集器

• 自适应调节策略：-XX:+UseAdaptiveSizePolicy

• JDK 8 默认收集器

-XX:+UseParallelGC
-XX:MaxGCPauseMillis=200    # 最大停顿时间目标
-XX:GCTimeRatio=99          # 吞吐量目标（GC 时间占比 1%）

CMS（Concurrent Mark Sweep）⭐⭐⭐⭐⭐

以最短停顿时间为目标的收集器，使用标记-清除算法。

四个阶段

1. 初始标记 (Initial Mark)     ← STW，仅标记 GC Roots 直接关联的对象，速度快
2. 并发标记 (Concurrent Mark)  ← 与用户线程并发，遍历对象图
3. 重新标记 (Remark)           ← STW，修正并发标记期间变动的引用
4. 并发清除 (Concurrent Sweep) ← 与用户线程并发，清除垃圾对象

缺点

1. CPU 敏感：并发阶段占用 CPU 资源

2. 浮动垃圾：并发清除阶段新产生的垃圾需下次 GC 处理

3. 内存碎片：标记-清除算法导致碎片

4. Concurrent Mode Failure：预留内存不足时退化为 Serial Old

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75  # 触发 CMS 的老年代使用率
-XX:+UseCMSCompactAtFullCollection     # Full GC 后整理碎片

G1（Garbage First）⭐⭐⭐⭐⭐

面向服务端的收集器，JDK 9 起成为默认收集器。

核心设计

┌───┬───┬───┬───┬───┬───┬───┬───┐
│ E │ O │ S │ E │ H │ O │ E │ S │  ← Region 划分
├───┼───┼───┼───┼───┼───┼───┼───┤
│ O │   │ E │ O │ H │ E │   │ O │  E=Eden S=Survivor
├───┼───┼───┼───┼───┼───┼───┼───┤  O=Old  H=Humongous
│ E │ O │   │ S │ O │   │ E │ O │
└───┴───┴───┴───┴───┴───┴───┴───┘

• Region：堆被划分为大小相等的 Region（1MB-32MB）

• Humongous Region：存放大对象（超过 Region 50%）

• Remembered Set：记录跨 Region 引用，避免全堆扫描

• Collection Set (CSet)：每次 GC 选择回收价值最高的 Region

回收过程

1. Young GC：回收所有 Eden 和 Survivor Region

2. 并发标记：类似 CMS，与用户线程并发

3. 混合回收（Mixed GC）：回收 Young + 部分 Old Region（优先回收垃圾最多的）

停顿预测模型

• 记录每个 Region 的回收耗时和垃圾比例

• 在 -XX:MaxGCPauseMillis 约束内选择回收收益最大的 Region

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200        # 停顿时间目标
-XX:G1HeapRegionSize=4m         # Region 大小
-XX:InitiatingHeapOccupancyPercent=45  # 触发并发标记的堆占用率

ZGC ⭐⭐⭐⭐

超低延迟收集器，停顿时间不超过 1ms。

核心技术

• 着色指针（Colored Pointers）：在指针中存储 GC 元数据

• 读屏障（Load Barrier）：在对象引用被读取时检查并修正

• 并发处理：几乎所有阶段都与用户线程并发

-XX:+UseZGC
-XX:SoftMaxHeapSize=4g   # 软性堆大小上限

适用场景

• 超大堆（TB 级别）

• 对延迟极其敏感的应用

• JDK 15+ 生产可用

Shenandoah

• 与 ZGC 类似的低延迟收集器

• 使用转发指针（Brooks Pointer） 实现并发整理

• OpenJDK 项目，非 Oracle JDK

GC 日志分析

开启 GC 日志

# JDK 8
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

# JDK 9+（统一日志框架）
-Xlog:gc*:file=gc.log:time,uptime,level,tags

G1 GC 日志示例

[2026-03-18T10:15:30.123+0800] GC(12) Pause Young (Normal) (G1 Evacuation Pause)
[2026-03-18T10:15:30.123+0800] GC(12)   Eden regions: 24->0(24)
[2026-03-18T10:15:30.123+0800] GC(12)   Survivor regions: 3->3(4)
[2026-03-18T10:15:30.123+0800] GC(12)   Old regions: 10->12
[2026-03-18T10:15:30.123+0800] GC(12)   Humongous regions: 0->0
[2026-03-18T10:15:30.123+0800] GC(12) Pause Young (Normal) 37M->15M(256M) 8.234ms

关键指标：

• 回收前后堆大小：37M -> 15M

• 停顿时间：8.234ms

• 各区域变化：Eden 24->0，Old 10->12

面试要点

高频问题

1. 如何判断对象是否可以被回收？

   • 可达性分析，从 GC Roots 出发不可达的对象

2. CMS 和 G1 的区别？

   • CMS 用标记-清除，G1 用标记-复制/整理

   • CMS 只收集老年代，G1 整堆收集

   • G1 可预测停顿时间，CMS 不可以

   • G1 无内存碎片问题

3. Minor GC、Major GC、Full GC 的区别？

   • Minor GC：只回收新生代

   • Major GC：只回收老年代（常与 Full GC 混用）

   • Full GC：回收整个堆 + 方法区

4. 什么时候触发 Full GC？

   • 老年代空间不足

   • 方法区空间不足

   • 调用 System.gc()（建议，不保证）

   • CMS Concurrent Mode Failure

   • 晋升失败（Promotion Failed）

5. 如何选择垃圾收集器？

   • 延迟敏感 → G1 / ZGC

   • 吞吐量优先 → Parallel Scavenge

   • 小内存（< 100MB）→ Serial

   • 大堆 + 超低延迟 → ZGC

常见陷阱

• System.gc() 只是建议 JVM 做 GC，不保证执行

• Minor GC 并不只回收 Eden，也包括 Survivor

• G1 并不是完全无停顿，只是停顿时间可控

参考资料

• 《深入理解 Java 虚拟机》第 3 章 - 周志明

• HotSpot Virtual Machine Garbage Collection Tuning Guide

• JEP 333: ZGC: A Scalable Low-Latency Garbage Collector