仅针对托管资源的最小 IDisposable 实现

Question

关于处置非托管资源的“标准完整”IDisposable 实现有很多信息 - 但实际上这种情况（非常）罕见（大多数资源已经被托管类包装）。这个问题的重点是 IDisposable 的最小实现，用于更常见的“仅托管资源”情况。

1：下面代码中IDisposable的最小实现是否正确，有问题吗？

2：是否有任何理由添加完整的标准IDisposable 实现（Dispose()、Dispose(bool)、Finalizer 等）而不是提供的最小实现？

3：在这种最小情况下，将Dispose 设为虚拟是否可行/明智（因为我们不提供Dispose(bool)）？

4：如果这个最小实现被包含（在这种情况下无用的）终结器的完整标准实现替换 - 这会改变 GC 处理对象的方式吗？有什么缺点吗？

5：该示例包括 Timer 和事件处理程序，因为这些情况特别重要，不要错过，因为未能处理它们将使对象保持活动状态（Timer 的情况下为this，eventSource 在事件处理程序的情况），直到 GC 及时处理它们。还有其他类似的例子吗？

class A : IDisposable {
    private Timer timer;
    public A(MyEventSource eventSource) {
        eventSource += Handler
    }

    private void Handler(object source, EventArgs args) { ... }

    public virtual void Dispose() {
        timer.Dispose();
        if (eventSource != null)
           eventSource -= Handler;
    }
}

class B : A, IDisposable {
    private TcpClient tpcClient;

    public override void Dispose() {
        (tcpClient as IDispose).Dispose();
        base.Dispose();
    }   
}

参考：
MSDN
SO: When do I need to manage managed resources
SO: How to dispose managed resource in Dispose() method in C#
SO: Dispose() for cleaning up managed resources

Answer 1

1. 实现是正确的，没有问题，前提是没有派生类直接拥有非托管资源。

2. 实施完整模式的一个很好的理由是“最小意外原则”。由于 MSDN 中没有描述这种更简单模式的权威文档，因此维护开发人员可能会有疑问 - 甚至您觉得有必要询问 StackOverflow :)

3. 是的，在这种情况下，Dispose 可以是虚拟的。

4. 如果 Dispose 已被调用并且被正确实现（即调用 GC.SuppressFinalize），则不必要的终结器的开销可以忽略不计

.NET Framework 本身之外的绝大多数IDisposable 类是IDisposable，因为它们拥有托管的IDisposable 资源。他们很少直接持有非托管资源 - 这只发生在使用 P/Invoke 访问未由 .NET Framework 公开的非托管资源时。

因此，推广这种更简单的模式可能有一个很好的论据：

• 在使用非托管资源的极少数情况下，应将它们包装在实现终结器的密封 IDisposable 包装类中（如 SafeHandle）。因为它是密封的，所以这个类不需要完整的 IDisposable 模式。

• 在所有其他情况下，绝大多数情况下，都可以使用您更简单的模式。

但除非并且直到微软或其他权威来源积极推广它，否则我将继续使用完整的IDisposable 模式。

Answer 2

另一种选择是重构您的代码以避免继承并使您的IDisposable 类密封。然后更简单的模式很容易证明是正确的，因为不再需要支持可能的继承的笨拙的旋转。我个人大部分时间都采用这种方法。在极少数情况下，我想让非密封类一次性使用，我只是遵循“标准”模式。培养这种方法的一个好处是它倾向于将您推向组合而不是继承，这通常使代码更易于维护和测试。

Answer 3

我推荐的Dispose 模式是用于将非虚拟Dispose 实现链接到虚拟void Dispose(bool)，最好是在以下内容之后：

int _disposed;
public bool Disposed { return _disposed != 0; }
void Dispose()
{
  if (System.Threading.Interlocked.Exchange(ref _disposed, 1) != 0)
    Dispose(true);
  GC.SuppressFinalize(this); // In case our object holds references to *managed* resources
}

使用这种方法将确保Dispose(bool) 只被调用一次，即使多个线程尝试同时调用它。虽然这种同时处理的尝试很少见（*），但防范它们的成本很低；如果基类不执行上述操作，则每个派生类都必须有自己的冗余双重处置保护逻辑，并且可能还有一个冗余标志。

(*) 一些主要是单线程并使用阻塞 I/O 的通信类允许从任何线程上下文调用 Dispose 以取消阻塞其自己线程的 I/O 操作 [显然是 Dispose不能在该线程上调用，因为该线程在被阻塞时无法执行任何操作]。对于此类对象或封装它们的对象，完全有可能（而且并非不合理）让外部线程尝试Dispose 它们作为在它们将被处理的那一刻中止它们当前操作的一种手段他们的主线。同时Dispose 调用可能很少见，但它们的可能性并不表示任何“设计问题”，前提是Dispose 代码可以对一个调用起作用而忽略另一个。