什么时候在类上实现 IDispose 而不是析构函数？我读了this article，但我仍然没有抓住重点。
我的假设是，如果我在一个对象上实现 IDispose，我可以显式地“破坏”它，而不是等待垃圾收集器执行它。这是正确的吗？
这是否意味着我应该始终在对象上显式调用 Dispose？有哪些常见的例子？
【问题讨论】：
using 构造轻松做到这一点。
标签： c# .net dispose destructor
终结器（又名析构函数）是垃圾回收 (GC) 的一部分 - 它何时（或什至）发生这种情况是不确定的，因为 GC 主要是由于内存压力（即需要更多空间）而发生的。终结器通常仅用于清理非托管资源，因为托管资源将有自己的收集/处置。
因此IDisposable 用于确定地清理对象，即现在。它不收集对象的内存（仍然属于 GC） - 但用于关闭文件、数据库连接等。
这方面有很多以前的话题：
最后，请注意IDisposable 对象也有终结器的情况并不少见；在这种情况下，Dispose() 通常调用GC.SuppressFinalize(this)，这意味着 GC 不会运行终结器——它只是将内存扔掉（便宜得多）。如果您忘记Dispose() 对象，终结器仍会运行。
【讨论】：
Finalize() 方法的作用是确保 .NET 对象可以在垃圾收集时清理非托管资源。但是，应该尽快释放数据库连接或文件处理程序等对象，而不是依赖垃圾收集。为此，您应该实现IDisposable 接口，并在Dispose() 方法中释放您的资源。
【讨论】：
C# 析构函数中唯一应该包含的就是这一行：
Dispose(False);
就是这样。该方法中不应该有其他任何东西。
【讨论】：
MSDN上有很好的描述：
这个接口的主要用途是 释放非托管资源。 垃圾收集器自动 释放分配给 a 的内存 当该对象为 no 时的托管对象 使用时间更长。然而，不是 可以预测什么时候垃圾 收集将发生。此外， 垃圾收集器没有 非托管资源的知识 例如窗口句柄，或 open 文件和流。
使用这个的 Dispose 方法 显式释放的界面 非托管资源 与垃圾收集器。这 对象的消费者可以在对象不存在时调用该方法 需要更长的时间。
【讨论】：
您是否应该始终致电Dispose 的问题通常是一场激烈的辩论。请参阅 this 博客，了解 .NET 社区中受人尊敬的个人的有趣观点。
就我个人而言，我认为 Jeffrey Richter 的立场是，调用 Dispose 不是强制性的，这非常弱。他举了两个例子来证明他的观点。
在第一个示例中，他说在 Windows 窗体控件上调用 Dispose 在主流场景中是乏味且不必要的。但是他没有提到Dispose实际上是在那些主流场景中被控制容器自动调用的。
在第二个示例中，他指出开发人员可能错误地认为应该积极处置来自IAsyncResult.WaitHandle 的实例，而没有意识到该属性会延迟初始化等待句柄，从而导致不必要的性能损失。但是，这个例子的问题是IAsyncResult 本身不遵守微软自己发布的处理IDisposable 对象的准则。也就是说，如果一个类拥有对IDisposable 类型的引用，那么该类本身应该实现IDisposable。如果IAsyncResult 遵循该规则，那么它自己的Dispose 方法就可以决定需要处置哪些组成成员。
因此，除非有人有更令人信服的论点，否则我将留在“总是调用 Dispose”阵营，并理解将出现一些边缘案例，主要是由于糟糕的设计选择。
【讨论】：
真的很简单。我知道它已得到答复，但我会再试一次，但会尽量保持简单。
通常不应该使用析构函数。它只是运行.net 想要它运行。它只会在垃圾回收周期后运行。它可能永远不会在您的应用程序的生命周期中真正运行。出于这个原因，您不应该将任何代码放入“必须”运行的析构函数中。您也不能依赖类中的任何现有对象在运行时存在（它们可能已经被清理，因为不保证析构函数的运行顺序）。
只要您有一个创建需要清理的资源（即文件和图形句柄）的对象，就应该使用IDisposible。事实上，许多人认为，由于上述原因，您放入析构函数中的任何内容都应该放入 IDisposable。
大多数类会在终结器执行时调用 dispose ，但这只是作为安全防护，永远不应依赖。完成后，您应该明确处置任何实现 IDisposable 的东西。如果你确实实现了 IDisposable，你应该在终结器中调用 dispose。示例见http://msdn.microsoft.com/en-us/library/system.idisposable.aspx。
【讨论】：
这是另一篇很好的文章，它清除了 IDisposable、GC 和 dispose 周围的一些迷雾。
【讨论】：