c# 垃圾回收gc原理_网络技术_宿州市腾雀网络科技有限公司

发布时间 - 2026-01-03 00:00:00 点击率：次

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

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

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

关键点：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 里被快速回收。

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

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

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