java对象晋升老年代由jvm在minor gc时根据空间压力实时决策，核心条件包括动态年龄判定、survivor空间不足和大对象直入，并需通过空间分配担保检查。
Java 中对象晋升老年代不是靠时间或手动控制，而是 JVM 在每次 Minor GC 过程中，结合内存布局、对象年龄、大小和空间可用性实时决策的结果。理解它，关键在于抓住“分代假说”这个设计原点：大多数对象朝生夕死，只有少数长期存活或体积过大者才适合留在老年代。
年轻代的物理结构决定晋升起点
年轻代默认占堆的 1/3，内部按 Eden : S0 : S1 = 8 : 1 : 1 划分（由 -XX:SurvivorRatio=8 控制）。新对象几乎都出生在 Eden 区；两个 Survivor 区交替使用，作为对象经历 GC 后的暂存缓冲区。这种结构天然限制了对象“停留”的空间——一旦 Survivor 装不下，就必须找地方安置，老年代就是兜底选择。
对象年龄只是参考，空间压力才是触发器
对象每经历一次 Minor GC 且存活，年龄 +1，记录在对象头中。但晋升不等于“活满 15 次就走”。真正起作用的是以下三种空间相关条件：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 动态年龄判定：Minor GC 后，JVM 从 age=1 开始累加 Survivor 中各年龄段对象大小，首次累计 ≥ Survivor 容量 × 50%（TargetSurvivorRatio 默认值）时，该年龄及更老的对象全部晋升；
- Survivor 空间不足：存活对象总量超出 To 区容量，多余部分无论年龄多小，直接晋升；
- 大对象直入：对象大小 ≥ -XX:PretenureSizeThreshold（如设为 4MB），跳过年轻代，直接在老年代分配（仅 Serial/ParNew 收集器生效）。
晋升前必须通过“空间分配担保”检查
每次 Minor GC 前，JVM 不会盲目执行，而是预判老年代是否能接住即将晋升的对象：
- 若老年代最大连续空闲空间 ≥ 当前新生代所有对象总大小 → 安全执行 Minor GC；
- 否则，再看是否 ≥ 历次晋升平均大小 → 尝试带风险的 Minor GC；
- 都不满足 → 提前触发 Full GC，腾出空间；失败则抛出 OutOfMemoryError。
调优时重点关注日志里的真实阈值
开启 -XX:+PrintGCDetails 后，Minor GC 日志中会出现类似：
Desired survivor size 524288 bytes, new threshold 3 (max 6)其中 new threshold 3 是本次动态算出的晋升起点年龄，比配置的 max 值更反映实际压力。频繁出现 low threshold（如 1 或 2）说明 Survivor 过小、对象生命周期集中，或存在批量短命大对象，需调整 SurvivorRatio 或 PretenureSizeThreshold。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
