Finalizer Queue 是什么，它真在“排队”吗
Finalizer Queue 不是传统意义的队列，而是 GC 内部维护的一个**带标记的对象链表**，只存那些重写了
Finalize()方法（或用
~ClassName()语法）且尚未被回收的实例。GC 不会按“先来后到”执行终结器，而是由 Finalizer 线程批量取出、逐个调用
Finalize()—— 所以“排队”只是逻辑概念，实际结构是链表 + 标记位。
关键点：只要对象有终结器，且没被
GC.SuppressFinalize()显式抑制，就会被 GC 在第一次标记为不可达时加入该链表。 对象进入 Finalizer Queue 的时机是：GC 第一次发现它不可达，且类型定义了终结器 它不会出现在 Gen 0/1/2 的常规代际堆中，但它的引用关系会影响对象的代际晋升 Finalizer Queue 本身不占用大量内存，但它会让对象多活至少一个 GC 周期（甚至更久）
为什么重写 ~MyClass()
后对象迟迟不被回收
因为终结器让对象经历了“两次 GC 才能释放”的过程：第一次 GC 将其移入 Finalizer Queue 并标记为“待终结”，第二次 GC（或之后）才真正回收——前提是 Finalizer 线程已执行完
Finalize()且对象不再被任何根引用。
常见诱因：
Finalizer 线程被阻塞（比如Thread.Sleep()、锁竞争、同步 I/O）→ 整个队列卡住
Finalize()中抛出未捕获异常 → 当前线程终止，后续终结器可能被跳过（.NET 5+ 默认终止进程） 终结器里又创建了新对象并持有长生命周期引用 → 意外延长其他对象寿命 高频分配带终结器的对象（如每帧 new 一个）→ Finalizer Queue 积压，GC 压力陡增
GC.SuppressFinalize(this)
应该在哪儿调用
必须在你**显式释放了非托管资源之后、且确定不再需要自动终结逻辑时**立即调用。典型场景是实现了
IDisposable的类型，在
Dispose(bool disposing)的
disposing == true分支末尾调用。
错误做法：
在Finalize()里调用 —— 此时已无意义，对象正被终结 在构造函数失败时调用 —— 对象还没完全构建，
this可能无效 仅在
Dispose()外层调用，却忘了在
Dispose(true)中调用 —— 导致
Finalize()仍会被执行
正确模式：
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this); // ← 这行必须有，且只在这里写一次
}
<p>protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// 释放托管资源
_stream?.Dispose();
}
// 释放非托管资源（如句柄、内存指针）
if (_handle != IntPtr.Zero)
{
NativeMethods.CloseHandle(_handle);
_handle = IntPtr.Zero;
}
_disposed = true;
}
}Finalization 的真实开销和替代方案
终结器不是免费的：每个带终结器的对象会额外占用约 24 字节（.NET 6+）用于跟踪信息；Finalizer 线程是单线程，高负载下成为瓶颈；而且无法预测执行时机，不适合做超时控制、资源及时归还等场景。
现代 C# 更推荐：
优先用IDisposable+
using语句显式释放 非托管资源封装用
SafeHandle子类（它自带可靠的终结逻辑，且支持
Dispose()抑制） 需要异步清理时，用
IAsyncDisposable而非依赖终结器 完全避免重写
Finalize()，除非你真的在写类似
SafeHandle的底层封装
GC 对终结器的处理机制本身很稳定，但滥用它带来的延迟、不可控性和调试难度，远超初学者预期。真正难的不是“怎么写终结器”，而是“怎么证明它根本不需要存在”。
