17370845950

GC是按需触发的标记-压缩回收机制，非定时执行；.NET分代回收通过对象存活次数动态晋升，90%对象死于Gen 0；标记-清除-压缩三步确保高效分配，但LOH不压缩易碎片化；手动调用GC.Collect()几乎总是错误。

GC 不是“定时扫垃圾”，而是“按需暂停+标记压缩”——它只在内存分配失败、系统压力大或显式调用时才启动，且每次回收都伴随短暂的 Stop-The-World（STW）暂停。理解这点，才能避开“为什么用了 GC.Collect() 反而更卡”这类误区。

分代回收不是分类管理，而是性能优化的核心策略

.NET 把托管堆划为三代（Gen 0、Gen 1、Gen 2），但这个划分不是静态标签，而是对象存活次数的动态记录：

• new 出来的对象默认进 Gen 0；
• 一次 Gen 0 GC 后还活着，就升到 Gen 1；
• 再活过一次 Gen 1 GC，就进 Gen 2；
• Gen 2 对象基本不挪动，除非触发全堆回收（Full GC）。

关键点：90% 的对象死在 Gen 0，所以 GC 大部分时间只扫描几 MB 内存，极快。一旦你把短期对象（比如循环里的 byte[1024]）长期持有（例如塞进静态 List），它就会不断晋升，最终拖慢 Gen 2 回收——这是最常见性能拐点。

标记-清除-压缩三步缺一不可，但压缩只对小对象生效

GC 不是简单删掉对象就完事。它必须保证后续分配还能用“指针碰撞”（Bump Pointer）这种 O(1) 速度分配新对象，所以压缩必不可少：

• 标记阶段：从根（静态字段、栈变量、寄存器等）出发，递归标记所有可达对象；
• 清除阶段：释放未被标记的内存块；
• 压缩阶段：仅对 Gen 0 和 Gen 1 中的小对象堆（SOH）执行——把存活对象往低地址挤，腾出连续空闲空间；
• 大对象堆（LOH）不压缩：>85,000 字节的对象（如大数组）直接进 LOH，GC 清理后只链表记录空闲块，不移动。久而久之就碎片化，可能提前触发 Full GC。

这就是为什么反复 new byte[100000] 比 new byte[1000] 更容易引发卡顿——前者直奔 LOH，后者还在 SOH 里被快速回收。

手动调用 GC.Collect() 几乎总是错的

CLR 的 GC 调度器比你更懂当前内存状态。强行调用只会：

• 打断正在运行的后台 GC（Server GC 模式下）；
• 强制升级本可留在 Gen 0 的对象；
• 引发不必要的 STW 暂停，尤其在 UI 线程调用时直接卡界面；
• 掩盖真正问题：比如事件没解绑、缓存没清理、IDisposable 没用 using。

唯一合理场景：进程即将退出，或长时间后台任务结束前想主动释放一批大资源（仍建议只指定 GC.Collect(0)，避免触碰 Gen 2）。

真正该盯住的不是 GC 本身，而是对象生命周期——谁在持有着不该持有的引用？静态集合是否在无限增长？Finalizer 是否在阻塞终结队列？这些才是 GC 表现异常背后的实锤线索。