分代回收的核心依据是“大多数对象朝生夕死”，即超90%新对象在几次GC后即死亡，而幸存者往往长期驻留；该假说驱动ZGC、V8、CPython等采用分代设计，通过隔离高死亡率区与低死亡率区实现高效回收。
分代回收的核心依据是“大多数对象朝生夕死”——这个观察结论不是凭空猜测，而是大量真实应用运行数据反复验证的结果。它直接决定了现代主流运行时（Java ZGC、V8、CPython）为何都采用分代设计：把堆按对象存活时间粗略切开，让回收策略更贴合实际内存行为。
分代假说到底在说什么
它包含两个关键观察：
- 新分配的对象中，超过90%在几次GC后就不再被引用，属于“瞬时存在”的临时变量、中间计算结果等
- 能活过前几轮GC的对象，往往会长期驻留，比如单例、缓存、连接池、全局配置等
这使得统一扫描整块堆变得低效：为找那10%的长命对象，却要反复检查90%早已死亡的区域。分代就是用空间换时间，把“高死亡率区”和“低死亡率区”物理或逻辑隔离，各自定制处理节奏。
短生命周期对象的分配优化要点
目标不是阻止它们产生，而是让它们“生得轻、死得快、不拖累别人”。关键在于控制它们的出生位置和晋升路径：
-
优先走TLAB（线程本地分配缓冲）：避免多线程争抢堆内存锁。ZGC和G1都默认启用，无需额外配置；若发现分配慢，可适当增大
-XX:TLABSize - 避免大对象直接进老年代：比如一次性创建超大数组、字符串拼接结果。这类对象即使只用一次，也会绕过年轻代，占用老年代空间并触发跨代扫描。应拆解或复用缓冲区
-
减少提前晋升：对象在年轻代没经历足够次数GC就被移到老年代，常见原因是Survivor区太小或对象过大。可通过
-XX:MaxTenuringThreshold（G1/ZGC分代下对应调整）或增大Survivor比例（-XX:SurvivorRatio）缓解 - 警惕隐式长生命周期：局部变量被闭包捕获、临时集合被放入静态Map、日志上下文意外持有请求对象——这些都会让本该快速消亡的对象“卡”在年轻代甚至晋升到老年代
不同语言/运行时的落地差异
虽然假说一致，但实现细节影响调优方向：
-
ZGC分代模式：需显式开启
-XX:+ZGenerational，否则退化为统一堆。年轻代大小可调（-XX:NewSize），但ZGC更倾向自动管理，人工干预宜保守 - V8引擎：新生区（Scavenger）使用复制算法，两次GC不死亡即升入中间区，再活一次才进老年代。频繁小对象分配建议复用对象池，避免持续触发Scavenge
-
Python：第0代阈值（默认700次分配）最敏感。高频创建销毁场景可微调
gc.set_threshold(300, 5, 5)加快第0代回收，但需防过度触发反拖慢吞吐
真正有效的优化，不是堆参数调到极致，而是让代码生成的对象天然符合分代规律：小、散、短命、无跨代引用。理解假说，是为了写出更“友好”的内存行为。
