分代回收基于“弱代假说”，即98%对象朝生夕死，应在新生代快速回收；其核心是对象是否被跨作用域强引用，而非配置开关——被静态字段、闭包等意外持有会导致短命对象晋升老年代，拖慢GC。
分代回收不是配置开关，而是你每次 new、[]、dict() 时默认触发的内存分配路径——理解它，关键在看清对象“出生后有没有被跨作用域持有”。
为什么98%的对象活不过一次Minor GC？
这不是理论推导，是JVM、V8、CPython、.NET都实测出的堆快照统计规律：方法内创建的 ArrayList、StringBuilder、DTO、list、dict，几乎立刻失去引用。它们本该在Eden区或第0代被快速扫掉。一旦你用静态字段、闭包、事件监听器、缓存容器无意中延长了它们的寿命，这些对象就会“卡在晋升路上”，反复被复制、扫描，拖慢整个GC周期。
常见错误现象：
-
OutOfMemoryError: Java heap space频发，但堆dump显示大量小对象堆积在老年代 - Python中
gc.collect(0)耗时突然变长，且gc.get_count()显示第0代计数长期不归零 - .NET应用在高频请求下出现毫秒级STW暂停，
dotnet-trace显示Gen 2 GC频率异常升高
Java里让短生命周期对象真正“短命”的写法
Eden区满就触发Minor GC，但前提是对象不被意外晋升。晋升不是因为“活久见”，而是因为“被强引用链锁住”。
实操建议：
- 避免在构造器中无条件初始化成员变量：
this.cache = new HashMap()→ 改为按需懒加载或使用局部变量 - 循环内拼接字符串优先用
StringBuilder（栈上分配+复用），不用String +（每次生成新对象） - 不要把
ThreadLocal或static final Map当作临时容器反复put，这会让对象无法进入第0代回收节奏 - 检查
finalize()或 Cleaner 注册——它们会强制对象至少经历两次GC才能回收
.NET中Gen 0对象为何没被及时回收？
Gen 0回收快，但前提是它真“空”。如果一个对象被根（如静态字段、正在运行的线程栈）直接或间接引用，哪怕只有一条路径，它就不会被标记为垃圾。
容易踩的坑：
- 事件订阅未取消：
button.Click += OnClick;但没在Dispose()中-=，导致整个UI控件树卡在Gen 1 - 大对象堆（LOH）误用：创建 >85,000 字节的数组或字符串，即使只用一次，也会跳过Gen 0/1，直奔LOH，且不压缩——碎片积累后触发全GC
- 异步状态机捕获过多局部变量：一个
async方法里定义了5个var，编译器生成的状态机类会把它们全打包成字段，延长生命周期
Python分代阈值调得太大会怎样？
默认第0代阈值是700次分配，意味着每新增700个对象就触发一次 gc.collect(0)。设成7000，不是“更省事”，而是让6300个本该秒删的对象积压在内存里，等第1代回收时才扫——这时它们已混入更多存活对象，扫描开销指数上升。
判断依据：
- 运行
import gc; gc.set_debug(gc.DEBUG_STATS)，观察输出中collected 0后面的数字是否持续飙升 - 用
gc.get_objects(0)抽样看第0代里是否存在大量预期已失效的dict或list - 禁用分代后手动调
gc.collect()，若性能反而提升，说明当前分代节奏已失配代码行为
真正难的不是调 gc.set_threshold()，而是确认你的 for 循环里新建的 item 对象，有没有被某个闭包、global 或类实例悄悄 hold 住。
