.net的GC机制有两个问题：首先GC并不能释放所有资源，它更不能释放非托管资源。其次，GC也不是实时的，所有GC存在不确定性。
为了解决这个问题donet提供了析构函数
public class TestClass : System.IDisposable{ //供程序员显式调用的Dispose方法 public void Dispose() { //调用带参数的Dispose方法，释放托管和非托管资源 Dispose(true); //手动调用了Dispose释放资源，那么析构函数就是不必要的了，这里阻止GC调用析构函数 System.GC.SuppressFinalize(this); } //protected的Dispose方法，保证不会被外部调用。 //传入bool值disposing以确定是否释放托管资源 protected void Dispose(bool disposing) { if (disposing) { ///TODO:在这里加入清理"托管资源"的代码，应该是xxx.Dispose(); } ///TODO:在这里加入清理"非托管资源"的代码 } //供GC调用的析构函数 ~TestClass() { Dispose(false);//释放非托管资源 }}
而即使我们忘记了在合适的时候调用Dispose，GC也会在释放对象的时候帮我们清理非托管资源的。GC所充当的角色只是一种保障手段，它应该充当这种角色，我们不能过分依赖它。实际上，在较大的模块退出时我们还应该及时地手动调用GC.Collect进行垃圾回收。
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方法能够被调用到，确保可以手动释放任何需要释放的资源。http://www.cnblogs.com/suningnet/archive/2010/06/12/1757447.html