当前位置：首页 > news >正文

堆的分代与垃圾回收

news 2026/6/30 23:19:47

一句话

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 没有分页，一次查太多数据 - 定时任务频率太高 - 内存泄漏（对象只增不减）