处置托管资源最合理的用例是为GC回收资源做准备，否则这些资源将永远不会被收集。

一个主要的例子是循环引用。

虽然使用避免循环引用的模式是最佳做法，但如果您最终（例如）得到了一个“子”对象，该对象的引用返回到其“父”，那么如果您只是放弃引用并依赖GC，则这可能会停止父对象的GC收集，而且如果您实现了终结器，则永远不会调用它。

解决此问题的唯一方法是通过将子级上的Parent引用设置为null来手动打破循环引用。

在父母和孩子身上实现IDisposable是实现这一点的最佳方式。当对父级调用Dispose时，对所有子级调用Disposit，并在子级Dispose方法中，将父级引用设置为null。

我使用IDisposable的场景：清理非托管资源、取消订阅事件、关闭连接

我用于实现IDisposable（非线程安全）的习惯用法：

class MyClass : IDisposable {
    // ...

    #region IDisposable Members and Helpers
    private bool disposed = false;

    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing) {
        if (!this.disposed) {
            if (disposing) {
                // cleanup code goes here
            }
            disposed = true;
        }
    }

    ~MyClass() {
        Dispose(false);
    }
    #endregion
}

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

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

我曾经读过一段代码，它是一个利用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创建了更干净的代码。

如果MyCollection无论如何都将被垃圾收集，那么您不需要对其进行处理。这样做只会过度消耗CPU，甚至可能使垃圾收集器已经执行的一些预先计算的分析无效。

我使用IDisposable来执行诸如确保线程以及非托管资源被正确处理之类的操作。

编辑回应斯科特的评论：

GC性能指标唯一受到影响的时间是调用〔sic〕GC.Collect（）时“

从概念上讲，GC维护对象引用图的视图，以及线程堆栈帧中对它的所有引用。这个堆可能非常大，并跨越许多页面的内存。作为优化，GC缓存对不太可能经常更改的页面的分析，以避免不必要地重新扫描页面。当页面中的数据发生更改时，GC从内核接收通知，因此它知道页面已脏，需要重新扫描。如果集合在Gen0中，那么页面中的其他内容也可能发生变化，但在Gen1和Gen2中这种情况发生的可能性较小。有趣的是，对于将GC移植到Mac以使Silverlight插件在该平台上工作的团队来说，这些钩子在Mac OS X中不可用。

反对不必要的资源处置的另一点是：想象一个进程正在卸载的情况。想象一下，这个过程已经运行了一段时间。很可能该进程的许多内存页已被交换到磁盘。至少它们不再位于L1或L2缓存中。在这种情况下，正在卸载的应用程序没有必要将所有数据和代码页交换回内存，以“释放”进程终止时操作系统无论如何都会释放的资源。这适用于托管资源，甚至某些非托管资源。只有使非后台线程保持活动状态的资源才能被释放，否则进程将保持活动状态。

现在，在正常执行期间，必须正确清理临时资源（正如@fezmonkey指出的数据库连接、套接字和窗口句柄），以避免非托管内存泄漏。这些都是必须处理的事情。如果您创建了一个拥有线程的类（我的意思是它创建了线程，因此负责确保它停止，至少按照我的编码风格），那么该类很可能必须实现IDisposable，并在Dispose期间拆除线程。

.NET框架使用IDisposable接口作为开发人员必须释放此类的信号，甚至是警告。我想不出框架中实现IDisposable的任何类型（不包括显式接口实现），其中处置是可选的。

IDisposable/using组合除了主要用作控制系统资源生命周期的方法（完全被Ian的精彩回答所涵盖）外，还可以用于确定（关键）全局资源的状态变化范围：控制台、线程、进程、任何全局对象（如应用程序实例）。

我写了一篇关于这种模式的文章：http://pragmateek.com/c-scope-your-global-state-changes-with-idisposable-and-the-using-statement/

它说明了如何以可重用和可读的方式保护一些常用的全局状态：控制台颜色、当前线程区域性、Excel应用程序对象财产。。。

如果有的话，我希望代码的效率比不使用它时要低。

调用Clear（）方法是不必要的，如果Dispose不这样做，GC可能不会这么做。。。