如果有的话，我希望代码的效率比不使用它时要低。

调用Clear（）方法是不必要的，如果Dispose不这样做，GC可能不会这么做。。。

我使用IDisposable的场景：清理非托管资源、取消订阅事件、关闭连接

我用于实现IDisposable（非线程安全）的习惯用法：

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
}

Dispose的目的是释放非托管资源。这需要在某个时候完成，否则它们永远不会被清理。垃圾回收器不知道如何对IntPtr类型的变量调用DeleteHandle（），也不知道是否需要调用DeleteHandler（）。

注意：什么是非托管资源？如果您在Microsoft.NET Framework中找到它：它是托管的。如果你自己去打听MSDN，它是不受管理的。任何您使用P/Invoke调用来脱离.NET Framework中所有可用内容的舒适世界的东西都是非托管的，现在您负责清理它。

您创建的对象需要公开一些外部世界可以调用的方法，以便清理非托管资源。该方法可以任意命名：

public void Cleanup()

or

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（），该怎么办？然后他们会泄露一些未管理的资源！

注意：它们不会泄漏托管资源，因为垃圾收集器最终将在后台线程上运行，并释放与任何未使用对象相关联的内存。这将包括您的对象和您使用的任何托管对象（例如Bitmap和DbConnection）。

如果该人忘记调用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方法：

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

一切都很好，除了你能做得更好！

---

如果用户对您的对象调用Dispose（），那么一切都已清理完毕。稍后，当垃圾收集器出现并调用Finalize时，它将再次调用Dispose。

这不仅是浪费，而且如果您的对象对上次调用Dispose（）时已处理的对象有垃圾引用，您将尝试再次处理它们！

您会注意到，在我的代码中，我小心地删除了对已释放对象的引用，所以我不会尝试对垃圾对象引用调用Dispose。但这并没有阻止一个微妙的bug潜入。

当用户调用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.
}

这样做的问题是，你不知道垃圾收集器什么时候可以完成你的对象。您的未管理、未需要、未使用的本机资源将一直存在，直到垃圾收集器最终运行。然后它将调用终结器方法；清理非托管资源。Object.Finalize的文档指出了这一点：

终结器执行的确切时间未定义。要确保类实例的资源的确定性释放，请实现Close方法或提供IDisposable.Dispose实现。

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

---

回答您最初的问题：为什么不现在释放内存，而不是在GC决定释放内存时释放内存？我有一个面部识别软件，现在需要去掉530 MB的内部图像，因为它们不再需要了。当我们不这样做时：机器会磨到交换停止。

奖金阅读

对于任何喜欢这个答案风格的人（解释原因，所以答案变得显而易见），我建议你阅读Don Box的基本COM的第一章：

直接链接：皮尔逊出版公司第1章样本磁铁：84bf0b960936d677190a2be355858e80ef7542c0

在35页中，他解释了使用二进制对象的问题，并在你眼前发明了COM。一旦你意识到COM的原因，剩下的300页就显而易见了，只需详细介绍一下微软的实现。

我认为每一个处理过对象或COM的程序员至少都应该阅读第一章。这是对任何事情最好的解释。

额外奖励阅读

当你所知道的一切都是错误的

因此，确实很难编写正确的终结器，我能给你的最好建议是不要尝试。

在对对象调用Dispose后，不应再调用该对象的方法（尽管对象应允许进一步调用Dispose）。因此，问题中的例子是愚蠢的。如果调用Dispose，则可以丢弃对象本身。因此，用户只需丢弃对整个对象的所有引用（将其设置为null），其内部的所有相关对象将自动被清理。

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

归根结底，你可以调用一个函数来让系统进入一种状态，而你可以调用另一个函数来使它恢复到那种状态。现在，在典型示例中，第一个可能是返回文件句柄的函数，第二个可能是对CloseHandle的调用。

但是-这是关键-它们可以是任何匹配的函数对。一个建立一个国家，另一个摧毁它。如果状态已构建但尚未拆除，则资源的实例存在。您必须安排在正确的时间进行拆卸-资源不由CLR管理。唯一自动管理的资源类型是内存。有两种：GC和堆栈。值类型由堆栈管理（或通过在引用类型内搭便车），引用类型由GC管理。

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

看看Justice问题中的例子。对日志文件缩进的更改必须完全嵌套，否则会出错。此外，它们也不太可能是线程安全的。

可以搭上垃圾收集器的便车来清理未管理的资源。但前提是状态更改函数是线程安全的，并且两个状态的生存期可以以任何方式重叠。因此，正义的资源示例不能有终结器！这对任何人都没有帮助。

对于这些类型的资源，您可以只实现IDisposable，而不需要终结器。终结器是绝对可选的-它必须是。这在很多书中都被掩盖了，甚至没有提到。

然后，您必须使用using语句来确保调用Dispose。这本质上就像在堆栈上搭车一样（因为终结器是在GC上，而使用是在堆栈上）。

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

还有一种选择，我更喜欢嵌套完美且不线程安全的状态（除了其他之外，避免IDisposable避免了与无法抗拒为每个实现IDisposale的类添加终结器的人发生争论的问题）。

不用编写类，而是编写函数。该函数接受要回调的委托：

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");

传入的lambda作为一个代码块，因此就像您创建自己的控制结构以实现与使用相同的目的，只是您不再有调用方滥用它的危险。它们不可能不清理资源。

如果资源的生存期可能重叠，那么这种技术就不太有用了，因为这样你就可以构建资源A，然后构建资源B，然后杀死资源A，再杀死资源B。但是，您需要使用IDisposable（但仍然没有终结器，除非您实现了线程安全，这不是免费的）。

给定的代码示例不是IDisposable用法的好示例。字典清除通常不应转到Dispose方法。字典项在超出范围时将被清除和处理。需要IDisposable实现来释放一些内存/处理程序，即使它们超出范围也不会释放/释放。

下面的示例显示了IDisposable模式的一个很好的示例，其中包含一些代码和注释。

public class DisposeExample
{
    // A base class that implements IDisposable. 
    // By implementing IDisposable, you are announcing that 
    // instances of this type allocate scarce resources. 
    public class MyResource: IDisposable
    {
        // Pointer to an external unmanaged resource. 
        private IntPtr handle;
        // Other managed resource this class uses. 
        private Component component = new Component();
        // Track whether Dispose has been called. 
        private bool disposed = false;

        // The class constructor. 
        public MyResource(IntPtr handle)
        {
            this.handle = handle;
        }

        // Implement IDisposable. 
        // Do not make this method virtual. 
        // A derived class should not be able to override this method. 
        public void Dispose()
        {
            Dispose(true);
            // This object will be cleaned up by the Dispose method. 
            // Therefore, you should call GC.SupressFinalize to 
            // take this object off the finalization queue 
            // and prevent finalization code for this object 
            // from executing a second time.
            GC.SuppressFinalize(this);
        }

        // Dispose(bool disposing) executes in two distinct scenarios. 
        // If disposing equals true, the method has been called directly 
        // or indirectly by a user's code. Managed and unmanaged resources 
        // can be disposed. 
        // If disposing equals false, the method has been called by the 
        // runtime from inside the finalizer and you should not reference 
        // other objects. Only unmanaged resources can be disposed. 
        protected virtual void Dispose(bool disposing)
        {
            // Check to see if Dispose has already been called. 
            if(!this.disposed)
            {
                // If disposing equals true, dispose all managed 
                // and unmanaged resources. 
                if(disposing)
                {
                    // Dispose managed resources.
                    component.Dispose();
                }

                // Call the appropriate methods to clean up 
                // unmanaged resources here. 
                // If disposing is false, 
                // only the following code is executed.
                CloseHandle(handle);
                handle = IntPtr.Zero;

                // Note disposing has been done.
                disposed = true;

            }
        }

        // Use interop to call the method necessary 
        // to clean up the unmanaged resource.
        [System.Runtime.InteropServices.DllImport("Kernel32")]
        private extern static Boolean CloseHandle(IntPtr handle);

        // Use C# destructor syntax for finalization code. 
        // This destructor will run only if the Dispose method 
        // does not get called. 
        // It gives your base class the opportunity to finalize. 
        // Do not provide destructors in types derived from this class.
        ~MyResource()
        {
            // Do not re-create Dispose clean-up code here. 
            // Calling Dispose(false) is optimal in terms of 
            // readability and maintainability.
            Dispose(false);
        }
    }
    public static void Main()
    {
        // Insert code here to create 
        // and use the MyResource object.
    }
}

是的，这段代码完全是多余和不必要的，它不会让垃圾回收器做任何它不会做的事情（即，一旦MyCollection的实例超出范围），尤其是.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（）。内存将在需要时释放。