如果某对象的 Dispose 方法被调用一次以上，则该对象必须忽略第一次调用后的所有调用。 如果对象的 Dispose 方法被多次调用，该对象一定不要引发异常。 除Dispose 之外的实例方法在资源已释放时会引发 。

用户可能期望资源类型使用特定的约定来表示已分配状态和已释放状态。流类即是这样一种示例，传统上认为它们要么打开要么关闭。具有此种约定的类的实施者可能选择实现具有自定义名称（如“Close”）的公用方法来调用 Dispose 方法。

因为 Dispose 方法必须显式进行调用，所以，实现  的对象还必须实现一个终结器，以便在未调用 Dispose 时处理释放资源问题。 默认情况下，垃圾回收器会在回收一个对象的内存之前自动调用该对象的终结器。然而，在调用 Dispose 方法后，通常不需要垃圾回收器调用已释放对象的终结器。 为防止自动终止，Dispose 实现可以调用 方法。

强制垃圾回收

.NET Framework 2.0

 　　

垃圾回收 

提供 

，您可以使用该方法让应用程序在一定程度上直接控制垃圾回收器。通常情况下，您应该避免调用任何回收方法，让垃圾回收器独立运行。在大多数情况下，垃圾回收器在确定执行回收的最佳时机方面更有优势。但是，在某些不常发生的情况下，强制回收可以提高应用程序的性能。当应用程序代码中某个确定的点上使用的内存量大量减少时，在这种情况下使用 

GC.Collect

 方法可能比较合适。例如，应用程序可能使用引用大量非托管资源的文档。当您的应用程序关闭该文档时，您完全知道已经不再需要文档曾使用的资源了。出于性能的原因，一次全部释放这些资源很有意义。有关更多信息，请参见 

。

　　在垃圾回收器执行回收之前，它会挂起当前正在执行的所有线程。如果不必要地多次调用 GC.Collect，这可能会造成性能问题。您还应该注意不要将调用 GC.Collect 的代码放置在程序中用户可以经常调用的点上。这可能会削弱垃圾回收器中优化引擎的作用，而垃圾回收器可以确定运行垃圾回收的最佳时间。

被动回收

.NET Framework 4

　　在大多数情况下，垃圾回收器可以确定执行回收的最佳时间，应让其独立运行。 

在某些不常发生的情况下，强制回收可以提高应用程序的性能。 在这些情况下，可使用  方法强制垃圾回收，以引发垃圾回收。

　　当应用程序代码中某个确定的点上使用的内存量大量减少时，请使用  方法。 例如，如果应用程序使用包含若干个控件的复杂对话框，则在对话框关闭时调用  可能会通过立即回收内存来提高性能。 务必确保应用程序不会过于频繁地引发垃圾回收，否则当垃圾回收器无效率地尝试回收对象时，可能会使性能降低。  模式使垃圾回收器可以根据收集是否有效率来确定是否进行回收。