Java分代收集理论依据对象在Minor GC中幸存次数（年龄）动态晋升，而非固定时间；新对象入Eden区，存活后移Survivor区并年龄+1，达阈值（默认15）或满足动态判定条件即晋升老年代。
Java 中分代收集理论不是按固定时间（比如“存活1秒以上进老年代”）划分年轻代和老年代，而是依据对象在多次垃圾回收中实际“活下来的次数”，也就是 JVM 内部维护的年龄计数器，来动态判断对象是否该晋升。
年轻代：专收“刚出生、大概率早夭”的对象
新对象默认分配在年轻代的 Eden 区。这类对象多数是方法内临时变量、循环中创建的集合元素、HTTP 请求 DTO 等——用完即弃，95% 以上撑不过一次 Minor GC。
- 每次 Minor GC 后仍存活的对象，会被复制到 Survivor 区，并年龄 +1（初始为 0）
- Eden 区满就触发 Minor GC，只扫描 Eden + 一个 Survivor 区，速度快、停顿短
- Survivor 区采用双缓冲设计（S0 和 S1），避免空间浪费，也支撑对象“反复存活”过程
老年代：接收“经受住考验、长期稳定”的对象
能多次在 Minor GC 中幸存下来，说明这个对象大概率会继续长期存在。比如 Spring 容器管理的单例 Bean、全局缓存 Map、数据库连接池实例等。
- 对象年龄达到阈值（默认 15 次，可通过 -XX:MaxTenuringThreshold 调整）后，在下次 Minor GC 时晋升至老年代
- 不满足年龄阈值也可能提前晋升：Survivor 区同龄对象累计大小 ≥ 其总容量 50%，则该年龄及更老的对象全部晋升（动态年龄判定）
- 大对象（如超长数组）可跳过年轻代，直接分配到老年代（由 -XX:PretenureSizeThreshold 控制）
划分本质是行为驱动，不是时间驱动
所谓“存活周期”，JVM 并不依赖系统时间戳或创建时间，而是用经历 Minor GC 的次数作为代理指标。因为实践中，频繁存活的对象，天然具备长生命周期特征；而一次都活不过的对象，基本没有长期价值。
立即学习“Java免费学习笔记（深入）”；
- 年轻代追求低延迟：复制算法只搬少量存活对象，毫秒级完成
- 老年代追求稳定性：标记-整理算法虽慢，但触发少，且能腾出连续空间供大对象分配
- 两个区域之间靠晋升机制联动，不是静态隔离，而是随应用运行节奏自然流动
