C# 垃圾回收(GC)机制是如何工作的 - 深入理解.NET内存管理

C#垃圾回收是分代、可干预的内存管理机制，按0/1/2代划分对象生命周期，通过根引用链判定存活，支持低延迟模式、NOGC区域等配置优化。

C# 的垃圾回收（GC）不是“自动清理内存”的黑箱，而是一套有策略、分代、可干预的内存管理机制。 它在后台持续监控对象生命周期，按需回收不可达对象所占堆内存，但它的行为受代码写法、对象大小、代际划分和运行时环境共同影响——理解这些细节，才能真正避免内存泄漏和 GC 频繁暂停。

堆内存被划分为三代：0代、1代、2代

.NET GC 采用“分代回收”策略，核心假设是：大部分对象生命周期很短，少数长期存活的对象应减少扫描频率。因此托管堆被逻辑划分为三代：

• 0代：最新分配的对象所在区域，GC 最频繁触发（如局部变量、临时集合）。回收后仍存活的对象会被提升到 1 代；
• 1代：中等生命周期对象，GC 触发频率较低，主要作为 0→2 的缓冲；
• 2代：长期存活对象（如静态缓存、全局服务实例），GC 开销最大，只在必要时（如内存压力大或调用 GC.Collect(2)）才回收。

代际提升不是复制移动就是标记压缩——小对象堆（SOH）在回收后会整理内存以减少碎片；大对象堆（LOH，≥85,000 字节）不整理，只做标记清除，容易产生内存碎片。

GC 触发条件不只是“内存不够”

触发 GC 并非等到物理内存耗尽。常见触发场景包括：

• 0代内存分配超过阈值（由运行时动态估算，与历史分配速率相关）；
• 显式调用 GC.Collect()（不推荐，干扰运行时优化）；
• 系统内存不足通知（Windows 的 MEMORYSTATUS 或 Linux 的 cgroup 压力信号）；
• 应用程序空闲且后台 GC 线程启动（.NET Core 3.0+ 的后台 GC 模式）。

注意：GC.Collect() 默认只回收 0 代；强制全代回收会阻塞当前线程，并可能引发更长暂停——它应是诊断手段，而非常规优化方式。

乾坤圈新媒体矩阵管家

新媒体账号、门店矩阵智能管理系统

219

查看详情

对象“存活”与否取决于根引用链是否可达

GC 判定对象是否可回收，本质是图遍历：从所有“根”（Roots）出发，沿着引用关系向下搜索，所有能到达的对象视为“存活”，其余标记为垃圾。

• 根包括：全局/静态变量、正在执行的方法的局部变量和参数、寄存器中的引用、线程栈上的引用、Finalizer 队列中的对象；
• 常见“隐式根”陷阱：事件订阅未取消（obj.Event += Handler 使 obj 被 EventHandler 持有）、静态集合 Add 了实例对象、Timer/Task 回调持有 this 引用；
• 弱引用（WeakReference） 可打破强引用链，让对象在 GC 时能被回收，适合缓存场景。

可控的 GC 行为：配置与提示

虽然不能完全控制 GC 时间点，但可通过以下方式引导其行为：

• 使用 GC.TryStartNoGCRegion(sizeInBytes) 在关键路径（如实时音频处理）临时禁止 GC，确保低延迟；
• 设置 GC 模式：GCSettings.LatencyMode = GCLatencyMode.LowLatency（短期启用，需及时恢复）；
• 大对象尽量复用或使用 ArrayPool<t></t> / MemoryPool<t></t> 减少 LOH 分配；
• 实现 IDisposable 并在 Dispose() 中释放非托管资源（文件句柄、数据库连接等），避免依赖 Finalizer——Finalizer 执行时机不确定，且会延长对象生命周期（至少多一次 GC）。

基本上就这些。GC 不是魔法，它高效的前提是你写的代码尊重它的规则：减少不必要的长引用、及时解耦、合理使用池和弱引用。真正影响性能的往往不是 GC 本身，而是我们无意中制造的“该死的存活对象”。

以上就是C# 垃圾回收(GC)机制是如何工作的 - 深入理解.NET内存管理的详细内容，更多请关注php中文网其它相关文章！