分代收集的理论依据是对象生命周期分布的客观规律：约80%–95%对象“朝生夕灭”，在首次minor gc即回收；少数“老而弥坚”对象经多次gc后长期存活，晋升老年代；机制通过年龄计数、大对象直入、survivor溢出和记忆集动态适配实际存活模式。
分代收集的理论依据，核心在于对象真实的生命周期分布——不是凭空设计，而是从海量 Java 应用运行数据中总结出的客观规律。
“朝生夕灭”是绝大多数对象的真实状态
实证数据显示：约 80%–95% 的对象在第一次 Minor GC 时就被回收；IBM 研究指出，近 98% 的对象在新生代一次 GC 后即消亡。这类对象包括：
- 方法内临时创建的 String、包装类、局部集合
- HTTP 请求生成的 DTO、JSON 解析中间对象
- 循环中反复 new 出的短生命周期实例
它们存活时间极短，往往只跨越几个毫秒或一次方法调用。这种高死亡率，让“快速扫描 + 少量复制”的策略成为最优解。
“老而弥坚”是少数对象的稳定特征
能熬过 5 次以上 Minor GC 的对象，后续长期存活的概率显著上升。这类对象通常具备全局性、容器性或缓存性，例如：
- Spring 容器管理的单例 Bean
- 连接池、线程池中的核心资源对象
- 应用级缓存（如 Guava Cache 中的长期条目）
它们数量少、变化慢、占用内存大，不适合高频搬运，更适合低频但彻底的标记类回收。
分代不是硬性割裂，而是动态适配
分代机制靠对象年龄和空间压力自动调节流转，体现的是对生命周期的响应式管理：
- 每次 Minor GC 后仍存活，年龄 +1；默认达 15 次即晋升老年代（可调）
- 大对象（如大数组）直接进入老年代，避免在 Survivor 区反复复制
- Survivor 空间不足时，部分存活对象提前“溢出”到老年代
- 记忆集（Remembered Set）精准记录跨代引用，防止漏标，保障分代正确性
这种设计不强求所有对象严格按代划分，而是让内存布局和回收行为持续贴近实际存活模式。
