一句话
JVM 根据"大部分对象朝生夕死"的规律，把堆分成了新生代和老年代，不同代用不同的回收策略。理解对象在堆里的流转过程，就掌握了 GC 的核心。
为什么堆要分代？
因为大部分对象活不久：
你的项目里： 查一次列表 → new 一堆 User 对象 → 用完没人引用了 下一次请求 → 又 new 一堆 → 又没人引用了 → 90% 的对象活不过几毫秒如果不分代，每次回收都要扫描整个堆，效率极低。分代后：
- 新生代：空间小，回收快（Minor GC，毫秒级）
- 老年代：放长命对象，回收频率低（Full GC，秒级）
堆的分区结构
堆（Heap） │ ├── 新生代（Young Generation） │ ├── Eden（E 甸园） ← 占 80% │ └── Survivor 区 │ ├── S0（From） ← 占 10% │ └── S1（To） ← 占 10% │ └── 比例：Eden : S0 : S1 = 8 : 1 : 1 │ └── 老年代（Old Generation）默认新生代和老年代比例约 1 : 2（可调）。
对象完整流转过程
new User() → 放进 Eden 区 │ ├── Eden 快满了 → Minor GC │ │ │ ├── 没人引用的对象 → 回收 │ └── 还有人引用的对象 → 移到 S0（年龄=1） │ ├── Eden 再次满了 → Minor GC │ │ │ ├── Eden 存活对象 + S0 存活对象 → 移到 S1（年龄+1） │ └── S0 清空 │ ├── 反复如此：Eden + 正在使用的 Survivor → 另一个 Survivor │ S0 和 S1 始终保持一个为空 │ ├── 对象年龄达到阈值（默认 15）→ 升到老年代 │ ├── 或者：Survivor 区装不下了 → 动态年龄判定 → 年龄大的提前升老年代 │ └── 老年代满了 → Full GC │ ├── 扫描整个堆（新生代 + 老年代 + 元空间） └── STW（Stop The World）：所有线程暂停Minor GC vs Full GC
| 对比项 | Minor GC（Young GC） | Full GC |
|---|---|---|
| 回收范围 | 新生代（Eden + Survivor） | 整个堆 + 元空间 |
| 触发条件 | Eden 区满了 | 老年代满了 / 元空间满了 / 主动调用 System.gc() |
| STW 时长 | 几毫秒（用户基本无感知） | 几秒甚至几十秒（系统卡顿） |
| 频率 | 频繁 | 少（但每次都很重） |
注意：Minor GC 也会 **STW（Stop The World）**——暂停所有线程。但因为只扫新生代，范围小，所以很快。
Full GC 是 JVM 调优的主要目标——要尽量降低 Full GC 的频率和时长。
GC Roots 和可达性分析
JVM 判断对象"该不该回收"，用的是可达性分析：
从 GC Roots（肯定活着的起点）出发 能走到的对象 → 活着 ❌ 不回收 走不到的对象 → 不可达 → 回收 ✅ GC Roots 包括： ├── 栈帧中的局部变量引用（方法里正在用的对象） ├── 静态变量引用（static 修饰的） └── 活跃线程打个比方：
一栋楼（堆）里有 1000 个房间 你不需要查每个房间有没有人 你只需要从 3 个值班室（GC Roots）出发： 前台有人的 → 她旁边的房间也有人 紧急指示灯亮着 → 它的线路都有人维护 监控室有人 → 监控覆盖的区域都是活的 能走到的房间 → 有人 → 不回收 走不到的房间 → 没人 → 回收面试问答
Full GC 频繁怎么排查？
① 看监控：老年代占用率持续上升 ② 加 JVM 参数：-XX:+HeapDumpOnOutOfMemoryError ③ OOM 时拿到 hprof 堆转储文件 ④ MAT 分析：看占内存最大的对象 ⑤ 定位代码：顺着线程栈找到问题 SQL/代码 常见原因： - SQL 没有分页，一次查太多数据 - 定时任务频率太高 - 内存泄漏（对象只增不减）一个对象一定会熬到 15 岁才进老年代吗？
不一定。还有动态年龄判定：如果 Survivor 区装不下了，会把年龄最大的那批对象提前升到老年代，不一定要等到 15 岁。
参考来源
- 《深入理解 Java 虚拟机》第 3 章
- JDK8 G1 GC 文档