GC是按需触发的内存调度器，非定时清扫；通过可达性分析判断对象存活，依据根引用链；分代机制基于对象存活次数，高频小对象进SOH快速回收，大对象进LOH易碎片化；手动调用GC.Collect()通常有害，应优先监控和释放非托管资源。
GC 不是后台定时清扫的“保洁员”，而是按需触发的内存调度器——它只在分配失败、系统告警或你误调用 GC.Collect() 时暂停线程，完成标记→清除→压缩三步操作。理解这点，才能避开“为什么加了 GC.Collect() 反而更卡”这种典型误区。
GC 怎么判断一个对象该被回收？
核心是可达性分析：从所有“根（Root）”出发，能触达的对象就是活的；其余一律当垃圾。根包括：static 字段、当前栈帧里的局部变量、CPU 寄存器中的引用、GC Handle、终结队列中的对象。
- 局部变量超出作用域（如方法返回后），引用立即消失 → 对象可能在下次 Gen 0 GC 就被回收
- 静态集合长期持有对象（比如
static List<byte> cache</byte>）→ 对象无法被根释放 → 晋升到 Gen 2，拖慢全堆回收 - 事件未解绑（
someObj.Event += handler但没 -=）→ 订阅者被发布者强引用 → 内存泄漏高发区
为什么分代（Gen 0/1/2）？90% 的对象死在 Gen 0
分代不是分类标签，而是对象“存活次数”的动态记录：新对象进 Gen 0；活过一次 Gen 0 GC → 升 Gen 1；再活过一次 → 进 Gen 2。Gen 2 回收代价最高，应尽量避免触发。
- 高频创建小对象（如循环中
new byte[1024]）→ 留在 SOH（Small Object Heap），Gen 0 快速回收，无压力 - 频繁分配大数组（如
new double[12000]≈ 96KB）→ 直接进 LOH（Large Object Heap）→ 只随 Gen 2 GC 清理，且不压缩 → 易碎片化、提前触发 Full GC - 服务器场景建议启用
gcServer=true：为每个 CPU 核心分配独立 GC 线程和堆，吞吐更高
LOH（大对象堆）为什么特别危险？
大于 85,000 字节的对象（如大数组、大字符串）自动进入 LOH。它不压缩内存，只靠空闲链表管理，碎片累积到一定程度，即使总空闲空间足够，也无法分配新大对象 → 强制触发 Gen 2 GC。
- 错误写法：
var buffer = new byte[1024 * 1024]; // 1MB → LOH - 推荐替代：
var buffer = ArrayPool<byte>.Shared.Rent(1024 * 1024); ... ArrayPool<byte>.Shared.Return(buffer);</byte></byte> - .NET 6+ 可开启 LOH 压缩（需配置
gcAllowVeryLargeObjects=true+gcConcurrent=true），但仅限 Gen 2 GC 时生效，不能解决高频分配问题
什么时候该干预 GC？几乎从不该手动调用 GC.Collect()
手动触发 GC 是反模式：它强制 STW 暂停，打乱 GC 自身的节奏预测，反而加剧抖动。真正需要干预的场景极少，且方式更精细：
- 极短生命周期关键路径（如实时音视频帧处理），可用
GC.TryStartNoGCRegion(size)预留空间，避免途中 GC 中断 - 长时间空闲期（如 UI 应用最小化后），可调用
GC.Collect(2, GCCollectionMode.Forced, blocking: true)—— 仅此一种较合理场景 - 监控优先：用
GC.CollectionCount(2)或 PerfView 查% Time in GC，持续 >5% 才值得深挖
最常被忽略的一点：GC 不管非托管资源。文件句柄、数据库连接、GDI 对象这些，必须靠 IDisposable + using 显式释放；否则 GC 再勤快，也会因句柄耗尽而崩溃。
