GC 不是“定时扫垃圾”，而是“按需暂停+标记压缩”——它只在内存分配失败、系统压力大或显式调用时才启动，且每次回收都伴随短暂的 Stop-The-World（STW）暂停。理解这点，才能避开“为什么用了
GC.Collect()反而更卡”这类误区。
分代回收不是分类管理，而是性能优化的核心策略
.NET 把托管堆划为三代（
Gen 0、
Gen 1、
Gen 2），但这个划分不是静态标签，而是对象存活次数的动态记录：
new出来的对象默认进
Gen 0； 一次
Gen 0GC 后还活着，就升到
Gen 1； 再活过一次
Gen 1GC，就进
Gen 2；
Gen 2对象基本不挪动，除非触发全堆回收（Full GC）。
关键点：90% 的对象死在
Gen 0，所以 GC 大部分时间只扫描几 MB 内存，极快。一旦你把短期对象（比如循环里的
byte[1024]）长期持有（例如塞进静态
List<byte></byte>），它就会不断晋升，最终拖慢
Gen 2回收——这是最常见性能拐点。
标记-清除-压缩三步缺一不可，但压缩只对小对象生效
GC 不是简单删掉对象就完事。它必须保证后续分配还能用“指针碰撞”（Bump Pointer）这种 O(1) 速度分配新对象，所以压缩必不可少：
标记阶段：从根（静态字段、栈变量、寄存器等）出发，递归标记所有可达对象； 清除阶段：释放未被标记的内存块； 压缩阶段：仅对Gen 0和
Gen 1中的小对象堆（SOH）执行——把存活对象往低地址挤，腾出连续空闲空间； 大对象堆（LOH）不压缩：>85,000 字节的对象（如大数组）直接进 LOH，GC 清理后只链表记录空闲块，不移动。久而久之就碎片化，可能提前触发 Full GC。
这就是为什么反复
new byte[100000]比
new byte[1000]更容易引发卡顿——前者直奔 LOH，后者还在 SOH 里被快速回收。
手动调用 GC.Collect()
几乎总是错的
CLR 的 GC 调度器比你更懂当前内存状态。强行调用只会：
打断正在运行的后台 GC（Server GC 模式下）； 强制升级本可留在Gen 0的对象； 引发不必要的 STW 暂停，尤其在 UI 线程调用时直接卡界面； 掩盖真正问题：比如事件没解绑、缓存没清理、
IDisposable没用
using。
唯一合理场景：进程即将退出，或长时间后台任务结束前想主动释放一批大资源（仍建议只指定
GC.Collect(0)，避免触碰
Gen 2）。
真正该盯住的不是 GC 本身，而是对象生命周期——谁在持有着不该持有的引用？静态集合是否在无限增长？
Finalizer是否在阻塞终结队列？这些才是 GC 表现异常背后的实锤线索。
