C#垃圾回收器：Destructor与IDisposable哪个调用更可靠？

实现IDisposable能否保证GC调用.Dispose()？ #

不能。CLR的GC仅负责回收托管内存，不会主动调用任何对象的.Dispose()方法。Dispose是为开发者手动调用（或配合using块自动调用）设计的，GC完全不会识别或触发这个方法。

析构函数（~ClassName）为啥不总能被调用？ #

CLR的终结机制本身就是不确定的：

• 带有析构函数的对象会被GC放入「终结队列」，由专门的终结线程异步执行析构逻辑，这个过程的触发时机完全由GC调度决定，可能很久才执行，甚至程序退出前都没机会运行。
• 如果进程被强制终止（比如崩溃、任务管理器强制结束），GC根本来不及处理终结队列里的内容，析构自然不会执行。
• 复杂的对象引用关系（比如循环引用）可能导致对象长期无法被回收，析构也就永远不会触发。

可靠释放资源的最佳实践（针对无法使用using的场景） #

1. 实现标准IDisposable模式 #

这是.NET处理资源释放的核心规范，既支持手动主动释放，又能通过终结器做兜底。示例代码：

public class ResourceHolder : IDisposable
{
    // 标记资源是否已释放，避免重复操作
    private bool _disposed = false;

    // 供外部手动调用的Dispose方法
    public void Dispose()
    {
        Dispose(true);
        // 告知GC无需再执行终结器，避免重复释放资源
        GC.SuppressFinalize(this);
    }

    // 核心释放逻辑，通过disposing参数区分「手动调用」和「GC终结」场景
    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;

        if (disposing)
        {
            // 释放托管资源（比如其他实现IDisposable的对象）
            // 此时对象处于可用状态，可安全访问托管成员
            _managedResource?.Dispose();
        }

        // 释放非托管资源（比如文件句柄、原生指针等）
        ReleaseUnmanagedResource();

        _disposed = true;
    }

    // 终结器：作为最后兜底，仅处理非托管资源
    ~ResourceHolder()
    {
        Dispose(false);
    }

    private void ReleaseUnmanagedResource()
    {
        // 实际释放非托管资源的逻辑
    }
}

2. 用try/finally手动模拟using逻辑 #

虽然不能用using，但可以手动实现类似的保障，确保对象不再使用时一定会触发释放：

var holder = new ResourceHolder();
try
{
    // 执行业务逻辑，使用holder对象
}
finally
{
    // 无论是否发生异常，都确保调用Dispose释放资源
    holder.Dispose();
}

3. 终结器仅做兜底，绝不依赖它 #

终结器是防止开发者遗漏手动Dispose的最后防线，但绝对不能把关键业务逻辑放在里面——它的执行时机不可控，甚至可能永远不执行。只在终结器中处理非托管资源，不要访问任何托管对象（因为此时它们可能已经被GC回收）。

4. 长期存活对象的特殊处理 #

如果是单例、静态对象这类长期存在的实例，要在程序退出前主动触发资源释放：

• 注册AppDomain.CurrentDomain.ProcessExit事件，在进程退出时调用Dispose。
• 或者在业务逻辑的收尾阶段（比如服务停止、模块卸载时）手动调用释放方法。

内容的提问来源于stack exchange，提问作者Katie Green