C#垃圾回收通过可达性分析判断对象存活，采用三代机制（Gen 0/1/2）和大对象堆（LOH）管理内存；优化需复用对象、及时解引用、慎用Finalize、监控GC指标并避免频繁分配大对象。
在C#中，垃圾回收（GC）由.NET运行时自动管理，开发者无需手动释放内存，但理解其工作原理并合理优化，能显著提升应用性能与内存稳定性。
GC如何判断对象该被回收
GC采用“可达性分析”：从根（Root）出发，包括全局变量、静态字段、线程栈上的局部变量、CPU寄存器中的引用等。所有能被根直接或间接访问到的对象视为“存活”，其余对象标记为“可回收”。注意：即使对象重写了Finalize()（或析构函数），它也不会立刻被销毁，而是先进入终结队列，等待下一次GC周期中由终结器线程调用——这会延迟回收，还可能引发内存堆积。
三代回收机制（Generation 0/1/2）
.NET GC将托管堆分为三代，基于“弱代假说”（多数对象生命周期短）设计：
- Gen 0：最新分配的小对象区域，最频繁回收。触发条件通常是分配空间不足
- Gen 1：从Gen 0幸存下来的对象。回收频率较低，主要起缓冲作用
- Gen 2：长期存活的大对象（如数组 > 85KB）或多次幸存对象。回收开销最大，应尽量避免频繁触发
每次GC都会“提升”未被回收的对象到下一代。大对象（LOH）单独存放，只在Gen 2 GC时清理，且不压缩内存（易碎片化）。
常见优化方法
优化核心是减少GC压力，尤其是降低Gen 0频率和避免Gen 2回收：
- 复用对象，避免高频分配：例如用StringBuilder代替字符串拼接；用ArrayPool<T>或MemoryPool<T>复用数组缓冲区
- 及时解除引用：将不再需要的长生命周期对象字段设为null（尤其在事件订阅、缓存、静态集合中），帮助GC提前识别不可达对象
- 慎用Finalize / 析构函数：改用IDisposable + using显式释放非托管资源；若必须用终结器，确保它极轻量，并在Dispose()中调用SuppressFinalize()
- 监控与诊断：用Visual Studio诊断工具、dotnet-trace 或 PerfView 查看GC计数、暂停时间、各代大小；关注% Time in GC指标是否持续偏高（>5%需警惕）
大对象堆（LOH）特别提醒
大于85,000字节的对象（如大数组、大字符串）直接进入LOH，它只随Gen 2 GC回收，且默认不压缩（.NET Core 3.0+ 开始在Gen 2 GC时可选压缩，需启用gcServer和gcConcurrent并设置gcAllowVeryLargeObjects）。频繁分配大对象极易导致LOH碎片和内存暴涨。建议：
- 拆分大任务，避免单次申请超大缓冲区
- 使用ArrayPool<byte>.Shared.Rent(…)替代new byte[1024*1024]
- 对固定尺寸大结构，考虑Span<T>或Memory<T>配合池化管理
基本上就这些。GC不是黑盒，也不是越“手动”越好——关键是让对象自然短命、减少跨代提升、避开LOH陷阱。写得清楚，回收就省心。
