Finalizer 线程是独立于 GC 的后台线程
GC 触发时，不会同步执行
Finalize方法；它只负责标记“可回收对象”，并将其中带有
Finalize方法的对象放入一个内部队列（
freachable queue）。真正调用
Finalize的是 .NET 运行时维护的单独线程——Finalizer 线程，它持续从该队列取对象并逐个调用其
Finalize方法。
这意味着：
Finalize执行时机完全不可控，可能延迟数秒甚至更久，尤其在低负载或 GC 不频繁时 Finalizer 线程默认是单线程（.NET 5+ 仍为单线程），若某个
Finalize方法阻塞（如等待锁、I/O），会拖慢整个队列的处理 GC 不等待
Finalize完成就继续下一轮回收；未完成 finalization 的对象在下次 GC 时才可能真正释放内存
GC.Collect() 不保证 Finalize 立即运行
调用
GC.Collect()只触发一次垃圾回收，把带 finalizer 的对象移入
freachable queue。但 Finalizer 线程是否立刻消费该队列，取决于它当前是否空闲、是否有其他 pending finalizers、以及运行时调度策略。
常见误操作：
GC.Collect(); GC.WaitForPendingFinalizers();—— 这能强制等待，但仅用于测试或极少数特殊场景（如单元测试中验证资源清理） 在
Finalize中调用
GC.Collect()—— 完全无效，且可能引发死锁或性能恶化 依赖
Finalize做关键资源释放（如文件句柄、数据库连接）—— 因为延迟和不确定性，极易导致资源泄漏或
IOException
Finalizer 和 IDisposable 的协作机制
.NET 推荐使用“终结器 + IDisposable”双模式（即
Dispose pattern），核心在于：通过
GC.SuppressFinalize(this)主动切断 finalization 流程。
典型结构如下：
~MyResource()
{
Dispose(false); // 不释放托管资源，只释放非托管资源
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this); // ← 关键：告诉 GC 别再进 freachable queue
}
protected virtual void Dispose(bool disposing)
{
if (_disposed) return;
if (disposing)
{
// 释放托管资源（如 Stream.Close()）
}
// 释放非托管资源（如 CloseHandle()）
_disposed = true;
}
注意点：
一旦调用Dispose()，必须立即调用
GC.SuppressFinalize(this)，否则对象仍会在下次 GC 时被 finalizer 线程处理，造成重复释放
Dispose(false)在 finalizer 中调用，此时托管对象可能已被回收，不能访问其他托管成员（只能操作字段或非托管句柄） Finalizer 中禁止抛出异常——未捕获的异常会终止 Finalizer 线程，导致后续所有 finalizer 永远不执行
Finalizer 线程在 .NET Core/.NET 5+ 中的行为变化
虽然 Finalizer 线程仍是单线程，但运行时做了若干底层优化：
不再使用 Windows 的WaitForMultipleObjects，改用更轻量的同步原语，降低唤醒延迟 对空
freachable queue的轮询改为基于事件驱动，减少 CPU 空转 Finalizer 线程优先级仍为
ThreadPriority.Normal，但受 GC 压力影响更大：当内存紧张时，Finalizer 线程会被更积极地调度
AppDomain.Unload或进程退出时，Finalizer 线程会被强制中断，未执行的
Finalize直接丢弃——这也是为什么不能依赖 finalizer 做关键清理
最常被忽略的一点：finalizer 是对象生命周期里唯一可能跨 GC 轮次存在的“残留状态”。只要没被
SuppressFinalize，哪怕对象已显式
Dispose，它仍可能在某次 GC 后进入
freachable queue，最终被 Finalizer 线程调用——所以
Dispose里务必做双重检查（
_disposed标志）。
