我不再重复关于使用或释放非托管资源的通常内容，这些内容已经全部介绍过了。但我想指出一个常见的误解。给定以下代码

Public Class LargeStuff
  Implements IDisposable
  Private _Large as string()

  'Some strange code that means _Large now contains several million long strings.

  Public Sub Dispose() Implements IDisposable.Dispose
    _Large=Nothing
  End Sub

我意识到一次性实现没有遵循当前的指导原则，但希望你们都能理解。现在，当调用Dispose时，释放了多少内存？答：没有。调用Dispose可以释放非托管资源，它不能回收托管内存，只有GC可以这样做。这并不是说上述模式不是一个好主意，事实上遵循上述模式仍然是一个好想法。一旦Dispose运行完毕，没有什么可以阻止GC重新声明_Large使用的内存，即使LargeStuff的实例可能仍在范围内。_Large中的字符串也可能在第0代，但LargeStuff的实例可能在第2代，因此，内存将很快被重新占用。但是，添加一个finalizer来调用上面显示的Dispose方法是没有意义的。这将延迟内存的重新声明，以允许终结器运行。

IDisposable通常用于利用using语句，并利用一种简单的方法对托管对象进行确定性清理。

public class LoggingContext : IDisposable {
    public Finicky(string name) {
        Log.Write("Entering Log Context {0}", name);
        Log.Indent();
    }
    public void Dispose() {
        Log.Outdent();
    }

    public static void Main() {
        Log.Write("Some initial stuff.");
        try {
            using(new LoggingContext()) {
                Log.Write("Some stuff inside the context.");
                throw new Exception();
            }
        } catch {
            Log.Write("Man, that was a heavy exception caught from inside a child logging context!");
        } finally {
            Log.Write("Some final stuff.");
        }
    }
}

在示例代码中，Dispose（）操作执行的某些操作可能会产生由于MyCollection对象的正常GC而不会发生的效果。

如果_theList或_theDict引用的对象被其他对象引用，那么List<>或Dictionary<>对象将不会被收集，而是突然没有内容。如果没有像示例中那样的Dispose（）操作，那么这些集合仍将包含其内容。

当然，如果是这种情况，我会称之为一个坏的设计——我只是指出（我想是迂腐的）Dispose（）操作可能不是完全冗余的，这取决于List＜＞或Dictionary＜＞是否有其他未在片段中显示的用途。

在您发布的示例中，它仍然没有“立即释放内存”。所有内存都是垃圾收集的，但它可能允许在早期版本中收集内存。你必须运行一些测试才能确定。

框架设计指南是指南，而不是规则。它们告诉你界面主要用于什么，何时使用，如何使用，以及何时不使用。

我曾经读过一段代码，它是一个利用IDisposable失败时的简单RollBack（）。下面的MiniTx类将检查Dispose（）上的一个标志，如果Commit调用从未发生，它将调用回滚。它添加了一层间接层，使调用代码更易于理解和维护。结果如下：

using( MiniTx tx = new MiniTx() )
{
    // code that might not work.

    tx.Commit();
} 

我也看到计时/日志代码做了同样的事情。在这种情况下，Dispose（）方法停止计时器并记录块已退出。

using( LogTimer log = new LogTimer("MyCategory", "Some message") )
{
    // code to time...
}

因此，这里有几个具体的示例，它们不执行任何非托管资源清理，但成功地使用IDisposable创建了更干净的代码。

大多数关于“非托管资源”的讨论的一个问题是，它们并没有真正定义这个术语，但似乎暗示它与非托管代码有关。虽然许多类型的非托管资源确实与非托管代码交互，但用这种术语来思考非托管资源是没有帮助的。

相反，我们应该认识到所有被管理的资源都有共同点：它们都包含一个对象，要求某个外部“事物”代表它做一些事情，而损害了其他一些“事物”，而另一个实体同意这样做，直到另行通知。如果物体被抛弃并消失得无影无踪，那么任何东西都不会告诉外部的“事物”，它不再需要代表不再存在的物体改变自己的行为；因此，“东西”的有用性将永久性地降低。

因此，非托管资源表示外部“事物”代表对象改变其行为的协议，如果对象被放弃并不再存在，这将毫无用处地损害外部“事物的有用性。被管理的资源是一个对象，它是此类协议的受益人，但如果它被放弃，它已签署接收通知，并将使用该通知在其被销毁之前整理其事务。

IDisposable适用于取消订阅事件。