MSDN建议按照下面的模式实现IDisposable接口(转)

http://www.cnblogs.com/czllfy/archive/2011/04/13/2014412.html

MSDN建议按照下面的模式实现IDisposable接口：

public class Foo : IDisposable
{
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!m_disposed)
        {
            if (disposing)
            {
                // Release managed resources
            }

            // Release unmanaged resources

            m_disposed = true;
        }
    }

    ~Foo()
    {
        Dispose(false);
    }

    private bool m_disposed;
}

在.NET的对象中实际上有两个用于释放资源的函数：Dispose和Finalize。Finalize的目的是用于释放非托管的资源，而Dispose是用于释放所有资源，包括托管的和非托管的。

在这个模式中，void Dispose(bool disposing)函数通过一个disposing参数来区别当前是否是被Dispose()调用。如果是被Dispose()调用，那么需要同时释放 托管和非托管的资源。如果是被~Foo()（也就是C#的Finalize()）调用了，那么只需要释放非托管的资源即可。

这是因为，Dispose()函数是被其它代码显式调用并要求释放资源的，而Finalize是被GC调用的。在GC调用 的时候Foo所引用的其它 托管对象可能还不需要被销毁，并且即使要销毁，也会由GC来调用。因此在Finalize中只需要释放非托管资源即可。另外一方面，由于在 Dispose()中已经释放了托管和非托管的资源，因此在对象被GC回收时再次调用Finalize是没有必要的，所以在Dispose()中调用 GC.SuppressFinalize(this)避免重复调用Finalize。

然而，即使重复调用Finalize和Dispose也是不存在问题的，因为有变量m_disposed的存在，资源只会被释放一次，多余的调用会被忽略过去。

因此，上面的模式保证了：

1、 Finalize只释放非托管资源；

2、 Dispose释放托管和非托管资源；

3、 重复调用Finalize和Dispose是没有问题的；

4、 Finalize和Dispose共享相同的资源释放策略，因此他们之间也是没有冲突的。

在C#中，这个模式需要显式地实现，其中C#的~Foo()函数代表了Finalize()。而在C++/CLI中，这个模式是自动实现的，C++的类析构函数则是不一样的。

按照C++语义，析构函数在超出作用域，或者delete的时候被调用。在Managed C++（即.NET 1.1中的托管C++）中，析构函数相当于CLR中的Finalize()方法，在垃圾收集的时候由GC调用，因此，调用的时机是不明确的。在.NET 2.0的C++/CLI中，析构函数的语义被修改为等价与Dispose()方法，这就隐含了两件事情：

1、 所有的C++/CLI中的CLR类都实现了接口IDisposable，因此在C#中可以用using关键字来访问这个类的实例。

2、 析构函数不再等价于Finalize()了。

对于第一点，这是一件好事，我认为在语义上Dispose()更加接近于C++析构函数。对于第二点，Microsoft进行了一次扩展，做法是引入了“！”函数，如下所示：

public ref class Foo
{
    public:
        Foo();
        ~Foo(); // destructor
        !Foo(); // finalizer
 };

“！”函数（我实在不知道应该怎么称呼它）取代原来Managed C++中的Finalize()被GC调用。MSDN建议，为了减少代码的重复，可以写这样的代码：

~Foo()
{
    //释放托管的资源
    this->!Foo();
}

!Foo()
{
    //释放非托管的资源
}

对于上面这个类，实际上C++/CLI生成对应的C#代码是这样的：

public class Foo
{
    private void !Foo()
    {
        // 释放非托管的资源
    }

    private void ~Foo()
    {
         // 释放托管的资源
        !Foo();
    }

    public Foo()
    {
    }

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

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            ~Foo();
        }
        else
        {
            try
            {
                !Foo();
            }
            finally
            {
                base.Finalize();
            }
        }
    }

    protected void Finalize()
    {
        Dispose(false);
    }
}

由于~Foo()和!Foo()不会被重复调用（至少MS这样认为），因此在这段代码中没有和前面m_disposed相同的变量，但是基本的结构是一样的。

并且，可以看到实际上并不是~Foo()和!Foo()就是Dispose和Finalize，而是C++/CLI编译器 生成了两个Dispose 和Finalize函数，并在合适的时候调用它们。C++/CLI其实已经做了很多工作，但是唯一的一个问题就是依赖于用户在~Foo()中调 用!Foo()。

关于资源释放，最后一点需要提的是Close函数。在语义上它和Dispose很类似，按照MSDN的说法，提供这个函数是为了让用户感觉舒服一点，因为对于某些对象，例如文件，用户更加习惯调用Close()。

然而，毕竟这两个函数做的是同一件事情，因此MSDN建议的代码就是：

public void Close()
{
    Dispose(();
} 

这里直接调用不带参数的Dispose函数以获 得和Dispose相同的语义。这样似乎就圆满了，但是从另外一方面说，如果同时提供了Dispose和Close，会给用户带来一些困惑。没有看到代码 细节的前提下，很难知道这两个函数到底有什么区别。因此在.NET的代码设计规范中说，这两个函数实际上只能让用户用一个。因此建议的模式是：

public class Foo: IDisposable
{
    public void Close()
    {
        Dispose();
    }

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

    protected virtual void Dispose(bool disposing)
    {
        // 同前
    }
}

这里使用了一个所谓的接口显式实现：void IDisposable.Dispose()。这个显式实现只能通过接口来访问，但是不能通过实现类来访问。因此：

Foo foo = new Foo();

foo.Dispose(); // 错误
(foo as IDisposable).Dispose(); // 正确

----------------------------------以下是CSDN上一位高手的总结----------------------------------------------

1、Finalize方法（C#中是析构函数，以下称析构函数）是用于释放非托管资源的，而托管资源会由GC自动回收。所 以，我们也可以这样来区分 托管和非托管资源。所有会由GC自动回收的资源，就是托管的资源，而不能由GC自动回收的资源，就是非托管资源。在我们的类中直接使用非托管资源的情况很 少，所以基本上不用我们写析构函数。

2、大部分的非托管资源会给系统带来很多负面影响，例如数据库连接不被释放就可能导致连接池中的可用数据库连接用尽。文件不关闭会导致其它进程无法读写这个文件等等。

实现模型：
1、由于大多数的非托管资源都要求可以手动释放，所以，我们应该专门为释放非托管资源公开一个方法。实现IDispose接口的Dispose方法是最好的模型，因为C#支持using语句快，可以在离开语句块时自动调用Dispose方法。

2、虽然可以手动释放非托管资源，我们仍然要在析构函数中释放非托管资源，这样才是安全的应用程序。否则如果因为程序员的疏忽忘记了手动释放非托管资源， 那么就会带来灾难性的后果。所以说在析构函数中释放非托管资源，是一种补救的措施，至少对于大多数类来说是如此。

3、由于析构函数的调用将导致GC对对象回收的效率降低，所以如果已经完成了析构函数该干的事情（例如释放非托管资源），就应当使用SuppressFinalize方法告诉GC不需要再执行某个对象的析构函数。

4、析构函数中只能释放非托管资源而不能对任何托管的对象/资源进行操作。因为你无法预测析构函数的运行时机，所以，当析构函数被执行的时候，也许你进行操作的托管资源已经被释放了。这样将导致严重的后果。

5、（这是一个规则）如果一个类拥有一个实现了IDispose接口类型的成员，并创建（注意是创建，而不是接收，必须是由类自己创建）它的实例对象，则 这个类也应该实现IDispose接口，并在Dispose方法中调用所有实现了IDispose接口的成员的Dispose方法。
只有这样的才能保证所有实现了IDispose接口的类的对象的Dispose方法能够被调用到，确保可以手动释放任何需要释放的资源。

(转码)C#实现标准的Dispose模式

需要明确一下C#程序（或者说.NET）中的资源。简单的说来，C#中的每一个类型都代表一种资源，而资源又分为两类：

托管资源：由CLR管理分配和释放的资源，即由CLR里new出来的对象；

非托管资源：不受CLR管理的对象，windows内核对象，如文件、数据库连接、套接字、COM对象等；

毫无例外地，如果我们的类型使用到了非托管资源，或者需要显式释放的托管资源，那么，就需要让类型继承接口IDisposable。这相当于是告诉调用者，该类型是需要显式释放资源的，你需要调用我的Dispose方法。

不过，这一切并不这么简单，一个标准的继承了IDisposable接口的类型应该像下面这样去实现。这种实现我们称之为Dispose模式：

    public class SampleClass : IDisposable
    {
        //演示创建一个非托管资源
        private IntPtr nativeResource = Marshal.AllocHGlobal(100);
        //演示创建一个托管资源
        private AnotherResource managedResource = new AnotherResource();
        private bool disposed = false;

        /// <summary>
        /// 实现IDisposable中的Dispose方法
        /// </summary>
        public void Dispose()
        {
            //必须为true
            Dispose(true);
            //通知垃圾回收机制不再调用终结器（析构器）
            GC.SuppressFinalize(this);
        }

        /// <summary>
        /// 不是必要的，提供一个Close方法仅仅是为了更符合其他语言（如C++）的规范
        /// </summary>
        public void Close()
        {
            Dispose();
        }

        /// <summary>
        /// 必须，以备程序员忘记了显式调用Dispose方法
        /// </summary>
        ~SampleClass()
        {
            //必须为false
            Dispose(false);
        }

        /// <summary>
        /// 非密封类修饰用protected virtual
        /// 密封类修饰用private
        /// </summary>
        /// <param name="disposing"></param>
        protected virtual void Dispose(bool disposing)
        {
            if (disposed)
            {
                return;
            }
            if (disposing)
            {
                // 清理托管资源
                if (managedResource != null)
                {
                    managedResource.Dispose();
                    managedResource = null;
                }
            }
            // 清理非托管资源
            if (nativeResource != IntPtr.Zero)
            {
                Marshal.FreeHGlobal(nativeResource);
                nativeResource = IntPtr.Zero;
            }
            //让类型知道自己已经被释放
            disposed = true;
        }

        public void SamplePublicMethod()
        {
            if (disposed)
            {
                throw new ObjectDisposedException("SampleClass", "SampleClass is disposed");
            }
            //省略
        }
    }

在Dispose模式中，几乎每一行都有特殊的含义。

在标准的Dispose模式中，我们注意到一个以~开头的方法：

        /// <summary>
        /// 必须，以备程序员忘记了显式调用Dispose方法
        /// </summary>
        ~SampleClass()
        {
            //必须为false
            Dispose(false);
        }

这个方法叫做类型的终结器。提供终结器的全部意义在于：我们不能奢望类型的调用者肯定会主动调用Dispose方法，基于终结器会被垃圾回收器调用这个特点，终结器被用做资源释放的补救措施。

一个类型的Dispose方法应该允许被多次调用而不抛异常。鉴于这个原因，类型内部维护了一个私有的布尔型变量disposed：

private bool disposed = false;

在实际处理代码清理的方法中，加入了如下的判断语句：

            if (disposed)
            {
                return;
            }
            //省略清理部分的代码，并在方法的最后为disposed赋值为true
            disposed = true;

这意味着类型如果被清理过一次，则清理工作将不再进行。

应该注意到：在标准的Dispose模式中，真正实现IDisposable接口的Dispose方法，并没有实际的清理工作，它实际调用的是下面这个带布尔参数的受保护的虚方法：

        /// <summary>
        /// 非密封类修饰用protected virtual
        /// 密封类修饰用private
        /// </summary>
        /// <param name="disposing"></param>
        protected virtual void Dispose(bool disposing)
        {
            //省略代码
        }

之所以提供这样一个受保护的虚方法，是为了考虑到这个类型会被其他类继承的情况。如果类型存在一个子类，子类也许会实现自己的Dispose模式。受保护 的虚方法用来提醒子类必须在实现自己的清理方法的时候注意到父类的清理工作，即子类需要在自己的释放方法中调用base.Dispose方法。

还有，我们应该已经注意到了真正撰写资源释放代码的那个虚方法是带有一个布尔参数的。之所以提供这个参数，是因为我们在资源释放时要区别对待托管资源和非托管资源。

在供调用者调用的显式释放资源的无参Dispose方法中，调用参数是true：

        public void Dispose()
        {
            //必须为true
            Dispose(true);
            //其他省略
        }

这表明，这个时候代码要同时处理托管资源和非托管资源。

在供垃圾回收器调用的隐式清理资源的终结器中，调用参数是false：

        ~SampleClass()
        {
            //必须为false
            Dispose(false);
        }

这表明，隐式清理时，只要处理非托管资源就可以了。

那么，为什么要区别对待托管资源和非托管资源。在认真阐述这个问题之前，我们需要首先弄明白：托管资源需要手动清理吗？ 不妨先将C#中的类型分为两类，一类继承了IDisposable接口，一类则没有继承。前者，我们暂时称之为非普通类型，后者我们称之为普通类型。非普 通类型因为包含非托管资源，所以它需要继承IDisposable接口，但是，这个包含非托管资源的类型本身，它是一个托管资源。所以说，托管资源需要手 动清理吗？这个问题的答案是：托管资源中的普通类型，不需要手动清理，而非普通类型，是需要手动清理的（即调用Dispose方法）。

Dispose模式设计的思路基于：如果调用者显式调用了Dispose方法，那么类型就该按部就班为自己的所以资源全部释放掉。如果调用者忘记调用 Dispose方法，那么类型就假定自己的所有托管资源（哪怕是那些上段中阐述的非普通类型）全部交给垃圾回收器去回收，而不进行手工清理。理解了这一 点，我们就理解了为什么Dispose方法中，虚方法传入的参数是true，而终结器中，虚方法传入的参数是true。

 

注意：我们提到了需要及时释放资源，却并没有进一步细说是否需要及时让引用等于null这一点。有一些人认为等于null可以帮助垃圾回收机制早点发现并标识对象是垃圾。其他人则认为这没有任何帮助。下一篇我们再细说这一点。