Java堆内存默认新生代与老年代比例为1:2，新生代内Eden:Survivor0:Survivor1=8:1:1；该划分基于对象生命周期差异，可通过-XX:NewRatio、-Xmn或-XX:SurvivorRatio等参数调优，并用jstat或GC日志验证。
Java 堆内存中新生代（Young Generation）和老年代（Old Generation）的划分比例，本质是 JVM 对对象生命周期差异的工程化应对：大多数对象朝生暮死，少数长期存活；通过分代管理，能显著提升垃圾回收效率。
默认比例：1:2（新生代 : 老年代）
HotSpot JVM 默认堆内存中，新生代与老年代的容量比为 1:2。也就是说，若堆总大小为 3GB（-Xmx3g），则新生代约 1GB，老年代约 2GB。这个比例可通过参数显式调整：
- -XX:NewRatio=n：设置老年代与新生代的容量比。例如 -XX:NewRatio=2 表示老年代 : 新生代 = 2:1 → 新生代占堆的 1/3，老年代占 2/3（即默认值）
- -Xmn 或 -XX:NewSize/-XX:MaxNewSize：直接指定新生代初始/最大大小，更直观。如 -Xmn512m 表示新生代固定为 512MB，剩余堆空间归老年代
新生代内部再分：Eden + Survivor（通常是 8:1:1）
新生代本身不是均质区域，它被划分为 Eden 区、Survivor0（S0）、Survivor1（S1）三个子区域。默认比例为 Eden : S0 : S1 = 8 : 1 : 1。这意味着：在 1GB 新生代中，Eden 占 800MB，每个 Survivor 各占 100MB。
这个比例由 -XX:SurvivorRatio 控制（如 -XX:SurvivorRatio=8）。每次 Minor GC 后，Eden 和一个 Survivor 中的存活对象会被复制到另一个 Survivor；当对象经历多次复制（默认 15 次，由 -XX:MaxTenuringThreshold 控制）或 Survivor 空间不足时，就会晋升（promote）到老年代。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
比例不是越小越好，需结合应用特征调优
比例设置没有绝对最优，关键看对象创建速率、平均存活时间、GC 频次与停顿表现：
- 若应用短生命周期对象极多（如 Web 请求处理），但新生代过小 → Minor GC 过于频繁，CPU 花费在复制上，可适当增大新生代（如 -XX:NewRatio=1）
- 若大量对象“意外”快速进入老年代（如大数组、缓存预热），导致老年代很快满 → 可能触发频繁 Full GC，这时需检查是否 Survivor 太小（SurvivorRatio 过大）、晋升阈值过低，或对象确实该放老年代（如用 -XX:+UseLargePages 或对象直接分配到老年代的策略）
- 使用 G1 或 ZGC 时，“新生代/老年代”概念弱化（G1 是分区管理，ZGC 无分代），此时传统 NewRatio 参数失效或仅作兼容保留
如何验证当前比例？
启动 JVM 时添加 -XX:+PrintGCDetails -Xloggc:gc.log，观察 GC 日志中的内存布局描述；或运行时用 jstat -gc <pid> 查看各代实际容量（S0C/S1C/EC/OC/MC 等字段）；更直观可用 JConsole 或 VisualVM 连接进程，在“Memory”页签中实时查看各内存池大小与使用率。
