正确使用 IDisposable 接口

通过阅读Microsoft 文档 ,我知道IDisposable接口的 “主要” 用途是清理非托管资源。

对我来说,“非托管” 意味着诸如数据库连接,套接字,窗口句柄之类的东西。但是,我已经看到了在其中实现Dispose()方法以释放托管资源的代码,这对我来说似乎是多余的,因为垃圾收集器应该照顾好你

例如:

public class MyCollection : IDisposable
{
    private List<String> _theList = new List<String>();
    private Dictionary<String, Point> _theDict = new Dictionary<String, Point>();

    // Die, clear it up! (free unmanaged resources)
    public void Dispose()
    {
        _theList.clear();
        _theDict.clear();
        _theList = null;
        _theDict = null;
    }

我的问题是,这是否会使MyCollection使用的垃圾收集器释放内存的速度比正常情况更快?

编辑 :到目前为止,人们已经发布了一些使用 IDisposable 清除数据库,连接和位图等非托管资源的良好示例。但是假设_theList在上面的代码中包含上百万字符串,你想现在就释放内存,而不是等待垃圾回收器。上面的代码能做到吗?

答案

处置的重点释放非托管资源。它需要在某个时候完成,否则它们将永远不会被清除。垃圾收集器不知道如何IntPtr类型的变量上调用DeleteHandle() ,也不知道是否需要调用DeleteHandle()

注意 :什么是非托管资源 ?如果您在 Microsoft .NET Framework 中找到它:它是受管理的。如果您自己去逛 MSDN,那它是不受管理的。您使用 P / Invoke 调用进入. NET Framework 中所有可用内容的舒适环境都是不受管理的 - 现在您要负责清理它。

您创建的对象需要公开一些外界可以调用的方法,以清理非托管资源。该方法可以命名为任意名称:

public void Cleanup()

要么

public void Shutdown()

但是,此方法有一个标准化名称:

public void Dispose()

甚至创建了一个接口IDisposable ,它只有一个方法:

public interface IDisposable
{
   void Dispose()
}

因此,使您的对象公开IDisposable接口,并以此方式保证已编写该单一方法来清理非托管资源:

public void Dispose()
{
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);
}

这样就完成了。 除了可以做得更好。


如果您的对象已将 250MB System.Drawing.Bitmap (即. NET 托管的 Bitmap 类)分配为某种帧缓冲区怎么办?当然,这是一个托管的. NET 对象,垃圾收集器将释放它。但是,您是否真的要保留 250MB 的内存,等待垃圾收集器最终释放出来并释放它呢?如果有开放的数据库连接怎么办?当然,我们不希望该连接处于打开状态,而是等待 GC 最终确定对象。

如果用户调用了Dispose() (意味着他们不再打算使用该对象),为什么不摆脱那些浪费的位图和数据库连接呢?

所以现在我们将:

  • 摆脱非托管资源(因为我们必须这样做),并且
  • 摆脱托管资源(因为我们希望有所帮助)

因此,让我们更新Dispose()方法来摆脱那些托管对象:

public void Dispose()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //Free managed resources too
   if (this.databaseConnection != null)
   {
      this.databaseConnection.Dispose();
      this.databaseConnection = null;
   }
   if (this.frameBufferImage != null)
   {
      this.frameBufferImage.Dispose();
      this.frameBufferImage = null;
   }
}

一切都很好, 但您可以做得更好


如果该人忘记在您的对象上调用Dispose()怎么办?然后他们将泄漏一些不受管理的资源!

注意:它们不会泄漏托管资源,因为最终垃圾收集器将在后台线程上运行,并释放与任何未使用的对象关联的内存。这将包括您的对象以及您使用的任何托管对象(例如BitmapDbConnection )。

如果该人忘记了调用Dispose() ,我们仍然可以保存他们的培根!我们仍然可以它们调用此方法:当垃圾收集器最终开始释放(即完成)对象时。

注意:垃圾收集器最终将释放所有托管对象。完成后,它将在对象上调用Finalize方法。 GC 不了解或不在乎您的 Dispose方法。当我们想要摆脱不受管理的东西时,这只是我们为调用的方法选择的名称。

垃圾收集器销毁我们的对象是释放那些烦人的非托管资源的绝佳时机。我们通过重写Finalize()方法来做到这一点。

注意:在 C#中,您不会显式覆盖Finalize()方法。您编写了一个看起来像 C ++ 析构函数的方法 ,并且编译器将其用作Finalize()方法的实现:

~MyObject()
{
    //we're being finalized (i.e. destroyed), call Dispose in case the user forgot to
    Dispose(); //<--Warning: subtle bug! Keep reading!
}

但是该代码中存在一个错误。您会看到,垃圾收集器在后台线程上运行;您不知道销毁两个对象的顺序。很有可能在您的Dispose()代码中,您试图摆脱的托管对象(因为您想提供帮助)不再存在:

public void Dispose()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.gdiCursorBitmapStreamFileHandle);

   //Free managed resources too
   if (this.databaseConnection != null)
   {
      this.databaseConnection.Dispose(); //<-- crash, GC already destroyed it
      this.databaseConnection = null;
   }
   if (this.frameBufferImage != null)
   {
      this.frameBufferImage.Dispose(); //<-- crash, GC already destroyed it
      this.frameBufferImage = null;
   }
}

因此,您需要的是Finalize()告诉Dispose()一种方式,它应该不接触任何托管资源(因为它们可能不再存在 ),同时仍释放非托管资源。

执行此操作的标准模式是让Finalize()Dispose()都调用第三个 (!)方法。在此处传递一个布尔值,表示是否要从Dispose()调用它(而不是Finalize() ),这意味着释放托管资源是安全的。

这个内部方法可以给出像 “CoreDispose”,或 “MyInternalDispose” 一些任意名称,但传统调用它Dispose(Boolean)

protected void Dispose(Boolean disposing)

但是更有用的参数名称可能是:

protected void Dispose(Boolean itIsSafeToAlsoFreeManagedObjects)
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //Free managed resources too, but only if I'm being called from Dispose
   //(If I'm being called from Finalize then the objects might not exist
   //anymore
   if (itIsSafeToAlsoFreeManagedObjects)  
   {    
      if (this.databaseConnection != null)
      {
         this.databaseConnection.Dispose();
         this.databaseConnection = null;
      }
      if (this.frameBufferImage != null)
      {
         this.frameBufferImage.Dispose();
         this.frameBufferImage = null;
      }
   }
}

然后,将IDisposable.Dispose()方法的实现更改为:

public void Dispose()
{
   Dispose(true); //I am calling you from Dispose, it's safe
}

和您的终结者可以:

~MyObject()
{
   Dispose(false); //I am *not* calling you from Dispose, it's *not* safe
}

注意 :如果您的对象从实现Dispose的对象Dispose ,那么在覆盖 Dispose 时,请不要忘记调用其基本 Dispose 方法:

public override void Dispose()
{
    try
    {
        Dispose(true); //true: safe to free managed resources
    }
    finally
    {
        base.Dispose();
    }
}

一切都很好, 但您可以做得更好


如果用户在您的对象上调用Dispose() ,则所有内容均已清除。稍后,当垃圾收集器出现并调用 Finalize 时,它将再次调用Dispose

这不仅浪费,而且如果您的对象具有对您从上次Dispose()调用以来已Dispose()的对象的垃圾引用,您将尝试再次废弃它们!

您会在代码中注意到,我小心删除了对已处置对象的引用,因此,我不会尝试在垃圾对象引用上调用Dispose 。但这并不能阻止潜伏的小错误。

当用户调用Dispose() ,句柄CursorFileBitmapIconServiceHandle被破坏。稍后当垃圾收集器运行时,它将尝试再次破坏相同的句柄。

protected void Dispose(Boolean iAmBeingCalledFromDisposeAndNotFinalize)
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //<--double destroy 
   ...
}

解决此问题的方法是告诉垃圾收集器,它无需费心地完成对象的处理 - 它的资源已被清理,并且不再需要任何工作。您可以通过在Dispose()方法中调用GC.SuppressFinalize()来做到这一点:

public void Dispose()
{
   Dispose(true); //I am calling you from Dispose, it's safe
   GC.SuppressFinalize(this); //Hey, GC: don't bother calling finalize later
}

现在,用户已调用Dispose() ,我们有了:

  • 释放非托管资源
  • 释放托管资源

GC 运行终结器没有任何意义 - 一切都已处理完毕。

我不能使用 Finalize 清理非托管资源吗?

Object.Finalize的文档说:

Finalize 方法用于在销毁对象之前对当前对象所拥有的非托管资源执行清理操作。

但是 MSDN 文档也对IDisposable.Dispose说:

执行与释放,释放或重置非托管资源相关的应用程序定义的任务。

那是什么呢?我可以清理哪一个托管资源?答案是:

这是你的选择!但是选择 “ Dispose

您当然可以将未管理的清除操作放入终结器中:

~MyObject()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //A C# destructor automatically calls the destructor of its base class.
}

这样做的问题是您不知道何时垃圾回收器会完成您的对象。您的未管理,不需要,未使用的本机资源将一直存在,直到垃圾收集器最终运行为止。然后它将调用您的 finalizer 方法;清理非托管资源。 Object.Finalize的文档指出了这一点:

终结器执行的确切时间是不确定的。为确保确定释放类实例的资源,请实现Close方法或提供IDisposable.Dispose实现。

这是使用Dispose清理非托管资源的优点。您将了解并控制何时清理非托管资源。他们的破坏是“确定性的”


要回答您最初的问题:为什么现在不释放内存,而不是在 GC 决定这样做时释放内存?我有一个面部识别软件,由于不再需要它们, 现在 需要摆脱 530 MB 的内部图像。当我们不这样做时:机器会陷入停顿状态。

奖励阅读

对于喜欢此答案样式的人(解释为什么 ,因此如何变得显而易见),建议您阅读 Don Box 的 Essential COM 的第一章:

在 35 页中,他解释了使用二进制对象的问题,并在您的面前发明了 COM。一旦了解了 COM 的原因 ,剩下的 300 页就显而易见了,只详细介绍了 Microsoft 的实现。

我认为每个曾经处理过对象或 COM 的程序员都应该至少阅读第一章。这是有史以来最好的解释。

额外奖金阅读

当您知道的一切都不对时 ,埃里克 · 利珀特(Eric Lippert)

因此,确实很难编写正确的终结器,而我能给您的最佳建议是不要尝试

IDisposable通常用于利用using语句,并利用一种简单的方法来确定性地清除托管对象。

public class LoggingContext : IDisposable {
    public Finicky(string name) {
        Log.Write("Entering Log Context {0}", name);
        Log.Indent();
    }
    public void Dispose() {
        Log.Outdent();
    }

    public static void Main() {
        Log.Write("Some initial stuff.");
        try {
            using(new LoggingContext()) {
                Log.Write("Some stuff inside the context.");
                throw new Exception();
            }
        } catch {
            Log.Write("Man, that was a heavy exception caught from inside a child logging context!");
        } finally {
            Log.Write("Some final stuff.");
        }
    }
}

Dispose 模式的目的是提供一种清除托管资源和非托管资源的机制,何时发生取决于如何调用 Dispose 方法。在您的示例中,使用 Dispose 实际上并没有执行任何与 Dispose 相关的操作,因为清除列表不会对该被处置的集合产生影响。同样,将变量设置为 null 的调用也不会影响 GC。

您可以看一下这篇文章,以获取有关如何实现 Dispose 模式的更多详细信息,但是它基本上看起来像这样:

public class SimpleCleanup : IDisposable
{
    // some fields that require cleanup
    private SafeHandle handle;
    private bool disposed = false; // to detect redundant calls

    public SimpleCleanup()
    {
        this.handle = /*...*/;
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Dispose managed resources.
                if (handle != null)
                {
                    handle.Dispose();
                }
            }

            // Dispose unmanaged managed resources.

            disposed = true;
        }
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
}

这里最重要的方法是 Dispose(bool),它实际上在两种不同的情况下运行:

  • dispose == true:该方法已由用户代码直接或间接调用。可以处理托管和非托管资源。
  • dispose == false:运行时已从终结器内部调用了该方法,因此您不应引用其他对象。只能处置非托管资源。

简单地让 GC 负责清理的问题是,您无法真正控制 GC 何时运行收集周期(可以调用 GC.Collect(),但实际上不应该这样做),因此资源可能会保留下来大约比需要的时间更长。请记住,调用 Dispose()实际上并不会导致收集周期或以任何方式导致 GC 收集 / 释放对象。它只是提供了一种方法,可以更确定地清除所使用的资源,并告诉 GC 已经执行了该清除操作。

IDisposable 和 dispose 模式的全部要点不是立即释放内存。实际上,对 Dispose 的调用实际上甚至唯一有机会立即释放内存的时间是在处理 Dispose == false 方案并处理非托管资源时。对于托管代码,在 GC 运行收集周期之前实际上不会回收内存,您实际上无法对其进行控制(除了调用 GC.Collect(),我已经提到过这不是一个好主意)。

您的方案不是真的有效,因为. NET 中的字符串不使用任何未使用的资源,也不实现 IDisposable,因此无法强制对其进行 “清理”。

调用 Dispose 之后,不应再对对象的方法进行任何调用(尽管对象应允许对 Dispose 的进一步调用)。因此,问题中的例子很愚蠢。如果调用了 Dispose,则对象本身可以被丢弃。因此,用户应该只丢弃对整个对象的所有引用(将它们设置为 null),并且它内部的所有相关对象都将自动清除。

至于有关托管 / 非托管的一般性问题以及其他答案中的讨论,我认为对此问题的任何回答都必须以非托管资源的定义开始。

归结为是,可以调用一个函数使系统进入状态,而可以调用另一个函数使系统退出该状态。现在,在典型示例中,第一个可能是返回文件句柄的函数,第二个可能是对CloseHandle的调用。

但是 - 这是关键 - 它们可以是任何匹配的功能对。一个建立一个状态,另一个建立状态。如果状态已建立但尚未拆除,则该资源的实例存在。您必须安排在正确的时间进行拆卸 - 资源不是由 CLR 管理的。唯一自动管理的资源类型是内存。有两种:GC 和堆栈。值类型由堆栈(或通过引用类型内的游标)管理,而引用类型由 GC 管理。

这些功能可能会导致状态更改,可以自由交错,或者可能需要完美嵌套。状态更改可能是线程安全的,也可能不是。

看正义问题中的例子。对日志文件的缩进的更改必须完美嵌套,否则一切都会出错。而且它们不太可能是线程安全的。

可以与垃圾收集器搭便车,以清理您的非托管资源。但是,仅当状态更改函数是线程安全的并且两个状态可以具有以任何方式重叠的生存期时,才可以。因此,Justice 的资源示例不能包含终结器!它只是无济于事。

对于这些资源,您可以仅实现IDisposable ,而无需使用终结器。终结器绝对是可选的 - 必须如此。这在很多书中都被掩盖甚至没有提到。

然后,您必须使用using语句才能确保调用了Dispose 。这基本上是像钩连一程与所述堆叠(从而终结是到 GC, using是在堆栈)。

缺少的部分是您必须手动编写 Dispose 并使其调用您的字段和基类。 C ++ / CLI 程序员不必这样做。在大多数情况下,编译器会为他们编写代码。

有一种选择,对于状态嵌套完美且不是线程安全的状态,我更喜欢(除了其他任何事情,避免使用 IDisposable 可以避免与无法拒绝向实现 IDisposable 的每个类添加终结器的人发生争执的问题) 。

不用编写类,而是编写一个函数。该函数接受委托以回调:

public static void Indented(this Log log, Action action)
{
    log.Indent();
    try
    {
        action();
    }
    finally
    {
        log.Outdent();
    }
}

然后一个简单的例子是:

Log.Write("Message at the top");
Log.Indented(() =>
{
    Log.Write("And this is indented");

    Log.Indented(() =>
    {
        Log.Write("This is even more indented");
    });
});
Log.Write("Back at the outermost level again");

拉姆达传递中作为一个代码块,所以这就像在你自己手里控制结构来达到相同的目的是using ,除非你不再有来电者滥用它的危险。他们没有办法清除资源。

如果资源是可能具有重叠生命周期的资源,则此技术的用处不大,因为那样的话,您希望能够先构建资源 A,然后构建资源 B,然后杀死资源 A,然后再杀死资源 B。您不能这样做如果您已强迫用户像这样完美嵌套。但是,然后您需要使用IDisposable (但仍然没有终结器,除非您实现了线程安全,这不是免费的)。

我使用 IDisposable 的方案:清理非托管资源,取消订阅事件,关闭连接

我用于实现 IDisposable( 不是 threadsafe )的惯用法:

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
}

是的,该代码是完全冗余且不必要的,并且不会使垃圾收集器执行其他操作(如果 MyCollection 的实例超出范围,则是.Clear() 。尤其是.Clear()调用。

回答您的编辑:有点。如果我这样做:

public void WasteMemory()
{
    var instance = new MyCollection(); // this one has no Dispose() method
    instance.FillItWithAMillionStrings();
}

// 1 million strings are in memory, but marked for reclamation by the GC

就内存管理而言,它在功能上是相同的:

public void WasteMemory()
{
    var instance = new MyCollection(); // this one has your Dispose()
    instance.FillItWithAMillionStrings();
    instance.Dispose();
}

// 1 million strings are in memory, but marked for reclamation by the GC

如果确实真的需要立即释放内存,请调用GC.Collect() 。不过,这里没有理由这样做。需要时将释放内存。

如果MyCollection都要对MyCollection进行垃圾回收,那么您就不需要处理它。这样做只会使 CPU 不必要地运转,甚至可能使垃圾收集器已经执行的某些预先计算的分析无效。

我使用IDisposable进行诸如确保正确处理线程以及非托管资源之类的事情。

编辑回应斯科特的评论:

只有当调用 [sic] GC.Collect()时,GC 性能指标才会受到影响”

从概念上讲,GC 维护对象引用图的视图以及线程堆栈框架对其的所有引用。该堆可能很大,并且跨越了许多页的内存。作为一种优化,GC 会缓存其对不太可能经常更改的页面的分析,以避免不必要地重新扫描该页面。当页面中的数据发生更改时,GC 会从内核接收通知,因此它知道该页面已脏,需要重新扫描。如果集合在 Gen0 中,则页面中的其他内容也可能会发生变化,但是在 Gen1 和 Gen2 中的可能性较小。有趣的是,对于将 GC 移植到 Mac 上以使 Silverlight 插件在该平台上运行的团队而言,这些挂钩在 Mac OS X 中不可用。

避免不必要地浪费资源的另一点是:想象一个过程正在卸载的情况。还可以想象该进程已经运行了一段时间。很有可能该进程的许多内存页面已被交换到磁盘。至少它们不再位于 L1 或 L2 缓存中。在这种情况下,卸载的应用程序将所有这些数据和代码页交换回内存以释放 “释放” 资源是没有意义的,而这些资源将在进程终止时由操作系统释放。这适用于托管甚至某些非托管资源。仅必须保留使非后台线程保持活动状态的资源,否则该进程将保持活动状态。

现在,在正常执行过程中,必须正确清除临时资源(如 @fezmonkey 指出数据库连接,套接字,窗口句柄 ),以避免非托管内存泄漏。这些都是必须处理的事情。如果您创建一个拥有线程的类(并拥有一个,我的意思是它创建了它,因此至少是按照我的编码风格负责确保它停止),那么该类很可能必须实现IDisposable并在执行过程中拆除该线程Dispose

.NET 框架使用IDisposable接口作为信号,甚至警告开发人员必须丢弃此类。我想不出框架中实现IDisposable的任何类型(不包括显式接口实现),其中处置是可选的。

如果要立即删除 ,请使用非托管内存

看到:

在您发布的示例中,它仍然没有 “立即释放内存”。所有内存都是垃圾回收的,但可以允许在较早的一代中回收内存。您必须运行一些测试才能确定。


框架设计准则是准则,而不是规则。他们告诉您接口的主要用途,何时使用,如何使用以及何时不使用。

我曾经阅读过使用 IDisposable 失败时的简单 RollBack()代码。下面的 MiniTx 类将检查 Dispose()上的标志,如果Commit调用从未发生,它将对其自身调用Rollback 。它增加了一个间接层,使调用代码更容易理解和维护。结果看起来像:

using( MiniTx tx = new MiniTx() )
{
    // code that might not work.

    tx.Commit();
}

我还看到定时 / 日志记录代码执行相同的操作。在这种情况下,Dispose()方法停止计时器并记录该块已退出。

using( LogTimer log = new LogTimer("MyCategory", "Some message") )
{
    // code to time...
}

因此,这里有几个具体示例,它们不执行任何非托管资源清除,但是确实成功使用 IDisposable 创建了更干净的代码。

我将不再重复有关使用或释放非托管资源的常规内容,所有内容已涵盖。但我想指出似乎是一个普遍的误解。
给出以下代码

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

我认识到 Disposable 实现不遵循当前的准则,但是希望大家都明白。
现在,当调用 Dispose 时,释放了多少内存?

答:没有。
调用 Dispose 可以释放非托管资源,它不能回收托管内存,只有 GC 可以这样做。并不是说上述不是一个好主意,遵循上述模式实际上仍然是一个好主意。一旦运行 Dispose,即使 LargeStuff 实例可能仍在范围内,也不会停止 GC 回收_Large 所使用的内存。 _Large 中的字符串也可能是第 0 代,但是 LargeStuff 的实例可能是第 2 代,因此,再次声明,将更快地回收内存。
尽管没有必要添加终结器来调用上面显示的 Dispose 方法。那只会延迟对内存的回收,以允许终结器运行。