通过阅读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包含一百万个字符串,并且您希望现在释放内存,而不是等待垃圾收集器。上面的代码能做到这一点吗?


当前回答

大多数关于“非托管资源”的讨论的一个问题是,它们并没有真正定义这个术语,但似乎暗示它与非托管代码有关。虽然许多类型的非托管资源确实与非托管代码交互,但用这种术语来思考非托管资源是没有帮助的。

相反,我们应该认识到所有被管理的资源都有共同点:它们都包含一个对象,要求某个外部“事物”代表它做一些事情,而损害了其他一些“事物”,而另一个实体同意这样做,直到另行通知。如果物体被抛弃并消失得无影无踪,那么任何东西都不会告诉外部的“事物”,它不再需要代表不再存在的物体改变自己的行为;因此,“东西”的有用性将永久性地降低。

因此,非托管资源表示外部“事物”代表对象改变其行为的协议,如果对象被放弃并不再存在,这将毫无用处地损害外部“事物的有用性。被管理的资源是一个对象,它是此类协议的受益人,但如果它被放弃,它已签署接收通知,并将使用该通知在其被销毁之前整理其事务。

其他回答

IDisposable/using组合除了主要用作控制系统资源生命周期的方法(完全被Ian的精彩回答所涵盖)外,还可以用于确定(关键)全局资源的状态变化范围:控制台、线程、进程、任何全局对象(如应用程序实例)。

我写了一篇关于这种模式的文章:http://pragmateek.com/c-scope-your-global-state-changes-with-idisposable-and-the-using-statement/

它说明了如何以可重用和可读的方式保护一些常用的全局状态:控制台颜色、当前线程区域性、Excel应用程序对象财产。。。

在对对象调用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(但仍然没有终结器,除非您实现了线程安全,这不是免费的)。

是的,这段代码完全是多余和不必要的,它不会让垃圾回收器做任何它不会做的事情(即,一旦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()。内存将在需要时释放。

处置托管资源最合理的用例是为GC回收资源做准备,否则这些资源将永远不会被收集。

一个主要的例子是循环引用。

虽然使用避免循环引用的模式是最佳做法,但如果您最终(例如)得到了一个“子”对象,该对象的引用返回到其“父”,那么如果您只是放弃引用并依赖GC,则这可能会停止父对象的GC收集,而且如果您实现了终结器,则永远不会调用它。

解决此问题的唯一方法是通过将子级上的Parent引用设置为null来手动打破循环引用。

在父母和孩子身上实现IDisposable是实现这一点的最佳方式。当对父级调用Dispose时,对所有子级调用Disposit,并在子级Dispose方法中,将父级引用设置为null。

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