JVM 堆内存：年轻代三区与老年代的生命周期

面试官很喜欢用这个问题开场，因为答案直接决定了他对你 GC 理解深度的判断：

如果你只回答"为了 GC 效率"，面试官一定会继续追问：凭什么年轻代的 GC 就可以更快？依据是什么统计规律？答不上来，话题就到此为止了。所以我们先建立正确的认知框架，再回答问题。

先搭框架：GC 的三个根本问题

整个 JVM 垃圾回收的知识体系，都可以挂在三个根本问题上。先记住这个框架，后面所有卷三的知识点都不会乱：

"为什么分代"本质上是回答"何时回收 + 怎么回收"的设计动机：把堆按对象存活时间切成不同的区域，让占绝大多数的"短命对象"能被一套又快又专的机制快速处理掉。

分代依赖的两个统计假设

HotSpot 的分代设计完全建立在这两个经验假设之上——面试时能说出名字和区别，就是加分项：

• 弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是"朝生夕灭"的——刚分配出来，很快就再也没有引用指向它们了。
• 强分代假说（Strong Generational Hypothesis）：熬过了前几轮 GC 的对象，未来继续长期存活的概率会更高。

第一个假设是年轻代存在的理由：统计上绝大多数对象活不过第一轮 GC，那么回收这"绝大多数"就不该每次都扫描整个堆，而应该有一块专用区域、一个高频快速的收集器（Minor GC）专门处理。第二个假设是老年代存在的理由：熬过年轻代的对象被证明"活得久"，回收它们可以慢一点、频率低一点——因为它们下轮还活着的概率高，如果每次都急着回收（比如频繁整理），反而浪费 CPU。

一个帮助内化的类比：医院分急诊科和住院部。急诊科（年轻代）处理"来得急、走得也快"的病例，流程快、频次高、吞吐量必须大；住院部（老年代）处理长期病人，动作慢、频次低。如果医院只设一个大厅让所有病人走同一条流程，那才是灾难。分代就是 JVM 的"分诊制度"。

这篇文章把 JVM 堆的分代结构拆成 8 站：全景布局 → 分配规则 → 晋升规则 → Minor GC 拆解 → Full/Mixed GC → 调优参数 → 面试模板。读的时候带着三个问题：

• Eden 和两个 Survivor 区默认什么比例？对象"Eden 都装不下"时去哪？
• 除了"年龄到 15"，对象进老年代还有哪几条路？"分配担保"的完整判定逻辑是什么？
• 到了 G1 时代，"年轻代 / 老年代"还是物理分区吗？

先画地图。HotSpot 的堆（Heap）分为两大区域：年轻代（Young Generation）和老年代（Old Generation）；年轻代内部再细分为三个区：Eden 和两个 Survivor 区（一个当 From，一个当 To，角色互换使用）。

三个必须记住的默认值

分代是物理分区吗？——G1 时代的真相

在 Serial、Parallel、CMS 这些"经典"收集器里，年轻代和老年代确实是堆里两块连续的物理内存。但到了 G1，情况变了：

这是 Oracle 官方文档的原话："the eden, survivor, and old generations are logical sets of these regions and are not contiguous"。所以面试时说"堆分成年轻代老年代"没错，但加分回答是：分代是一种分配与回收策略，不一定要物理连续——G1 用 Region 化打破了物理边界，但"对象从年轻态走向老年态"的生命周期概念依然保留（Region 也有年龄）。

对象创建的第一步是内存分配。JVM 决定"把对象放在哪"的规则，比你想象的多——不只是"新对象进 Eden"这么简单。

规则一：新对象优先进 Eden

绝大多数对象走这条路：在 Eden 区分配内存（实际发生在每个线程的 TLAB——线程本地分配缓存里，TLAB 的机制在「对象创建全过程」一篇里拆，这里只需知道：TLAB 是 Eden 里划给每个线程的私有小块，避免多线程抢同一个分配指针加锁）。Eden 满了，触发一次 Minor GC。

规则二：Eden 装不下，直接去老年代

如果一个对象比 Eden 的剩余空闲空间还大（注意：不是比 Eden 总空间大，JVM 会先看 Eden 当前剩多少），就没有资格在年轻代"历练"了——JVM 直接在老年代找一块连续空间分配。如果老年代也放不下，就先触发一次 Full GC 腾空间，再试。

规则三：大对象直通老年代（PretenureSizeThreshold）

有些对象天生就是大块头（典型如大数组 byte[10 * 1024 * 1024]、大视频字节流）。如果让它先在 Eden 出生、再在 Survivor 之间反复复制，复制成本可能比直接分配还高。于是 HotSpot 提供了直通机制：

// 分配对象 size 时：
if (size <= eden_free)          // ① Eden 剩得下 → 正常在 Eden 分配
    allocate_in_eden(size);
else if (size <= old_free)     // ② Eden 剩不下，老年代放得下 → 直接老年代
    allocate_in_old(size);
else {                          // ③ 两边都放不下 → 先 Full GC 再试，仍失败则 OOM
    full_gc();
    retry_or_oom(size);
}

对于 Serial / ParNew 收集器，还可以显式指定：-XX:PretenureSizeThreshold——超过该大小的对象不走规则二的"看剩余空间"逻辑，直接进老年代。它存在的目的正是省掉大对象在年轻代的复制开销。

规则四：大数组的"灰色地带"

一个容易忽略的细节：数组在 HotSpot 里有特殊待遇。即使没有设置 PretenureSizeThreshold，一个总长度很大的数组（比如 new long[100000]，约 800KB）如果在 Eden 剩余空间里放不下，也会直接落到老年代——因为数组是"潜在大对象"里最常见的一种，HotSpot 对它的分配策略更保守。写批量处理代码时，如果一次性 new 超大数组，老年代会突然鼓起来，GC 日志里能看到对应的 allocation——这不是 bug，是分配规则在起作用。

对象在年轻代的"履历"由一个数字记录：年龄（age）。每熬过一次 Minor GC，年龄 +1；年龄存的是字节（byte），所以理论上限是 255。HotSpot 默认认为：年龄达到 15 的对象，晋升老年代。

通道二：动态年龄判定（Dynamic Aging）

年龄只是"名义"条件。HotSpot（Parallel Scavenge 实现）还有一个更聪明的自适应规则：

举个例子：Survivor 只剩 10MB，而年龄为 3 的对象加起来有 8MB——如果还按年龄规则让它们继续在 S0/S1 之间复制，这次 Minor GC 大概率装不下。JVM 就"批量升级"：把年龄 ≥ 3 的对象全部送进老年代。这就是 GC 日志里常说的 average promotion size（平均晋升大小）统计的由来——JVM 会持续跟踪每轮 Minor GC 实际晋升了多大一块，供后续决策参考。

通道三：分配担保（Allocation Failure / Promotion Guarantee）

这是最容易被忽略、也最能体现深度的一条规则。场景是：Eden 满了，Minor GC 即将触发。此时 JVM 要回答一个问题：这次 GC 之后，存活对象（Eden + From 里活着的）总共多大？To 区装得下吗？装不下的部分得有去处——这个"去处保证"就叫分配担保。

ParNew 收集器的完整判定逻辑是两步：

// 设：young_live = Eden + From 中存活对象总大小
//     to_space  = 另一个 Survivor 区的大小
//     old_free  = 老年代当前最大连续空闲空间

if (old_free > young_live) {
    // ① 老年代的连续空闲空间 比 全部存活对象还大
    //    → 担保成立：放心做 Minor GC，To 装不下的部分直接放老年代
    proceed_minor_gc();
} else {
    // ② 担保不成立，还要看历史：比较 old_free 与「平均晋升大小」
    if (old_free > avg_promotion_size) {
        //    历史每轮晋升量不大，这次大概率也放得下 → 冒险做 Minor GC
        //    （风险：这次偏偏晋升多了 → Promotion Failed → 还是 Full GC）
        proceed_minor_gc();
    } else {
        // ③ 连历史平均都放不下 → 保险起见，先做一次 Full GC 腾老年代
        //    然后再重试 Minor GC
        full_gc();
        retry_minor_gc();
    }
}

理解这段逻辑，三个常见现象就有解释了：

• "为什么 Minor GC 之前会先来一次 Full GC？"——分配担保失败，JVM 主动先清老年代（GC 日志里能看到 Full GC (Ergonomics) 或 Promotion Failed 的 cause）。
• "为什么老年代占用率还没满，Full GC 就发生了？"——上面第 ③ 种情况：不是老年代"满了"，而是"预判装不下即将晋升的对象"。
• "为什么调大年轻代后 Full GC 反而多了？"——年轻代越大，单次 Minor GC 的存活总量越大，担保判定越容易失败（第 ① 步 old_free > young_live 更难成立）。

四条晋升路径汇总

前面讲了"对象去哪"，这一站拆开引擎盖：Eden 满了之后，JVM 内部一步步发生了什么。以 ParNew（经典的并行复制收集器）为例，一次 Minor GC 分五步：

1. STW（Stop-The-World）：暂停所有 Java 线程。原因：标记和复制期间，引用关系不能变，否则会出现"正在遍历的对象被新建/删除"的混乱。这是所有 Minor GC 无法避免的代价。
2. 根扫描：从 GC Roots 出发，找出年轻代里的存活对象。注意这里有一个关键优化——不需要完整扫描老年代。老年代对象可能引用了年轻代对象（比如一个长生命周期容器里存了短命对象），但 HotSpot 用卡表（Card Table）+ 写屏障（Write Barrier）机制，只在"老年代指向年轻代的引用发生过写操作"的内存卡（每 512 字节一张卡）上打脏标记，根扫描时只处理脏卡。G1 里对应的结构是 RSet（Remembered Set）。这正是"为什么 Minor GC 只扫年轻代却不会漏掉老年代的引用"的答案——写屏障是并发 GC 的基石，「对象存活判定」一篇会展开讲。
3. 标记存活对象：用三色标记法（白色=不可达、灰色=自身可达但子引用未处理完、黑色=处理完）从根出发遍历。年轻代用 STW 标记，不存在并发修改问题，所以不需要 SATB 之类的补偿机制。
4. 复制存活对象：把存活对象按内存序重新排布到 To 区（复制过程中顺便完成内存整理——对象紧凑排列，无碎片）；同时 age+1，满足晋升条件的对象改放到老年代（走上一节的分配担保逻辑）。
5. 清空与角色互换：Eden 和 From 区的"指针"一移即空（零成本，不需要逐个释放），S0 和 S1 互换 From/To 身份。下一轮 Minor GC 的存活对象会复制到另一个区。

Minor GC 的典型耗时在 10~100ms 量级（取决于存活对象大小和根扫描范围），频率取决于 Eden 大小和对象分配速度——这两者就是后面调优要拧的两个旋钮。

年轻代的回收快而频繁，老年代的回收则慢而危险。先把术语理清楚——"Major GC" 和 "Full GC" 在很多材料里混用，但严谨的说法是：

Full GC 的六大触发场景

为什么 Full GC 这么可怕？

三个原因叠加：① 全程 STW，且要扫描所有 GC Roots（包括完整老年代根）；② 回收整个堆，耗时与堆大小成正比（几十 GB 的堆，一次 STW 可达秒级）；③ Full GC 之后如果回收不了多少空间（说明是泄漏或堆太小），很快又会触发下一次——形成"GC 风暴"，CPU 几乎全耗在 GC 上，业务线程饿死。

G1 的 Mixed GC：不做 Full GC 的理想

G1 的设计目标就是"让 Full GC 尽量不发生"。它的做法是把老年代回收化整为零：

1. 并发标记周期（Concurrent Marking Cycle）：老年代占用率到达 -XX:InitiatingHeapOccupancyPercent（默认 45%，JDK 9+ 可自适应）时启动。分四阶段：初始标记（STW，挂在 Young GC 尾部，只标根对象）→ 并发标记（与应用并发，从根出发标记全部老年代对象，用 SATB 快照保证一致性）→ 最终标记（STW，处理并发期间的引用变更）→ 筛选清理（按 Region 垃圾比例排序）。
2. Mixed GC：并发标记结束后，接下来的若干次 Young GC 变成 Mixed GC——每次除了回收全部年轻代，再回收一批"垃圾占比最高"的老年代 Region。
3. 回收多少由暂停时间目标决定：-XX:MaxGCPauseMillis（默认 200ms）是 G1 的"软实时"目标。G1 内部维护每个 Region 的回收效率预测（可回收字节数 ÷ 预测耗时），每次 Mixed GC 在暂停预算内按性价比挑 Region。相关旋钮：-XX:G1MixedGCCountTarget（默认 8，分 8 次 Mixed GC 消化完标记的老年代垃圾）、-XX:G1HeapWastePercent（默认 5%，可回收垃圾低于堆的 5% 就停止 Mixed GC）。

理解了分代原理，调优就是拧参数。先列出控制堆分代结构的核心参数：

参数之间的关系与冲突（面试爱问）

• -Xmn 与 -XX:NewRatio 二选一：同时指定时 -Xmn 优先生效，NewRatio 被忽略。写启动脚本时别两个都写，否则参数"看起来生效了其实没生效"。
• -Xms = -Xmx 是铁律：堆动态扩容/缩容本身需要 GC 且缩容要整理内存，生产环境固定堆大小，把"扩堆 STW"这个变量从线上环境里彻底移除。
• SurvivorRatio 调小的连锁反应：Survivor 变大 → 存活对象能多待几轮 → 晋升变慢，老年代压力减小；但 Eden 变小 → Minor GC 频率上升。两个方向互相制约，没有免费午餐。

三种典型场景的启动模板

# 固定堆 = 容器内存的一半，给堆外（Metaspace/Direct/线程栈）留余量
-Xms4g -Xmx4g
# G1 是 JDK 9+ 默认收集器，显式写出便于日志识别
-XX:+UseG1GC -XX:MaxGCPauseMillis=100
# 显式 GC（Netty 释放 DirectMemory 依赖）走并发路径
-XX:+ExplicitGCInvokesConcurrent
# GC 日志 + OOM 自动转储（排障三件套，见「OOM 排查实战」）
-Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=50m
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/

# 吞吐优先：Parallel GC（JDK 8 的默认服务端收集器）
-Xms8g -Xmx8g
-XX:+UseParallelGC
# 大批量短命对象：年轻代给足（约占堆一半）
-XX:NewRatio=1
# 关注吞吐而非停顿：GC 时间占比上限
-XX:GCTimeRatio=19   # GC 时间 ≤ 总时间的 1/20

# ZGC：停顿与堆大小无关（亚毫秒级），适合大堆 + 严格延迟 SLA
-Xms16g -Xmx16g
-XX:+UseZGC
-XX:SoftMaxHeapSize=12g  # 软上限：尽量把堆压在这个值以下，减少 GC 频率

调优方法论：五步走，拒绝拍脑袋

容器化部署的特别注意

JDK 8u191+ / JDK 10+ 能正确识别 cgroup 内存限制（Container Support），此时不写 -Xmx，JVM 默认用容器限制的 25%（-XX:MaxRAMPercentage=25.0）。生产建议显式写出：容器 8G 给 JVM 4G 堆（-XX:MaxRAMPercentage=50.0），剩下的留给 Metaspace、Direct Memory、线程栈（每个线程 -Xss 默认 1MB 堆外内存）和 OS 缓存。JDK 8 老版本在容器里会看到宿主机物理内存——这是"容器里 JVM 把宿主机内存吃满"的经典事故根源。

知识地图

面试回答模板

高频追问速答