C#中对IDisposable接口的理解
本人最近接触一个项目,在这个项目里面看到很多类实现了IDisposable接口.在我以前的项目中都很少用过这个接口,只知道它是用来手动释放资源的.这么多地方用应该有它的好处,为此自己想对它有进一步的了解,但这个过程远没有我想象中的简单.
IDisposable接口定义:定义一种释放分配的资源的方法。
.NET 平台在内存管理方面提供了GC（Garbage Collection），负责自动释放托管资源和内存回收的工作，但它无法对非托管资源进行释放，这时我们必须自己提供方法来释放对象内分配的非托管资源，比如你在对象的实现代码中使用了一个COM对象 最简单的办法可以通过实现Finalize()来释放非托管资源，因为GC在释放对象时会检查该对象是否实现了 Finalize() 方法。 有一种更好的，那就是通过实现一个接口显式的提供给客户调用端手工释放对象的方法，，而不是傻傻的等着GC来释放我们的对象.这种实现并不一定要使用了非托管资源后才用，如果你设计的类会在运行时有非常大的实例（象 GIS 中的Geometry），为了优化程序性能，你也可以通过实现该接口让客户调用端在确认不需要这些对象时手工释放它们 .
在定义一个类时,可以使用两种机制来自动释放未托管的资源.这些机制通常放在一起实现.因为每个机制都为问题提供了略为不同的解决方法.这两种机制是:
第一:声明一个析构函数,作为类的一个成员.在GC回收资源时会调用.
第二:在类中实现IDisposable接口
析构函数的问题:
执行的不确定性:析构函数是由GC调用的,而GC的调用是不确定的.如果对象占用了比较重要的资源,应尽可以早的释放资源.
IDisposable接口定义了一个模式,为释未托管资源提供了确定的机制,并避免产生析构函数固有的与GC相关的问题.
在实际应用了,常常是结合两种方法来取长补短.之所以要加上析构函数,是防止客户端没有调用Dispose方法.
本人对IDisposable接口的理解是这样的:
这种手动释放资源的方式肯定要比等待GC来回收要效率高啊,于是出现了下面的示例类代码:
这个Foo类实现了IDisposable接口,里面有一个简单的方法:增加一个用户.
Code：
public class Foo : IDisposable
{
/// <summary>
/// 实现IDisposable接口
/// </summary>
public void Dispose()
{
Dispose(true);
//.NET Framework 类库
// GC..::.SuppressFinalize 方法
//请求系统不要调用指定对象的终结器。
GC.SuppressFinalize(this);
}
/// <summary>
/// 虚方法，可供子类重写
/// </summary>
/// <param name="disposing"></param>
protected virtual void Dispose(bool disposing)
{
if (!m_disposed)
{
if (disposing)
{
// Release managed resources
}
// Release unmanaged resources
m_disposed = true;
}
}
/// <summary>
/// 析构函数
/// 当客户端没有显示调用Dispose()时由GC完成资源回收功能
/// </summary>
~Foo()
{
Dispose(false);
}
/// <summary>
/// 增加一个用户
/// </summary>
public bool AddUser()
{
//代码省略
return true;
}
/// <summary>
/// 是否已经被释放过,默认是false
/// </summary>
public bool m_disposed;
//private IntPtr handle;
}
客户端是这样调用的:先实例化对象,然后增加一个用户,此时销毁对象.
Code：
Foo _foo = null;
_foo = new Foo();
//资源是否已经被释放
//第一次默认为false;
bool isRelease3 = _foo.m_disposed;
//增加用户
bool isAdded= _foo.AddUser();
//不再用了,释放资源
_foo.Dispose();