分代回收是基于对象“朝生夕死”规律的工程优化：年轻代专收短命对象（如70%~95%活不过一次gc），用轻量算法快速回收；老年代只存幸存对象，避免全堆扫描；跨代引用需记忆集维护；zgc需显式开启-xx:+zgenerational才生效；python第0代阈值控制临时对象回收频率；v8新生区分配失败实为晋升信号，反映生命周期预估偏差。
分代回收不是玄学，而是对对象死亡规律的工程化利用：绝大多数对象在分配后几毫秒内就不可达，这个事实决定了你该把新对象往哪放、何时触发回收、甚至要不要手动干预。
为什么“朝生夕死”能变成内存优化杠杆
分代假说（The Generational Hypothesis）本质是统计结论——不是所有对象都一样“命硬”。V8、ZGC、CPython 都观察到：70%~95% 的对象活不过一次 GC 周期。这意味着，如果把所有对象混在一块扫描，等于用重型挖掘机去清理桌面灰尘。
- 年轻代（Young Generation）专为这类短命对象设计：空间小、回收快、算法轻量（如复制算法）
- 老年代（Old Generation）只收“扛过两轮 GC 还活着”的对象，避免频繁全堆扫描
- 跨代引用（比如老年代对象持有年轻代对象引用）必须被记录，否则年轻代 GC 时会漏判存活对象——这就是记忆集（Remembered Set）存在的原因
ZGC 分代模式下，-XX:+ZGenerational 开关不加等于白配
ZGC 默认是不分代的统一堆模式，哪怕你堆设了 -Xmx32g，它也当一块大平地来扫。只有显式加上 -XX:+ZGenerational，JVM 才会划分年轻代/老年代逻辑区域，并启用对应的并发 Minor GC 路径。
- 不加这个参数，ZGC 仍低延迟，但无法享受“高频小范围回收”的红利，尤其在高创建率服务中，Minor GC 次数可能反升
-
-XX:NewSize和-XX:MaxNewSize只在开启分代后生效；未开启时设了也 ignored - JDK 17+ 才支持该参数，JDK 16 或更早版本加了会直接报错：
Unrecognized VM option 'ZGenerational'
Python 的 gc 模块里，第 0 代阈值才是短生命周期对象的开关
Python 的分代回收有三代（0、1、2），其中第 0 代（gen=0）完全对应“刚分配就可能死”的对象。它的回收频率由 gc.get_threshold() 返回的第一个数字控制，默认是 700：每分配 700 个新对象就触发一次第 0 代回收。
- 如果你的应用大量生成临时字典/列表（比如 Web 请求解析），把
gc.set_threshold(300, 10, 10)能提前释放内存，减少第 1/2 代压力 - 但别设太低（如
50）：频繁调用gc.collect(0)会增加 CPU 开销，尤其在单核或 I/O 密集型场景 - 注意：引用计数仍实时工作，
gc模块只管循环引用和代际晋升——所以即使关掉gc.disable()，局部变量仍会在作用域退出时立即释放
V8 新生区（Scavenger）的分配失败不是 OOM，而是晋升信号
V8 把年轻代拆成 new_space（新生区）和 old_space（老年代），而新生区又分两个半区（From/To）。对象总是在 From 半区分配，GC 时把存活对象复制到 To 半区，然后交换角色。
- 当 From 半区满，但 To 半区装不下所有存活对象 → 触发“晋升”（promotion），直接把这批对象挪进老年代
- 这不是错误，是设计行为；但若频繁发生（比如大量长生命周期对象误入新生区），说明对象生命周期预估失准，应检查是否用了
new Array(10000)这类大对象初始化 - V8 不允许手动指定某对象进老年代，但可通过
globalThis.weakRef = new WeakRef(obj)或长期持有引用来自然延缓晋升
真正难的不是理解“分代”，而是判断你的对象到底属于哪一代——这需要看分配现场：是请求上下文里的临时 map，还是全局配置单例？前者压根不该让它活过一次 event loop，后者从一开始就不该出现在新生区。
