“Dispose”是否应该只用于包含非托管资源的类型？

IDisposable 有不同的有效用途。一个简单的例子是持有一个打开的文件，当您不再需要它时，您需要在某个时刻将其关闭。当然，您可以提供一个方法 Close，但将它放在 Dispose 中并使用像 using (var f = new MyFile(path)) { /*process it*/ } 这样的模式会更安全。

一个更流行的示例是持有一些其他 IDisposable 资源，这通常意味着您需要提供自己的 Dispose 才能处置它们。

一般来说，只要您想对任何事物进行确定性销毁，就需要实施 IDisposable。

我的观点和你的不同之处在于，我在某些资源需要确定性 销毁/释放时立即实施 IDisposable，而不是尽快。在这种情况下，依靠垃圾收集不是一种选择（与您同事的说法相反），因为它发生在不可预测的时刻，实际上可能根本不会发生！

任何资源在后台不受管理的事实并不意味着什么：开发人员应该考虑“何时以及如何处理该对象是正确的”，而不是“它如何在后台工作”。无论如何，底层实现可能会随着时间而改变。

事实上，C# 和 C++ 之间的主要区别之一是没有默认的确定性破坏。 IDisposable 缩小了差距：您可以订购确定性销毁（尽管您无法确保客户端正在调用它；在 C++ 中您无法确定客户端是否在对象上调用 delete）。

小补充：确定性释放资源和尽快释放它们之间实际上有什么区别？实际上，这些是不同的（尽管不是完全正交的）概念。

如果要确定地释放资源，这意味着客户端代码应该有可能说“现在，我想释放这个资源”。这实际上可能不是释放资源的可能的最早时刻：持有资源的对象可能已经从资源中获得了它需要的一切，因此它可能已经释放了资源。另一方面，即使在对象的 Dispose 运行后，对象也可能选择保留（通常是非托管的）资源，仅在终结器中清理它（如果持有资源太长时间不会产生任何问题）。

因此，为了尽快释放资源，严格来说，Dispose 是不必要的：对象一旦意识到自己不再需要该资源，就可以释放该资源。但是，Dispose 提供了一个有用的提示，即不再需要对象本身，因此如果合适的话，资源可能会在此时被释放。

另一个必要的补充：不仅非托管资源需要确定性释放！这似乎是这个问题的答案中意见分歧的关键点之一。一个人可以有纯粹的想象结构，这可能需要确定性地释放。

例如：访问某些共享结构的权利（想想 RW-lock）、巨大的内存块（想象您正在手动管理程序的一些内存）、使用其他程序的许可（想象您不被允许同时运行多个X个程序的副本）等等。这里要释放的对象不是非托管资源，而是权利做/使用某事，这是程序逻辑的纯粹内部构造。

小补充：这里有一小部分 [ab] 使用 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？

当有人在对象上放置 IDisposable 接口时，这告诉我创建者打算在该方法中做某事，或者将来他们可能打算这样做。为了确定，我总是在这种情况下调用 dispose 。即使它现在不做任何事情，但它可能在未来做任何事情，并且因为他们更新了一个对象而导致内存泄漏很糟糕，而且您在第一次编写代码时没有调用 Dispose。

事实上，这是一个判断电话。你不想过度实现它，因为在那个时候为什么还要麻烦有一个垃圾收集器。为什么不手动处理每个对象。如果您有可能需要处置非托管资源，那么这可能不是一个坏主意。这一切都取决于，如果唯一使用您的对象的人是您团队中的人，您可以随时跟进他们并说，“嘿，现在需要使用非托管资源。我们必须检查代码并确保我们已经收拾好了。”如果您将其发布以供其他组织使用，那就不同了。没有简单的方法可以告诉可能已经实现该对象的每个人，“嘿，您需要确保它现在已被处置。”让我告诉你，没有什么比升级第三方程序集更让人发疯的事情了，因为他们更改了他们的代码并让你的应用程序出现了内存问题。

我的同事回答说，在幕后，ADO.NET 连接是一种托管资源。我对他的答复是，一切最终都是非托管资源。

他是对的，它现在是一个托管资源。他们会改变它吗？谁知道呢，但打电话给它也无妨。我不会尝试猜测 ADO.NET 团队做了什么，所以如果他们把它放进去但它什么也没做，那很好。我还是会这样称呼它，因为一行代码不会影响我的工作效率。

您还遇到了另一种情况。假设您从一个方法返回一个 ADO.NET 连接。您不知道 ADO 连接是基础对象还是派生类型。您不知道 IDisposable 实现是否突然变得必要。无论如何，我总是这样称呼它，因为在生产服务器每 4 小时崩溃一次时，跟踪内存泄漏是很糟糕的。

---

虽然已经有了很好的答案，但我只是想明确一点。

实现 IDisposable 的三种情况：

您正在直接使用非托管资源。这通常涉及从必须由不同的 P/Invoke 调用释放的 P/Invoke 调用中检索 IntPrt 或某种其他形式的句柄 您正在使用其他 IDisposable 对象并且需要对它们的处置负责 您还有其他一些需要或使用它，包括使用块的便利性。

虽然我可能有点偏见，但您确实应该阅读（并向您的同事展示）the StackOverflow Wiki on IDisposable。

---

Dispose 应该用于任何具有有限生命周期的资源。终结器应该用于任何非托管资源。任何非托管资源都应该有一个有限的生命周期，但是有很多托管资源（如锁）也有有限的生命周期。

---

请注意，非托管资源很可能包括标准 CLR 对象，例如保存在某些静态字段中的对象，它们都在安全模式下运行，根本没有非托管导入。

没有简单的方法可以判断实现 IDiposable 的给定类是否确实需要清理某些内容。我的经验法则是总是对我不太了解的对象调用 Dispose，比如一些 3rd 方库。

---

不，它不仅适用于非托管资源。

建议它像框架调用的基本清理内置机制一样，使您可以清理您想要的任何资源，但最适合自然是非托管资源管理。

---

如果您聚合 IDisposable，那么您应该实现接口，以便及时清理这些成员。在您引用的 ADO.Net 连接示例中如何调用 myConn.Dispose()？

我认为在这种情况下说一切都是非托管资源是不正确的。我也不同意你同事的观点。

---

你说的对。托管数据库连接、文件、注册表项、套接字等都保留在非托管对象上。这就是他们实施 IDisposable 的原因。如果您的类型拥有一次性对象，您应该实现 IDisposable 并在您的 Dispose 方法中处理它们。否则，它们可能会一直存活，直到垃圾收集导致锁定文件和其他意外行为。

---

一切最终都是非托管资源。

不对。除了仅由框架管理（分配和释放）的 CLR 对象使用的内存之外的所有内容。

在不持有任何非托管资源的对象上实现 IDisposable 和调用 Dispose（直接或通过依赖对象间接）毫无意义。它确实不会使释放该对象确定性，因为您不能自己直接释放对象的 CLR 内存，因为它总是只有 GC这样做。对象是引用类型，因为值类型在方法级别直接使用时，由堆栈操作分配/释放。

现在，每个人都声称自己的答案是正确的。让我证明我的。根据documentation：

Object.Finalize 方法允许对象在被垃圾回收器回收之前尝试释放资源并执行其他清理操作。

换句话说，对象的 CLR 内存在 Object.Finalize() 被调用后立即被释放。 [注意：如果需要，可以显式跳过此调用]

这是一个没有非托管资源的一次性类：

internal class Class1 : IDisposable
{
    public Class1()
    {
        Console.WriteLine("Construct");
    }

    public void Dispose()
    {
        Console.WriteLine("Dispose");
    }

    ~Class1()
    {
        Console.WriteLine("Destruct");
    }
}

请注意，destructor 隐式调用继承链中的每个 Finalize 直到 Object.Finalize()

这是控制台应用程序的 Main 方法：

static void Main(string[] args)
{
    for (int i = 0; i < 10; i++)
    {
        Class1 obj = new Class1();
        obj.Dispose();
    }

    Console.ReadKey();
}

如果调用 Dispose 是一种以确定性方式释放 托管 对象的方法，那么每次“Dispose”都会紧跟“Destruct”，对吗？亲眼看看会发生什么。从命令行窗口运行这个应用程序是最有趣的。

注意：有一种方法可以强制 GC 收集当前应用程序域中等待完成的所有对象，但不收集单个特定对象。不过，您无需调用 Dispose 即可在完成队列中拥有一个对象。强烈建议不要强制收集，因为它可能会损害整体应用程序性能。

编辑

有一个例外——状态管理。如果您的对象碰巧管理外部状态，Dispose 可以处理状态更改。即使 state 不是非托管对象，由于 IDisposable 的特殊处理，使用它也非常方便。示例是安全上下文或模拟上下文。

using (WindowsImpersonationContext context = SomeUserIdentity.Impersonate()))
{
    // do something as SomeUser
}

// back to your user

这不是最好的例子，因为 WindowsImpersonationContext 在内部使用系统句柄，但你明白了。

底线是，在实现 IDisposable 时，您需要（或计划）在 Dispose 方法中做一些有意义的事情。否则只是浪费时间。 IDisposable 不会改变 GC 管理对象的方式。

---

如果你的类型引用了非托管资源或者它持有对实现 IDisposable 的对象的引用，则你的类型应该实现 IDisposable。

---

在我的一个项目中，我有一个内部包含托管线程的类，我们将它们称为线程 A 和线程 B，以及一个 IDisposable 对象，我们将其称为 C。

A 用于在退出时处理 C。 B 曾经使用 C 来保存异常。

我的班级必须实现 IDisposable 和 decrtuctor 以确保以正确的顺序处理事物。是的，GC 可以清理我的物品，但我的经验是除非我管理好班级的清理工作，否则会出现竞争状况。

---

简短的回答：绝对不是。如果您的类型具有托管或非托管成员，则应实现 IDisposable。

现在详细信息：我已经回答了这个问题，并在 StackOverflow 上提供了有关内存管理内部和 GC 问题的更多详细信息。这里仅仅是少数：

依赖 .NET 自动垃圾收集器是不好的做法吗？

如果我不对笔对象调用 Dispose 会发生什么？

Dispose，什么时候调用？

至于 IDisposable 实现的最佳实践，请参考我的博文：

How do you properly implement the IDisposable pattern?

---

如果对象拥有任何非托管对象或任何托管一次性对象，则实施 IDisposable

如果一个对象使用非托管资源，它应该实现 IDisposable。拥有一次性对象的对象应实现 IDisposable 以确保释放底层非托管资源。如果遵循规则/约定，因此可以得出结论，不释放托管的一次性对象等于不释放非托管资源是合乎逻辑的。

---

根本不需要资源（托管或非托管）。通常，IDisposable 只是一种方便 消除繁琐 try {..} finally {..} 的方式，只需比较一下：

  Cursor savedCursor = Cursor.Current;

  try {
    Cursor.Current = Cursors.WaitCursor;

    SomeLongOperation();
  }
  finally {
    Cursor.Current = savedCursor;
  }

和

  using (new WaitCursor()) {
    SomeLongOperation();
  }

其中 WaitCursor 是 IDisposable 适用于 using：

  public sealed class WaitCursor: IDisposable {
    private Cursor m_Saved;

    public Boolean Disposed {
      get;
      private set;
    }

    public WaitCursor() {
      Cursor m_Saved = Cursor.Current;
      Cursor.Current = Cursors.WaitCursor;
    }

    public void Dispose() {
      if (!Disposed) {
        Disposed = true;
        Cursor.Current = m_Saved;
      }
    }
  }

您可以轻松地组合这些类：

  using (new WaitCursor()) {
    using (new RegisterServerLongOperation("My Long DB Operation")) {
      SomeLongRdbmsOperation();  
    }

    SomeLongOperation();
  }

---