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

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

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

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

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

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

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

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

Mistral AI

Mistral AI被称为“欧洲版的OpenAI”，也是目前欧洲最强的 LLM 大模型平台

182 查看详情 Mistral AI

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

根包括：全局/静态变量、正在执行的方法的局部变量和参数、寄存器中的引用、线程栈上的引用、Finalizer 队列中的对象；
常见“隐式根”陷阱：事件订阅未取消（obj.Event += Handler 使 obj 被 EventHandler 持有）、静态集合 Add 了实例对象、Timer/Task 回调持有 this 引用；
弱引用（WeakReference） 可打破强引用链，让对象在 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内存管理的详细内容，更多请关注其它相关文章！