分代回收是基于对象存活率统计规律的工程实践：98%新生代对象活不过一次Minor GC，因大量临时对象（如方法内list、DTO）创建后立即失去引用，JVM据此划分新生代与老年代以优化GC效率。
分代回收不是玄学，而是对“对象朝生夕死”这一高频现象的工程响应——理解它，关键在看懂对象存活率分布，而不是背算法。
为什么新生代对象 98% 活不过一次 Minor GC？
这不是理论推导，而是大量真实应用堆快照统计出的规律：新分配的对象（比如函数内临时创建的 list、dict、短生命周期 DTO）几乎立刻失去引用。JVM、V8、CPython 都观察到类似分布，所以不约而同把堆逻辑切分成“年轻”和“老”两块。
这意味着：你写的每行 new Object() 或 []，默认都该落在新生代；如果它真活过了两次 GC，那才值得挪去老年代——否则就是浪费扫描开销。
- Java 中 Eden 区满就触发
Minor GC，只扫新生代，停顿极短 - V8 新生区用“Scavenge”复制算法，靠指针碰撞快速分配+复制存活对象
- Python 的第 0 代（
gc.collect(0)）阈值设得最低（默认 700 次分配），就是为高频清理小对象
短生命周期对象写法直接影响 GC 压力
哪怕用了 ZGC 或 Python 3.13，如果代码持续制造“本该短命却意外延长寿命”的对象，分代机制就形同虚设。
常见踩坑点：
- 把局部
StringBuilder或ArrayList缓存在静态字段或长生命周期对象里，导致无法及时进入第 0 代回收周期 - Python 中用
global或闭包捕获大量临时数据，让本该被引用计数即时释放的对象被迫进gc循环检测 - JS 里给事件监听器传匿名函数并长期挂载，内部闭包捕获的上下文对象卡在新生区晋升失败，反复拷贝
优化方向很直接：让对象“出生即孤立”，不跨作用域泄漏引用。例如 Java 中优先用 var 局部变量、避免 this.xxx = new ArrayList() 在构造器里无条件初始化。
ZGC 和 Python 的分代开关必须显式启用
分代不是默认打开的魔法，是需要你确认激活的特性。
- JDK 17+ 启用 ZGC 分代模式，仅加
-XX:+UseZGC不够，必须补上-XX:+ZGenerational，否则退化为统一堆模式，失去年轻代快速回收优势 - Python 默认开启分代，但如果你调过
gc.disable()，就得手动gc.enable()；且gc.set_threshold()第一个参数（第 0 代阈值）别设太高，否则短对象积压成灾 - V8 没有用户可控开关，但可通过
--trace-gc观察Scavenge（新生代）和Mark-sweep（老年代）的频次比，若前者远少于后者，说明对象过早晋升，要查代码里是否有隐式强引用
真正难的从来不是配置参数，而是判断一个对象“到底该活多久”——这取决于你对业务逻辑中数据流转路径的理解，而不是 GC 日志里的一行 GC (Allocation Failure)。
