# 「说说 JVM 垃圾回收」——这题到底在考什么

> 这是一道能同时考出三件事的题：你知不知道 Java 的内存是自动管理的、你能不能说清「自动」背后的代价、以及线上真出问题时你能不能定位。
>
> 下面把它写成一场模拟面试：三轮追问由浅入深，最后给出面试官视角的考点拆解、可直接背诵的 30 秒答案，以及一张带关系说明的知识地图。
>
> 本文默认语境是 HotSpot 虚拟机、JDK 8 / 11 为主；涉及版本差异的地方会单独标注。

---

## 开场：这题为什么高频

先说结论：**垃圾回收（Garbage Collection，GC）是 Java 里少有的、同时横跨「语言特性」「性能调优」「线上排障」三条线的高频题。**

- 语言层面：它是 Java 敢说自己「不用手动 `free`」的底气。
- 性能层面：你调的每一个 `-Xmx`、感受到的每一次卡顿，最后都落在 GC 上。
- 排障层面：线上 CPU 飙高、接口毛刺、OOM，八成要把 GC 日志翻出来。

所以面试官问它，并不是想听你背「新生代、老年代、Eden、Survivor」这串词，而是想看你能不能把「为什么这么设计」讲通。下面开始。

---

## 第一轮：基础题

> **面试官**：先热身。Java 里的「垃圾」指什么？怎么判断一个对象是垃圾？

> **候选人**：垃圾就是**再也不会被程序用到的对象**。判断方式主流有两种：引用计数法和可达性分析。

> **面试官**：Java 用的是哪种？

> **候选人**：可达性分析。

> **面试官**：那为什么不用引用计数法？它看起来更简单。

### 陷阱在哪

引用计数法的定义是：给每个对象记一个「被引用次数」，加一次引用就 +1，减一次就 -1，归零即可回收。听起来很优雅，但有两个致命问题：

1. **循环引用**：A 引用 B、B 引用 A，两者计数都不为 0，可它们已经不可达了 —— 永远不会被回收。这本身就是一种内存泄漏。
2. **维护计数本身要花钱**：每次引用赋值都得同步更新计数，高频操作下吞吐量要打折扣，并发场景还要额外保证计数的原子性。

Java 选了另一条路：**从一组叫 GC Roots 的根对象出发，能走到的对象标记为存活，走不到的一律回收。**

> **面试官**：那 GC Roots 具体是哪些对象？

> **候选人**：以 HotSpot 为例主要有六类：虚拟机栈中局部变量表引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中 JNI 引用的对象、JVM 内部的引用（如基本类型对应的 Class 对象、常驻异常对象）、以及被同步锁 `synchronized` 持有的对象。

这里有个关键直觉：**GC Roots 之所以选中「栈」和「静态变量」，是因为它们代表了「程序当前正在用的东西」。** 一个局部变量还躺在栈帧里，说明方法没返回，它引用的对象当然不能动。

### 验证代码：引用还在不在，决定对象生死

那「引用」本身有没有强弱之分？有。下面这段代码能直接跑出区别：

```java
import java.lang.ref.WeakReference;

public class RefDemo {
    public static void main(String[] args) {
        Object strong = new Object();                                   // 强引用：只要 strong 变量在，绝不回收
        WeakReference<Object> weak = new WeakReference<>(new Object()); // 弱引用：下一次 GC 必被回收

        System.out.println("GC 前 weak = " + weak.get());                // 有值
        System.gc();                                                    // 只是「建议」JVM 回收，HotSpot 通常响应
        System.out.println("GC 后 weak = " + weak.get());                // 大概率 null
        System.out.println("strong = " + strong);                       // 一定还在
    }
}
```

运行结果类似（对象地址因运行而异）：

```
GC 前 weak = java.lang.Object@1b6d3586
GC 后 weak = null
strong = java.lang.Object@4554617c
```

这段代码要证明的是：**引用类型决定了回收时机**，不是所有引用都「死死拉着」对象。强、软、弱、虚四种引用的差别，会在后面的加分项里展开。

---

## 第二轮：往深了问

基础答完，面试官开始递进。

### 追问一：为什么要有分代？

> **面试官**：既然可达性分析能找出所有垃圾，全堆扫一遍不就行了？为什么要分开新生代、老年代？

> **候选人**：因为**全堆扫描太慢，而绝大多数对象活不过第一轮 GC**。分代的目的是让回收操作只作用于一小块区域，降低单次成本。

这套设计的依据是三条经验假说，以 HotSpot 的实践为准：

1. **弱分代假说**：绝大多数对象朝生夕灭。
2. **强分代假说**：熬过越多次 GC 的对象，越难死。
3. **跨代引用假说**：跨代引用相对于同代引用只占极少数。

**陷阱在哪**：很多人能背出「新生代用复制、老年代用标记整理」，却答不出**为什么**。答案就藏在假说里 —— 新生代对象死亡率高，存活下来的只有一小撮，复制它们最划算；老年代对象死亡率低，存活的是大多数，复制成本高得离谱，只能原地整理。

### 追问二：新生代复制算法为什么是 8:1:1？

> **面试官**：复制算法得预留空间。HotSpot 具体怎么做的？

> **候选人**：把新生代切成 Eden 和两块 Survivor，默认比例 8:1:1。新对象优先在 Eden 分配，一次 Minor GC 后，Eden 和一块 Survivor 里的存活对象全部复制到另一块空着的 Survivor。

> **面试官**：那 Survivor 只占 10%，对象多到装不下怎么办？

> **候选人**：这就是**空间分配担保**。放不下时，多出来的对象直接挪进老年代，由老年代做担保。

这里还藏着另一个高频考点：**对象怎么进入老年代**。主要有四条路：

1. **熬够年龄**：每经历一次 Minor GC 年龄 +1，超过 `-XX:MaxTenuringThreshold`（默认 15）就晋升。
2. **动态年龄判定**：Survivor 中相同年龄对象的总和超过该区一半，年龄大于等于它的对象直接晋升，不必等到 15 岁。
3. **大对象直接进**：超过 `-XX:PretenureSizeThreshold` 的对象直接进老年代（该参数只对 Serial / ParNew 有效，对 Parallel Scavenge 无效）。
4. **空间分配担保失败**：上一条。

**陷阱在哪**：「默认年龄 15」是个好记的点，但**动态年龄判定才是线上更常见的提前晋升原因**。只答 15，会显得你没做过实际调优。

### 追问三：并发标记为什么还要 STW？

> **面试官**：CMS 和 G1 都号称「并发收集」，可它们还是要 Stop The World。既然都要停，并发图什么？

> **候选人**：并发的意思是**大部分标记和清理工作与用户线程同时进行**，STW 只发生在很短的几个阶段，用来修正并发期间产生的偏差。

要讲清这个「偏差」，就得先知道**三色标记法**：

- **黑色**：对象本身和它引用的所有对象都扫描完了。
- **灰色**：对象本身扫描了，但它引用的对象还没扫完。
- **白色**：还没被扫描到 —— 如果标记结束时还是白的，就是垃圾。

并发标记时，用户线程一边跑一边改引用，可能把「黑 → 白」的关系搬来搬去导致漏标。漏标必须**同时**满足两个条件：

1. 黑色对象**新增**了指向白色对象的引用；
2. 所有从灰色对象指向该白色对象的引用**都被删除**了。

只要破坏其中一个条件，漏标就不会发生：

- **CMS 用增量更新**：破坏条件 1。写屏障拦下「新增引用」这个动作，重新标记时把这些黑色对象当作根再扫一遍。
- **G1 / Shenandoah 用原始快照（SATB）**：破坏条件 2。写屏障记录「被删除的旧引用」，重新标记时以这些灰色对象为根再扫。

**陷阱在哪**：能说出「三色标记」的人不少，能说清「漏标两个条件」以及「CMS 与 G1 各自破坏的是哪一个」的人很少。这是把基础题答成加分题的分水岭。

---

## 第三轮：场景题

> **面试官**：来个实战的。一个订单查询服务，QPS 不算高，但监控显示每 2 小时左右一次 Full GC，每次停顿 1.2 秒，接口在这期间会集体超时。你怎么查？

（建议先自己想 10 秒，再往下看。）

排查思路分两步，顺序不能反：

**第一步：先看 GC 日志，区分是「内存泄漏」还是「分配过快」。**

- 如果 Full GC 后老年代占用**一路降到底** → 不是泄漏，是分配速率太高，扩堆或调分代比例即可。
- 如果 Full GC 后老年代占用**居高不下、还逐步抬升** → 是内存泄漏。这种情况堆再大也没用，必须找到泄漏点。

**第二步：如果确认是泄漏，用 `jmap -histo:live <pid>` 或导出堆转储，找「数量只增不减」的类。**

最常见的泄漏形态就是**静态集合只进不出**。下面这段代码能在几十秒内复现：

```java
import java.util.ArrayList;
import java.util.List;

public class LeakDemo {
    // static 集合被 GC Roots 直接引用，里面的对象永远可达 → 永远不会被回收
    static final List<byte[]> CACHE = new ArrayList<>();

    public static void main(String[] args) {
        for (int i = 0; ; i++) {                    // 故意不设上限
            CACHE.add(new byte[1024 * 1024]);       // 每次塞 1MB，且没有任何地方移除
            if (i % 20 == 0) {
                System.out.println("已缓存 " + (i + 1) + " MB");
            }
        }
    }
}
```

用 `-Xmx64m` 启动，会稳定抛出：

```
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
```

**为什么要用静态集合演示**：因为它把「泄漏」的本质摊开了 —— **对象没被回收，不是 GC 失灵，而是它始终可达**。GC 的判定标准是可达性，不是「你以为它没用了」。所以排查泄漏永远只做一件事：**找到那条不该存在的强引用链。**

> 诚实性说明：以上是一个典型复现场景，用于讲解排查路径，并非某次真实事故的原始记录。

---

## 面试官视角：这题到底在考什么

面试官问这题，是在分层验证四件事：

1. **概念层**：知道可达性分析、GC Roots。
2. **设计层**：能解释分代假说，说明白「为什么这么切」。
3. **机制层**：能讲三色标记、漏标条件、屏障类型。
4. **工程层**：拿到 GC 日志和监控，能给出可执行的排查路径。

前两层是及格线，第三层是加分线，第四层决定你是不是「真的上线过」。

### 知识地图：它和谁有关

![mermaid diagram](https://developer.qcloudimg.com/http-save/yehe-8667236/a0aa75a6a640b553abdbd703844b0776.png)

每个关联点都说一句话关系，这是本文最该记住的部分：

- **它和可达性分析的关系**：可达性分析是判定「谁是垃圾」的**唯一标准**，不理解 GC Roots 的选取，你就想不通为什么静态集合会泄漏。
- **它和引用计数法的关系**：两者是同一道题（怎么找垃圾）的两种解法，区别是前者能处理循环引用，后者不能。理解这个差异，才能理解 Java 为何弃用它。
- **它和分代收集理论的关系**：分代是可达性分析的**性能补丁** —— 全堆分析太慢，于是用假说把堆切成小块分而治之。
- **它和标记-清除 / 复制 / 整理的关系**：这三个是「标记出来之后怎么处理」的三种算法，是分代方案能落地的**执行手段**。
- **它和 STW 的关系**：STW 是 GC 最大的**副作用**，也是整部收集器演进史的主线 —— 每一代收集器都在缩短 STW。
- **它和 CMS / G1 / ZGC 的关系**：它们是 STW 这条主线上的**解决方案**，从「全停顿」到「低停顿」再到「几乎不停顿」。
- **它和三色标记的关系**：三色标记是并发收集器的**理论基石**，没有它就没有 CMS 和 G1。
- **它和四种引用的关系**：引用类型是留给开发者的**回收时机调节旋钮**，让你能告诉 GC「这个可以先扔」。
- **它和分配策略 / TLAB / 卡表的关系**：这些是 GC 的**配套基础设施** —— 分配策略决定对象出生在哪，TLAB 让分配变快，卡表解决跨代引用扫描。
- **它和 GC 日志 / 调优参数的关系**：这是 GC 在**工程侧的出口**，你调的每个参数，本质都是在和 STW 与吞吐量做交易。
- **它和内存泄漏 / OOM 的关系**：这是 GC 能力边界的**现实表现** —— GC 只能回收不可达对象，可达但已经不用的对象它管不了。

---

## 答不上来怎么办：前置知识补课

如果上面有几节没跟上，按这个顺序补，每个只需记住一句话。

### 1. 运行时数据区与 GC Roots

JVM 运行时把内存分成线程私有（虚拟机栈、本地方法栈、程序计数器）和线程共享（堆、方法区）两部分。**GC 主要管堆和方法区**。GC Roots 之所以选中栈和静态变量，是因为它们代表「当前正在被使用的数据」。

### 2. 三种基础回收算法

| 算法 | 怎么做 | 优点 | 代价 | 典型用途 |
|---|---|---|---|---|
| 标记-清除 | 标记存活对象，清除其余 | 实现简单，不移动对象 | 内存碎片，效率随对象数下降 | CMS 老年代 |
| 标记-复制 | 存活对象复制到另一块空间，原空间整块清空 | 无碎片，分配快 | 浪费一块空间，存活对象多时成本高 | 新生代 |
| 标记-整理 | 标记存活对象并移动到一端，清掉边界外的内存 | 无碎片，不浪费空间 | 移动对象需更新引用，停顿长 | 老年代（吞吐优先型收集器） |

一句话记忆：**清除省空间但留碎片，复制无碎片但费空间，整理两者都要但更慢。**

### 3. 四种引用类型

| 引用 | 回收时机 | 典型用途 |
|---|---|---|
| 强引用 | 只要可达就不回收 | 普通 `new` 出来的对象 |
| 软引用 `SoftReference` | 内存不足时才回收 | 内存敏感型缓存 |
| 弱引用 `WeakReference` | 下一次 GC 必回收 | `WeakHashMap`、`ThreadLocal` 的 key |
| 虚引用 `PhantomReference` | 任何时刻都可能被回收，仅用于回收通知 | 管理堆外内存（如 `DirectByteBuffer`） |

> 类比的局限：把软引用理解成「仓库货架紧张时才清的便利店货架」是够用的，但它不像货架那样有明确容量线 —— 具体何时清，取决于 JVM 的内存压力与相关策略参数，不是一个固定阈值。

---

## 加分项：几个容易被忽略的延伸点

### TLAB：让分配快过释放

**TLAB（Thread Local Allocation Buffer，线程本地分配缓冲）**：JVM 在 Eden 里给每个线程划一小块私有区域，线程分配对象优先在自己的 TLAB 里完成，不用加锁。

**它和 GC 的关系**：TLAB 是「分配」这一侧的优化。GC 只管回收，但如果分配要靠全局锁，新对象还没生出来性能就先崩了。TLAB 在 HotSpot 中默认开启，可用 `-XX:TLABSize` 调整。

### 卡表：让跨代引用不必全堆扫描

分代之后冒出一个新问题：Minor GC 只扫新生代，可老年代完全可能引用新生代对象。为了不每次都扫全堆，HotSpot 用**卡表（Card Table）**做粗粒度记录：把老年代按 512 字节切成一张张「卡」，只要存在跨代引用就把对应卡标为 dirty，Minor GC 时只扫 dirty 的卡。

**它和 GC 的关系**：卡表是第三条分代假说（跨代引用是少数）的**工程实现**。没有它，分代的「只扫一小块」就无从谈起。

### 收集器一览（同级对比）

| 收集器 | 分代 / 区域 | 停顿目标 | 并发 | 适合场景 | 备注 |
|---|---|---|---|---|---|
| Serial / Serial Old | 分代 | 短但全停 | 否 | 单核、客户端、小堆 | 内存占用最省 |
| ParNew | 分代 | 短但全停 | 否 | 配合 CMS 使用 | 多线程版 Serial |
| Parallel Scavenge / Parallel Old | 分代 | 吞吐量优先 | 否 | 后台批处理 | 看重吞吐而非单次停顿 |
| CMS | 分代 | 低停顿 | 是 | 响应敏感的老服务 | JDK 9 废弃、JDK 14 移除 |
| G1 | Region | 可预测停顿 | 是 | 大堆、通用 | JDK 9 起成为默认 |
| ZGC | Region + 染色指针 | 亚毫秒到几毫秒 | 是 | 超大堆、超低延迟 | JDK 15 转正 |
| Shenandoah | Region | 低停顿 | 是 | 大堆、低延迟 | 定位与 ZGC 接近 |

选型经验（量级参考，不构成绝对结论，务必以实测为准）：堆小于 4G 且追求吞吐，Parallel 系够用；堆在 4G 到 16G 之间的通用服务，G1 是当下的默认答案；堆开到几十上百 G 且延迟敏感，再考虑 ZGC。

### 常用参数速查

| 参数 | 作用 |
|---|---|
| `-Xms` / `-Xmx` | 堆初始 / 最大大小，线上通常设为相等，避免动态扩缩引发额外停顿 |
| `-Xmn` | 新生代大小 |
| `-XX:SurvivorRatio` | Eden 与单个 Survivor 的比例，默认 8 |
| `-XX:MaxTenuringThreshold` | 晋升年龄阈值，默认 15 |
| `-XX:+UseG1GC` | 启用 G1 |
| `-XX:MaxGCPauseMillis` | G1 的期望最大停顿时间 |
| `-Xlog:gc*`（JDK 9+） | 打印 GC 日志，排障必备；JDK 8 用 `-XX:+PrintGCDetails` |

---

## 收尾：一句话答案模板

如果面试时间有限，用这段 30 秒回答打底：

> Java 用**可达性分析**判断垃圾，从 GC Roots 出发，走不到的就回收 —— 不用引用计数法是因为它扛不住循环引用。
>
> 为了性能，堆被**分成新生代和老年代**：新生代对象朝生夕灭，用**复制算法**，代价小；老年代对象活得久，用**标记-整理**。
>
> 现代收集器（CMS、G1、ZGC）靠**并发标记**把停顿压下去，并发带来的漏标问题用**三色标记 + 读写屏障**解决 —— CMS 用增量更新，G1 用原始快照。
>
> 线上排查先看 GC 日志：**Full GC 后老年代降不下去就是泄漏，降得下去就是分配太快。**

### 三条核心结论

1. **GC 的唯一标准是可达性**，不是「你觉得它没用了」。
2. **几乎所有设计都在为 STW 让路**，收集器的演进史就是一部缩短停顿的历史。
3. **泄漏排查就是找那条不该存在的强引用链**。

### 延伸学习顺序

1. 先把运行时数据区（栈、堆、方法区）搞清楚，它是所有 GC 概念的地基。
2. 再动手跑一遍 GC 日志：把 `-Xms` / `-Xmx` 调小，用 `-Xlog:gc*` 观察 Minor GC 与 Full GC 的触发条件。
3. 然后读三色标记与读写屏障，理解并发收集器的理论边界。
4. 最后按「分代 → 分区 → 染色指针」的顺序过一遍收集器演进，每一步都能说出「它替谁解决了什么」。

这是一道能同时考出三件事的题：你知不知道 Java 的内存是自动管理的、你能不能说清「自动」背后的代价、以及线上真出问题时你能不能定位。

【JVM】说说 JVM 垃圾回收——这题到底在考什么

编程语言

后端

职业发展

JVM垃圾回收面试高频题，考察内存自动管理、GC机制及线上排障能力。核心包括可达性分析判断垃圾、分代收集理论（新生代复制、老年代标记整理）、三色标记与读写屏障解决并发漏标问题。排查思路：先看GC日志区分内存泄漏或分配过快，再定位强引用链。掌握GCRoots、引用类型、收集器选型与调优参数是关键。

代码解释

虚拟机

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【JVM】说说 JVM 垃圾回收——这题到底在考什么-腾讯云开发者社区-腾讯云

【JVM】说说 JVM 垃圾回收——这题到底在考什么

【JVM】说说 JVM 垃圾回收——这题到底在考什么

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐