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


当前回答

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),它实际上在两种不同的情况下运行:

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

简单地让GC负责清理的问题是,你无法真正控制GC何时运行一个收集周期(你可以调用GC.Collect(),但你真的不应该这样做),所以资源可能会比需要的时间更长。记住,调用Dispose()实际上不会导致收集循环,也不会以任何方式导致GC收集/释放对象;它只是提供了更明确地清理所用资源的方法,并告诉GC该清理已经执行。

IDisposable和dispose模式的重点不是立即释放内存。对Dispose的调用实际上只有在处理dispositing==false场景和处理非托管资源时才有机会立即释放内存。对于托管代码,在GC运行一个收集循环之前,内存实际上不会被回收,这是您无法控制的(除了调用GC.Collect()之外,我已经提到过这不是一个好主意)。

由于.NET中的字符串不使用任何未更改的资源,也不实现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()。内存将在需要时释放。

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

调用Clear()方法是不必要的,如果Dispose不这样做,GC可能不会这么做。。。

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

如果MyCollection无论如何都将被垃圾收集,那么您不需要对其进行处理。这样做只会过度消耗CPU,甚至可能使垃圾收集器已经执行的一些预先计算的分析无效。

我使用IDisposable来执行诸如确保线程以及非托管资源被正确处理之类的操作。

编辑回应斯科特的评论:

GC性能指标唯一受到影响的时间是调用〔sic〕GC.Collect()时“

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

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

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

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

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),它实际上在两种不同的情况下运行:

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

简单地让GC负责清理的问题是,你无法真正控制GC何时运行一个收集周期(你可以调用GC.Collect(),但你真的不应该这样做),所以资源可能会比需要的时间更长。记住,调用Dispose()实际上不会导致收集循环,也不会以任何方式导致GC收集/释放对象;它只是提供了更明确地清理所用资源的方法,并告诉GC该清理已经执行。

IDisposable和dispose模式的重点不是立即释放内存。对Dispose的调用实际上只有在处理dispositing==false场景和处理非托管资源时才有机会立即释放内存。对于托管代码,在GC运行一个收集循环之前,内存实际上不会被回收,这是您无法控制的(除了调用GC.Collect()之外,我已经提到过这不是一个好主意)。

由于.NET中的字符串不使用任何未更改的资源,也不实现IDisposable,因此您的方案并不真正有效,因此无法强制“清理”它们