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 代；强制全代回收会阻塞当前线程，并可能引发更长暂停——它应是诊断手段，而非常规优化方式。
对象“存活”与否取决于根引用链是否可达
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/MemoryPool减少 LOH 分配； - 实现
IDisposable并在Dispose()中释放非托管资源（文件句柄、数据库连接等），避免依赖 Finalizer——Finalizer 执行时机不确定，且会延长对象生命周期（至少多一次 GC）。
基本上就这些。GC 不是魔法，它高效的前提是你写的代码尊重它的规则：减少不必要的长引用、及时解耦、合理使用池和弱引用。真正影响性能的往往不是 GC 本身，而是我们无意中制造的“该死的存活对象”。
