最近我和同事就实现Dispose和实现IDisposable接口的类型的价值进行了讨论。
我认为对于应该尽快清理的类型，即使没有未受控资源需要清理，实现IDisposable也是有价值的。
我的同事持不同意见。他认为如果没有未受控资源，实现IDisposable是不必要的，因为您的类型最终会被垃圾回收。
我的观点是，如果您想尽快关闭ADO.NET连接，则实现IDisposable并使用using new MyThingWithAConnection()是有意义的。 我的同事回答说，在内部，ADO.NET连接是一个未受控资源。而我回复他的回答是最终所有东西都是未受控资源。
我知道有推荐的可释放模式，在这种模式下，如果调用Dispose，则释放托管和未托管资源，但只释放未受控资源如果通过终结器/destructor调用它（并且一段时间以前我在博客中分享了如何警告使用您的IDisposable类型的不当方式的消费者）。
那么，我的问题是，如果您有一个不包含未受控资源的类型，是否值得实现IDisposable？
IDisposable。一个简单的例子是持有打开的文件，你需要在某个时刻关闭它，只要你不再需要它了。当然，你可以提供一个方法Close，但在 Dispose内使用using (var f = new MyFile(path)) { /*process it*/ }这样的模式会更可靠避免异常。
一个更流行的例子是持有其他一些需要释放的IDisposable资源，这通常意味着您需要提供自己的Dispose以便将它们释放。
通常，只要您想要确定性地销毁任何东西，您就需要实现IDisposable。
我的观点与你的观点不同，在我看来只有当某种资源需要确定性的销毁/释放时，我才会实现IDisposable，而不是尽快实现。在这种情况下，依赖垃圾回收并不是一个选择（与你的同事的说法相反），因为它发生在不可预测的时间，并且实际上可能根本不会发生！
任何资源都是不受管理的事实并没有什么意义：开发人员应该考虑“何时以及如何释放此对象”而不是“它在底层如何工作”。底层实现可能随时间变化而改变。
事实上，C＃和C ++之间的主要区别之一是缺少默认的确定性销毁。 IDisposable填补了这个空缺：您可以命令确定性销毁（尽管您不能确保客户端调用它；同样，在C ++中，您无法确保客户端调用delete）。
小补充：确定性释放资源与尽快释放资源之间实际上有什么区别？ 实际上，这些是不同的（尽管并非完全正交的）概念。
如果要确定地释放资源，这意味着客户端代码应该有可能说“现在我想释放这个资源”。这实际上可能不是资源可以被释放的最早时间：持有资源的对象可能已经从资源中获取了所有需要的内容，因此它可能已经自行释放了该资源。另一方面，该对象可能选择保留（通常未受管理的）资源，即使在对象的Dispose方法运行后，只在终结器中清理它（如果长时间持有资源不会产生任何问题）。Dispose方法：一旦它自己意识到不再需要该资源，对象就可以立即释放该资源。然而，Dispose方法提供了一个有用的提示，即对象本身不再需要，因此如果合适的话，可能会在那时释放资源。
小小的补充：这里有一些巧妙地滥用IDisposable的示例列表：http://www.introtorx.com/Content/v1.0.10621.0/03_LifetimeManagement.html#IDisposable。
我认为最有帮助的是将IDisposable视为责任。 如果一个对象知道在它不再需要和宇宙结束之间（最好尽快），需要完成某些任务，并且如果它是唯一具有信息和动力的对象，则应该实现IDisposable。 例如，打开文件的对象有责任确保文件被关闭。 如果该对象消失而不关闭文件，则该文件可能在任何合理时间内都无法关闭。
重要的是要注意，即使仅与100％托管对象交互的对象也可能需要进行清理（并应使用IDisposable）。 例如，附加到集合的“修改”事件的IEnumerator将需要在不再需要时分离自身。 否则，除非枚举器使用一些复杂的技巧，否则只要集合在作用域内，枚举器就永远不会被垃圾回收。 如果集合被枚举一百万次，则会向其事件处理程序附加一百万个枚举器。
请注意，在某些情况下，可能可以在未调用Dispose的情况下使用终结器进行清理。 有时这很有效; 有时它会非常糟糕。 例如，即使Microsoft.VisualBasic.Collection使用终结器将枚举器从“修改”事件中分离，但在没有介入的Dispose或垃圾回收的情况下尝试多次枚举此类对象会使其变得非常缓慢-比正确使用Dispose导致的性能慢几个数量级。
IDisposable的另一个原因。 - Adam RobinsonIDisposable 不是因为它们期望将来的版本可能这样做，而是因为它们或基类型可能被用作工厂方法的返回类型，这些方法可能返回需要清理的派生类型。例如，所有实现 IEnumerator<T> 的类型都实现了 IDisposable，即使它们的绝大多数 Dispose 方法什么也不做。 - supercatIDisposable的原因之一。例如，IObservable<T>.Subscribe返回一个IDisposable，即使它不是用于封装非托管资源或在using块中使用。 - GabeIObservable<T>，如果您能添加一些内容可能会更好。 - Adam RobinsonIDisposable应该有一些澄清。重要的是，在最后一个对IDisposable的引用被销毁之前（因为在此之后无法调用），必须调用Dispose。另一方面，许多对象通常持有对IDisposable的引用；通常只有一个对象应该调用Dispose。 - supercatIDisposable，都应该有一个“所有者”，负责确保适当地调用Dispose。 - Adam RobinsonIDisposable的给定类是否需要进行清理。我的经验法则是始终对我不太了解的对象调用Dispose，例如某些第三方库。DisposeRequired 属性，找出是否需要调用 Dispose 的时间（稍微）超过了无条件调用 Dispose 的时间 [因为它必须对属性进行虚拟调用，然后根据结果进行分支，而不是简单地进行虚拟调用]。只有在确定何时调用 Dispose 比实际调用 Dispose 更繁琐时（例如，如果需要对需要清理的对象进行“用户计数”，但不需要对不需要清理的对象进行计数），DisposeRequired 才会有帮助。 - supercatDispose 应该用于任何具有 有限生命周期 的资源。对于任何非托管资源，都应该使用 finalizer。任何非托管资源都应该有一个有限的生命周期，但是还有很多托管资源（如锁）也具有有限的生命周期。
一切最终都是未受管理的资源。
不是真的。除了CLR对象使用的内存，这些内存只由框架进行管理（分配和释放）。
实现IDisposable并在一个不持有任何未受管理资源的对象上调用Dispose（直接或间接通过依赖对象），是毫无意义的。这并不能使释放该对象变得确定性，因为你不能直接自己释放对象的CLR内存，因为它总是只有GC才能做到。对象是引用类型，因为值类型，在方法级别直接使用时，是通过堆栈操作进行分配/释放的。
现在，每个人都声称自己的答案是正确的。让我来证明我的观点。根据文档:
换句话说，对象的CLR内存在调用Object.Finalize方法允许对象在被垃圾回收器回收之前尝试释放资源和执行其他清理操作。
Object.Finalize()后立即释放。[注意：如果需要，可以明确跳过此调用]internal class Class1 : IDisposable
{
public Class1()
{
Console.WriteLine("Construct");
}
public void Dispose()
{
Console.WriteLine("Dispose");
}
~Class1()
{
Console.WriteLine("Destruct");
}
}
Finalize，直到Object.Finalize()。Main方法：static void Main(string[] args)
{
for (int i = 0; i < 10; i++)
{
Class1 obj = new Class1();
obj.Dispose();
}
Console.ReadKey();
}
using (WindowsImpersonationContext context = SomeUserIdentity.Impersonate()))
{
// do something as SomeUser
}
// back to your user
WindowsImpersonationContext在内部使用系统句柄，但你可以理解意思。IDisposable时，你需要在Dispose方法中有（或计划有）一些有意义的事情要做。否则，这只是浪费时间。 IDisposable不会改变GC管理对象的方式。Dispose。换句话说，如果任何依赖对象实现了Dispose，你的对象也应该实现。如果没有表述清楚，我很抱歉。 - MaciejIDisposable 以 RAII-way 的方式获取此权限是一件好事：using (ObtainModifyRight(collection)) { /* modify it */ }。 - Vladusing关键字的存在而变得更加方便。更新答案。 - MaciejIDisposable，则应实现该接口，以便这些成员及时清理。否则，在您引用的ADO.Net连接示例中，myConn.Dispose()如何被调用呢？但在这种情况下，我认为不正确地说所有内容都是无管理资源。我也不同意您的同事的观点。你说得对。管理的数据库连接、文件、注册表键、套接字等都持有未托管对象。这就是为什么它们实现了IDisposable接口。如果你的类型拥有可释放的对象，你应该实现IDisposable并在你的Dispose方法中释放它们。否则它们可能会一直存活，直到垃圾回收导致锁定文件和其他意外行为。
IDisposable，因为资源是托管的。但我的观点是，你必须这样做，因为在任何IDisposable对象内部都有一个非托管的资源。当你聚合IDisposable对象时，你也必须实现IDisposable。 - Martin LiversageIDisposable - OP似乎认为即使没有未经管理的资源需要清理，实现IDisposable也有价值。 - BlueRaja - Danny Pflughoeft
IDisposable的唯一另一个场合，是在处理非托管资源之外，当我需要确保事件被正确取消订阅以便类可以被垃圾回收时。但这实际上是语言的缺陷：事件真的真的 非常 需要弱引用，但它们并没有。 - BlueRaja - Danny Pflughoeft