很多人第一次接触 JVM 内存模型时，都会有个很自然的疑问：为什么要把堆拆成新生代、老年代，又把新生代切成 Eden 区和两块 Survivor 区？直接用一大块连续内存做统一的标记清理，不是更省事吗？这个问题问得特别好，因为它正好戳中了分代收集理论的核心价值。这套理论不是某个工程师拍拍脑袋想出来的，而是 JVM 的设计者统计了大量真实应用的运行数据后，提炼出的一套“空间换时间”的内存管理策略。本文会把分代收集的假说基础、内存区域分工、回收机制联动、收集器选型和参数调整，以及线上真实问题的排查思路讲透，适合正在啃 JVM 的同学、被 GC 日志折磨的开发，以及靠调参续命的运维和架构师参考。
1. 分代收集的由来：两个假说决定了堆内存的划分
1.1 先看对象寿命分布规律：弱分代假说与强分代假说
分代收集理论的立论基础，是两条看起来简单但意义深远的统计规律：弱分代假说和强分代假说。弱分代假说的意思是，绝大多数对象的生命周期都非常短，创建出来之后很快就不再被引用了。强分代假说的意思是，越能熬过多次垃圾回收的对象，就越有可能继续存活很长时间。
这两条假说不是孤立的，它们共同描绘了 Java 程序运行时对象寿命分布的基本画像。我做过不少线上系统的 GC 日志分析，绝大多数业务系统里，新生代中 90% 以上的对象在一次 Minor GC 发生时就已经变成了垃圾。真正能一路晋级到老年代的对象，数量少得可怜，但一旦进入老年代，就会在很长一段时间内持续被引用。
为什么这两条假说能指导内存划分？关键在于：既然对象在年轻时死亡概率最高，那就把新对象集中放在一个相对独立的小空间里，用最快的算法高频回收；既然老对象存活概率高，就把它们单独放到老年代，用更稳妥但耗时更长的算法低频处理。这样一来，GC 的大部分工作都集中在一个很小的区域，回收效率极高，而老年代因为对象存活率本就很高，收集频次自然下降。
1.2 如果不进行分代：全堆扫描的高昂代价
很多新手会想：GC 不就是把没用的对象标记出来再清掉吗，直接全堆扫描一遍不就行了？这就必须提到 STW（Stop The World），也就是用户线程停顿。标记阶段需要精确扫描整个堆上的对象引用关系，JVM 为了不在标记过程中误删还在被引用的对象，通常得暂停所有业务线程。
堆越大、对象越多，扫描耗时越长。对一个 2GB 的小堆，全堆扫描可能只需要几十毫秒，体感尚可；但对 32GB 以上的堆，一次全堆标记可能轻松突破秒级，线上业务根本承受不起。分代收集的精妙之处，就在于把“全堆扫描”变成了“小范围高频扫描 + 大范围低频扫描”的组合。
我常打一个生活化的比方：小区里的垃圾桶每天清运，废纸箱、果皮这些“朝生夕死”的垃圾很快就会被拉走；而图书馆的档案室则隔一段时间才整理一次，馆藏旧书本来就不容易作废，没必要每天都把它们搬出来晒太阳。JVM 的分代模型本质上就是在模仿这种管理逻辑。
1.3 三个区域的任务分工：新生代、老年代、以及“元空间”的误区澄清
在常规的 HotSpot JVM 里，堆被划分为新生代（Young Generation）和老年代（Old Generation）。新生代内部又分为 Eden 区和两块 Survivor 区。Eden 区是对象最初被创建的地方，大量的短命对象在这里出生并快速消亡。Survivor 区是新生代回收时的“中间收容所”，存放那些扛过了一两次回收但还没晋升到老年代的对象。老年代则住着那些“见过风浪”的长寿对象，也接收一些直接分配进来的大对象。
这里必须澄清一个高频误区：元空间（Metaspace）并不属于堆，它是 JDK 8 之后用来存放类元数据的区域，分配在本地内存中。很多调优文章会把元空间和分代收集混在一起说，实际上分代收集里的老年代并不包含元空间。之所以要单独强调，是因为我之前排查一个很诡异的 OOM 时，同事一直盯着老年代占用调参数，结果真正的问题是元空间不断膨胀，方向完全走偏了。
2. 新生代内部结构与连环回收机制：Eden 区和 Survivor 区的循环赛
2.1 为什么要搞两块 Survivor 区，而不是一块
很多人初次接触新生代布局时会问：Eden 区放新对象，回收以后留几个有用的，直接搬到老年代不就行了？为什么要 Survivor 区，而且还搞两块？直接搬老年代确实能解决问题，但有个重大副作用：刚晋升到老年代的对象很快又变成垃圾，会把老年代塞得越来越满，而老年代的回收算法是标记-清除-整理，成本远高于新生代的复制算法，结果就是频繁触发昂贵的 Full GC。
有了两块 Survivor 区之后，新生代回收采用“复制”逻辑：分配对象主要使用 Eden 区和其中一块 Survivor 区（通常叫 S0）。GC 发生时，把 Eden 区与 S0 区中存活的对象一次性搬到另一块空闲的 Survivor 区（S1），然后清空 Eden 区和 S0 区。下一次 GC 再把方向反过来，Eden 区与 S1 区中的存活对象搬到 S0 区。两块 Survivor 区轮流干活，保证任意时刻都有一块完全空闲的区域，复制的目标空间总是干净的，不会产生内存碎片。
需要重点提醒的是，Survivor 区默认其实很小。HotSpot 里 Eden 和两块 Survivor 的默认比例是 8:1:1，也就是说新生代里只有一成空间分给 Survivor。这个比例的前提是绝大多数对象在 Minor GC 时会死，且存活率低于 10%。如果你在生产环境把 Survivor 比例调成 5:3:2，看起来是“给 Survivor 更多空间”，实际上反而削弱了 Eden 区缓存新对象的能力，可能导致 Minor GC 更频繁，属于典型的“好心办坏事”。
2.2 对象晋升流程与动态年龄判断
对象从新生代进入老年代通常要满足两个条件：一是年龄达到阈值，默认是 15 岁，可通过-XX:MaxTenuringThreshold调整；二是 Survivor 区空间不足，触发提前晋升。对象年龄的计算方式是，每经历一次 Minor GC 且存活下来，年龄就加一。
JVM 里还有一个容易被忽略的动态年龄判定机制：如果一批同龄对象加起来的总占用空间超过了 Survivor 区容量的一半，这些对象就不一定非要等到 15 岁，可以直接晋升到老年代。这个设计的本质是预测空间成长性。如果一组对象虽然年龄不大，但总体积惊人，继续留在 Survivor 里只会导致后续多次复制搬家的成本越来越大，还不如尽早送到老年代，让新生代回收更轻快。
我在一个高并发网关项目里踩过这个坑。当时的现象是 Minor GC 非常频繁，GC 日志显示大量对象刚晋升到老年代后马上又变成了垃圾。后来把最大存活年龄从 15 调低到 6，让这类本就不长寿的对象更早进入老年代，配合老年代合适的回收频率，整体停顿反而明显下降。调参这件事，真的不能光看默认值抄作业。
2.3 分配担保机制：老年代其实也在悄悄兜底
当新生代进行 Minor GC 时，如果 Survivor 区放不下存活对象，就需要老年代上前“接盘”，这就是分配担保。JVM 会先做一个预测判断：历史上新生代晋升到老年代的对象总大小的平均值，是否超过老年代当前的连续可用空间。如果超过，就会提前触发一次 Full GC，而不是等老年代彻底满了再动手。
在这套机制里，老年代看起来只是“躺平”接收老对象的区域，但它实际上承担了新生代回收失败的兜底角色。这也是老年代不能调太小的根本原因：如果老年代空间紧张，Minor GC 触发 Full GC 的概率就会增大，停顿时间会远超平时的小回收。分代模型中，新生代和老年代从来不是两个独立的孤岛，它们通过晋升和担保机制紧密联动，调任何一边都要同步评估另一边。
3. 分代背景下的收集器选型与实测调参思路：从 Serial 到 ZGC 的真实工作场景
3.1 分代模型如何影响收集器设计
理解了分代结构，才能真正看懂收集器之间的差异化设计。Serial、Parallel、CMS、G1 这些收集器在不同年龄段采取了不同策略。新生代几乎都倾向于用标记-复制算法，因为复制可以避免碎片化，又不需要像标记-清除那样整段扫描。老年代一般用标记-清除或标记-整理算法，追求目标要么是降低停顿（CMS 的并发清除），要么是压缩碎片（Parallel Old 的整理）。
G1 出现之后，堆被拆成了若干大小相同的 Region，物理上不再是一整块连续的年轻代和老年代，但它逻辑上依然保持了分代概念：Eden、Survivor、Old 分别由不同的 Region 集合构成。ZGC 更是把停顿时间压到了极低水平，用染色指针和读屏障配合并发整理，但它也依旧保留分代思路，后来的分代 ZGC 让这套模型走得更远。所以分代收集理论并没有过时，而是被现代收集器以更细的粒度继续内化和改造。
这里多说一句“为什么选 G1 而不是 CMS”。CMS 是老牌的低延迟收集器，但它的老年代采用“并发标记-并发清除”，天生没法处理碎片问题，一旦碎片化严重，就要 Serial Old 做兜底，反而进入长停顿。G1 通过 Region 复制和可预测停顿时间，解决了很多 CMS 在生产环境中的痛点，这也是它能成为默认收集器的直接原因。
3.2 堆大小与区域比例设定：用一段示例配置理解参数
做分代调优时，第一步永远是确认总堆大小和新生代大小，而不是盲目换收集器。我推荐两步走：先根据压测峰值内存确定堆大小，再按应用特征调整新生代占比。如果业务接口疯狂创建短生命周期对象，新生代没道理设得太小；如果系统里缓存特别多，长生命周期对象占主流，老年代就要更大一些。
以一个常见的 4GB 堆举例，可以这样配：
-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200这里-Xms和-Xmx保持一致，是为了避免运行期堆扩容导致性能抖动。G1 模式下不太需要手动设置新生代绝对大小，它会根据暂停时间目标自我调节。如果用的是 ParallelGC，-XX:NewRatio=2表示新生代和老年代各占一半，NewRatio=3时老年代占 2/3、新生代占 1/3。
调参绝对要做前后对照实验。我之前遇到一个服务用默认参数，Minor GC 平均 20ms，但每两小时会有一次超过 1 秒的 Full GC。把堆从 4GB 升到 8GB 后，Minor GC 频率下降了一半，可 Full GC 的停顿时间反而拉长了，原因是老年代变大后回收耗时同步增加。所以堆并不是越大越好，压缩停顿时长必须结合收集器参数和对象分配速率整体分析。
3.3 观察 GC 日志识别分代运转是否健康
分代调优说白了就是对着日志做诊断。用-verbose:gc可以输出基本回收信息，想更细致可以用-XX:+PrintGCDetails，JDK 9 以上则推荐用-Xlog:gc*打印结构化日志。日志里重点看清三个数据：Minor GC 前新生代占用情况、晋升到老年代的对象总量、Full GC 前后老年代的实际降幅。
我习惯用三步法做日志分析：
- 看 Full GC 的触发原因和频率。如果老年代几乎没满却频繁 Full GC，优先怀疑晋升阈值设太低，或者 Survivor 空间过小，导致正常对象被提前送进老年代。
- 看 Minor GC 后 Eden 区能否迅速回到很低的占用。如果一直处于高位，说明对象分配速率太高，或者 Eden 本身设得太大，需要从业务侧减少瞬时对象创建。
- 养成“每次调参之后重新抓日志”的习惯。参数调完不看新日志，等于白调。
下面这段模拟的日志格式可以帮你建立直观感觉：
[GC (Allocation Failure) [PSYoungGen: 2048K->256K(6144K)] 5120K->4096K(8192K), 0.0123s] [Full GC (Ergonomics) [PSYoungGen: 0K->0K(6144K)] [ParOldGen: 5120K->4812K(10240K)] 5120K->4812K(12288K), 0.5834s]第一次是新生代回收，耗时只有毫秒级；第二次 Full GC 时老年代只回收了 300KB 左右，说明对象“死不透”，存活性太高。这种日志背后通常藏着长期被引用的缓存，或者静态集合持有对象的问题。
4. 分代调优中的典型事故与排查实录：一次 Full GC 异常与对象过早晋升的复盘
4.1 事故现场：Full GC 频繁、老年代占用率不高，问题到底在哪
我经常遇到这种监控场景：老年代占用率只有 30%，但 Full GC 一小时却触发好几次。按理说老年代没满，不应该频繁 Full GC。真正的原因往往不是总量问题，而是老年代连续可用空间不够，触发了分配担保失败。这种“老年代占用不高但连续空间不足”的情况，通常来自老年代里散落着大量无法及时清除的大对象，或者说这些大对象的存活时间与业务处理节奏不匹配。
从实操经验看，遇到这种问题先别急着把老年代调大。先用jmap -histo查看堆中对象分布，再用jstat -gcutil观察 Eden、Survivor、Old 各区占比变化。如果应用里有很多批量创建的临时大数组，这些大对象不会在新生代分配，而是直接进入老年代，老年代就会逐渐碎片化。对应的解法很多在业务层：把大对象改成池化复用，减少一次性创建大量对象的操作，必要时再配合堆参数调整。
4.2 常见问题速查表：成年项目中的典型症状与调整手段
我把线上常见的分代相关表现整理成了一张速查表，方便你直接对照定位：
| 症状 | 根因线索 | 常用排查手段 | 推荐调整方向 |
|---|---|---|---|
| Minor GC 极频繁但回收量很小 | Eden 区过大或对象创建速率过高 | 看对象分配速率、压测业务峰值 | 缩小新生代，优化业务对象复用 |
| Full GC 频繁但老年代占用不高 | 老年代碎片化或分配担保失败 | jmap -histo，查看 GC 日志担保上下文 | 调大老年代连续空间，减少大对象直接入老年代 |
| 老年代长期高位占用 | 缓存未清理、静态集合长期持有引用 | 用 MAT 分析 dump 文件 | 业务侧释放引用，必要时调高老年代阈值 |
| 对象大量在晋升后立刻死亡 | Survivor 留不住，提前晋升 | 打印 GC 前后年龄分布 | 调大 Survivor 比例或提高晋升年龄阈值 |
这张表不能解决所有问题，但它能帮你把抽象的 GC 问题快速归类。判断根因最忌讳的是一上来就套参数，缺少对应用对象本身的观察。
4.3 基于常见实践的补充经验：内存分配速率 vs 回收效率的整体观念
最后再强调一个观点：分代收集只是手段，而不是目的。很多系统卡顿的根源不是 GC 算法本身，而是内存分配速率太高。试想一下，一个垃圾桶再怎么高效，旁边有一台每秒往外丢一百公斤废物的机器，也撑不住。所以在调整分代结构和收集器参数的同时，必须同步关注业务层创建对象的方式。
字符串拼接改用 StringBuilder，循环体内避免反复实例化对象，批量查询时控制返回列表的体积，这些工作看起来不性感，却往往比 JVM 参数更立竿见影。我遇到过一个极端案例，业务层一个循环里反复创建 BigDecimal 对象，导致新生代分配速率飙升，最后靠调参压停顿只优化了 20% 的效果，改成复用对象后 GC 压力直接降到了可忽略的水平。
我个人实际操作中的体会是，JVM 参数永远不要照搬网上的“万能配置”。每个应用的对象生命周期曲线都不一样，和项目规模、业务形态、压测模型都高度相关。用数据说话，每次改动都记录日志和监控，用一组完整的 GC 采样档案来判断方向是否有效。分代收集理论看起来是理论，实际它就是我排查性能问题时最踏实的一张地图——先搞清楚对象到底都活多久、死在哪个区，再谈优化和调参。
