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();
C#编程的一个优点是程序员不需要担心具体的内存管理，尤其是垃圾收集器会处理所有的内存清理工作。用户可以得到像C++语言那样的效率，而不需要考虑像在C++中那样内存管理工作的复杂性。虽然不必手工管理内存，但如果要编写高效的代码，就仍需理解后台发生的事情。
一面运行没有错误,可总想知道这个dispose方法到底做了些什么.既然是释放资源,那么类被释放后应该就被销毁,它的引用应该是不存在的,于是本人的测试代码如下:
Code：
try
{
if (_foo == null)
{
//对象调用Dispose()后应该运行到此外
Response.Write("资源已经释放啦!");
}
else
{
Response.Write(_foo.GetType().ToString());
//资源是否已经被释放 此时为true
bool isRelease4 = _foo.m_disposed;
bool isAdded2 = _foo.AddUser();
}
}
catch (Exception ex)
{
Response.Write("ERR");
}
本想应该会运行Response.Write("资源已经释放啦!"),可是结果相反,它的引用依然存在.这让我不解,后来得到园友jyk的指点,他让我试下,.net下实现了dispose方法的类,我就用Stream试了下,测试结果好下:
Code：
Stream _s = this.FileUpload1.PostedFile.InputStream;
//客户端文件大小 为了判断对象是否被销毁
long orgLength = _s.Length;
_s.Dispose();
try
{
if (_s == null)
{
Response.Write("资源已经释放啦!");
}
else
{
Response.Write(_s.GetType().ToString());
//客户端文件大小 此处为释放资源后
//运行结果表明,此时的文件流的大小是0
//说明资源已经成功释放
long _length= _s.Length;
}
}
catch (Exception ex)
{
Response.Write("ERR");
}
运行结果我们可以非常清楚的看出,Stream资源已经被释放,因为两次访问Stream的大小,发现在dispose后的大小为零.这就好像是第一次初始化的结果.但Stream属于非托管资源,如果是托管资源呢?在Foo的测试代码中发现,释放前后的变量(m_disposed,调用Dispose前为false,调用后为true,而且还可以调用类的方法)发生了变化,并不是我想象当中的初始化.这是让我一直不解的地方.
后来在资料书上看,发现IDisposable接口是专门针对未托管资源而设计的.它在托管资源上没有特别大的帮助.最终的资源回收工作还得要GC.我们看下托管资源和非托管资源在内存上的分配情况.
非常感谢 Angel Lucifer的指教,本人见笑了 特此删除:
值类型与引用类型在内存分配上的分别:
值类型存储在堆栈中,堆栈的工作原理就是先进后出.它在释放资源的顺序上与定义变量时分配内存的顺序相反.值变量一旦出了作用域就会从堆栈中删除对象.
引用类型则存储在堆中.,当new一个类时,此时就会为对象分配内存存入托管堆中,它可以在方法退出很长的时间后仍然可以使用.我以一句常用的实例类的语句来说明下.
classA a=new classA();
这句非常平常的语句其实可以分成两部分来看:
第一:classA a;声明一个classA的引用a,在堆栈上给这个引用分配存储空间.它只是个引用,并不是真正的对象.它包含存储对象的地址.
第二:a=new classA();分配堆上的内存,以存储真正的对象.然后修改a的值为新对象的内存地址.
当引用出了作用域后,就会从堆栈上删除引用,但引用对象的数据仍然存储在托管堆中,一直到程序停止,或者是GC删除.
所在这点就可以解释我上面写的Foo类在调用Dispose方法后,程序仍然可以访问对象的原因了.
非常感谢 Angel Lucifer的指教 特此更正如下:
这种情况完全是因为GC回收操作的不可预测性导致的。GC Heap上的对象生存期完全看GC是否要回收它而决定。此外，值类型完全没必要实现 IDisposable 接口。
总结:
如果你的类中没有用非托管资源,或者是非常大的实例（象 GIS 中的Geometry）， 就没有太大的必要实现这个接口. 并不是实现了这样的接口就说明你写的类有多大的不同或者会带来多大的性能优势.
