Finalizer Queue 是 GC 维护的带标记对象链表，非传统队列；对象在首次 GC 不可达且含终结器时加入，导致至少延迟一个 GC 周期回收，易因 Finalizer 线程阻塞或异常引发内存泄漏。
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); // ← 这行必须有，且只在这里写一次
}
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 对终结器的处理机制本身很稳定，但滥用它带来的延迟、不可控性和调试难度，远超初学者预期。真正难的不是“怎么写终结器”，而是“怎么证明它根本不需要存在”。
