在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大对象堆（LOH）特别提醒
大于85,000字节的对象（如大数组、大字符串）直接进入LOH，它只随Gen 2 GC回收，且默认不压缩（.NET Core 3.0+ 开始在Gen 2 GC时可选压缩，需启用gcServer和gcConcurrent并设置gcAllowVeryLargeObjects）。频繁分配大对象极易导致LOH碎片和内存暴涨。建议：
拆分大任务，避免单次申请超大缓冲区 使用ArrayPool基本上就这些。GC不是黑盒，也不是越“手动”越好——关键是让对象自然短命、减少跨代提升、避开LOH陷阱。写得清楚，回收就省心。
