分代回收是现代运行时内存管理的底层事实，新对象默认在第0代因绝大多数对象存活时间极短，运行时据此高频次扫描小区域以精准回收；晋升由GC次数而非时间决定。
分代回收不是一种可选的优化技巧，而是现代运行时（如 .NET、JVM、CPython）内存管理的底层事实。你写的每一行对象创建代码，都在被自动归入某一代——理解它，才能让对象“住对地方”，而不是靠 GC.Collect() 或 gc.collect() 硬扛。
为什么“新对象默认在第0代”不是偶然
分代回收基于一个被反复验证的观察：绝大多数对象存活时间极短。比如一个循环里临时拼接的 string、一次 HTTP 请求中解析出的 JsonElement、Python 函数内创建的 list，它们通常在几毫秒内就失去所有引用。
所以运行时把最新分配的对象统一放进最小、最热的区域（.NET 的 Gen 0，JVM 的 Eden，CPython 的 generation 0），并高频次地只扫这一小块。这不是“偷懒”，是精准打击垃圾密度最高的区域。
实操建议：
- 避免在长生命周期对象（如单例服务、静态缓存）里持有短周期对象的引用——这会把本该快速死亡的对象“拖进”Gen 2 或老年代，导致全堆扫描开销陡增
- 不要用
new byte[1024 * 1024]这类大数组做临时缓冲；超过 85 KB（.NET 默认阈值）会直接进大对象堆（LOH），而 LOH 只在 Gen 2 回收时才压缩，极易碎片化 - Python 中，
del局部变量不是必须的，但若函数内创建了大型容器（如含上万元素的dict），显式del它能帮助引用计数及时归零，避免等标记-清除阶段才回收
如何识别并隔离“长寿对象”的真实生命周期
所谓“长寿”，不等于“全局变量”或“static”，而取决于它被谁引用、被引用多久。一个被 Web API Controller 实例持有的 HttpClient，如果 Controller 是 transient（每次请求新建），那这个 HttpClient 其实仍是短命的——但它本该是单例。
常见错误现象：
- .NET 应用中 Gen 2 GC 频率异常升高，且
GC.GetGCMemoryInfo().TotalCommittedBytes持续增长 → 很可能有本该复用的对象被反复 new，或缓存未设上限 - Python
gc.get_stats()显示 generation 2 的 collected 数量远高于 generation 0 → 大量对象活过了前两轮回收，需检查是否误将临时数据塞进了模块级字典 - JVM
jstat -gc输出中OU（Old Used）持续上涨，但OC（Old Capacity）不变 → 老年代在填满，但没触发 Full GC → 可能是内存泄漏，也可能是对象晋升过快（如 Young GC 太频繁，Survivor 区太小）
调整代际阈值前先确认你真需要它
手动调高 Gen 0 阈值（如 .NET 的 System.GC.TryStartNoGCRegion）、降低 Python 的 gc.set_threshold(300, 5, 5)，看似能减少 GC 次数，但代价是更高概率的内存溢出或更长的单次暂停。
真正有效的干预点，在于控制对象“晋升”行为：
- C# 中，用
ArrayPool替代.Shared.Rent(4096) new byte[4096]，池化后的数组不会参与 Gen 0 分配，自然不触发晋升 - Java 中，把频繁修改的字段从对象内拆出，改用
ThreadLocal，避免 StringBuilder 实例被多个线程引用而被迫留在老年代 - Python 中，避免在闭包内捕获大型对象；例如
def make_processor(data): return lambda x: data[x]，这里的data会被闭包长期持有，哪怕外部已无引用
分代回收本身无法被关闭或绕过，你能掌控的只有对象的“出生地”和“居住时长”。最常被忽略的一点是：**晋升不是由时间决定的，而是由 GC 次数决定的**。一个对象只要在 Gen 0 的每次回收中都存活下来，三次之后它就在 Gen 2 了——无论它实际存在了 3 毫秒还是 3 小时。
