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

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接口或使用对dll的调用创建的东西。GC不知道如何处理此类对象。例如，如果类只有值类型，那么我不认为这个类是具有非托管资源的类。对于我的代码，我遵循以下实践：

如果由我创建的类使用一些非托管资源，那么这意味着我还应该实现IDisposable接口以清理内存。使用完后立即清理对象。在dispose方法中，我遍历类的所有IDisposable成员并调用dispose。在Dispose方法中，调用GC.SuppressFinalize（this），以通知垃圾收集器我的对象已被清理。我这样做是因为调用GC是一项昂贵的操作。作为额外的预防措施，我尝试多次调用Dispose（）。有时我添加私有成员_disposed并签入方法调用，但对象被清理了。如果已清理，则生成ObjectDisposedException以下模板演示了我用文字描述的代码示例：

公共类SomeClass:IDisposable{///<summary>///像往常一样，我不在乎对象是否被处理///</summary>public void SomeMethod（）{如果（_disposed）引发新的ObjectDisposedException（“已释放SomeClass实例”）；}public void Dispose（）{Dispose（真）；}私有bool _disposed；受保护的虚拟void Dispose（bool dispositing）{如果（_disposed）回来如果（处置）//我们在第一次通话中{}_已处理=真；}}

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

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

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

我使用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。我认为这篇文章是我找到的关于如何实际使用IDisposable的最佳解释之一。

https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About

对于实际问题；如果您使用IDisposable清理占用大量内存的托管对象，简短的答案是否定的。原因是，一旦持有内存的对象超出范围，它就可以进行收集了。此时，任何引用的子对象也超出范围，将被收集。

唯一真正的例外是，如果托管对象中占用了大量内存，并且您已经阻止了该线程等待某个操作完成。如果在调用完成后不需要这些对象，那么将这些引用设置为null可能会让垃圾收集器更快地收集它们。但那个场景将代表需要重构的坏代码——而不是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的任何类型（不包括显式接口实现），其中处置是可选的。