UML软件工程组织

关于GC——Dotnet中Dispose的设计模式
作者:Rustle 来源:中国DotNet俱乐部

.NET的GC机制有这样两个问题:

首先,GC并不是能释放所有的资源。它不能自动释放非托管资源。

第二,GC并不是实时性的,这将会造成系统性能上的瓶颈和不确定性。

为了解决第一个问题,.NET提供了析构函数,在C#中是~ClassName的形式。如果某个类定义了析构函数,.NET会在第一次的GC中调用析构函数,第二次才真正进行资源释放。这就允许了我们能够做一些手动的资源管理操作,手动对非托管资源进行清理。但是如果没有必要,定义析构函数就会对性能造成较大的影响。

仅仅依赖析构函数对非托管资源进行释放是不够的,这是由于第二个问题:GC并不是实时性的,这会造成系统性能上的瓶颈和不确定性。所以有了IDisposable接口,IDisposable接口定义了Dispose方法,这个方法用来供程序员显式调用以释放非托管资源。

通常我们应该这样写程序:

        public class SampleClass : System.IDisposable

        {

                public void Dispose()

                //供程序员显式调用的Dispose方法

                {

                        Dispose(true);

                        //调用带参数的Dispose方法,释放托管和非托管资源

                        System.GC.SuppressFinalize(this);

                        //手动调用了Dispose释放资源,那么析构函数就是不必要的了,这里阻止GC调用析构函数

                }

                protected void Dispose(bool disposing)

                //protected的Dispose方法,保证不会被外部调用。

                //传入bool值disposing以确定是否释放托管资源

                {

                        if (disposing)

                        {

                                //在这里加入清理"托管资源"的代码,应该是xxx.Dispose();

                        }

                        // 在这里加入清理"非托管资源"的代码

                }

                ~SampleClass()

                //供GC调用的析构函数

                {

                        Dispose(false);

                        //释放非托管资源

                }

        }

        这样一来,我们就像Delphi里调用Object.Free方法一样自然的调用Object.Dispose方法,而即使我们忘记了在合适的时候调用Dispose,GC也会在释放对象的时候帮我们清理非托管资源的。GC所充当的角色只是一种保障手段,它应该充当这种角色,我们不能过分依赖它。

        实际上,在较大的模块退出时我们还应该及时地手动调用GC.Collect进行垃圾回收。


版权所有:UML软件工程组织