在标准的Dispose模式中，真正的IDisposable接口的Dispose方法并没有做实际的清理工作，它其实是调用了下面的这个带bool参数且受保护的的虚方法：
protected virtual void Dispose(bool disposing)
之所以提供这样一个受保护的虚方法，是因为考虑了这个类型会被其他类型继承的情况。如果类型存在一个子类，子类也许会实现自己的Dispose模式。受保护的虚方法用来提醒子类：必须在自己的清理方法时注意到父类的清理工作，即子类需要在自己的释放方法中调用base.Dispose方法。
如果不为类提供这个受保护的虚方法，很有可能让开发者设计子类的时候忽略掉父类的清理工作。所以要在类型的Dispose模式中提供一个受保护的虚方法
Finalize 和Dispose(bool disposing)和 Dispose()
相同点:
这三者都是为了释放非托管资源服务的
不同点:
- Finalize是CRL提供的一个机制, 它保证如果一个类实现了Finalize方法,那么当该类对象被垃圾回收时,垃圾回收器会调用Finalize方法.而该类的开发者就必须在Finalize方法中处理 非托管资源的释放. 但是什么时候会调用Finalize由垃圾回收器决定,该类对象的使用者(客户)无法控制.从而无法及时释放掉宝贵的非托管资源.由于非托管资源是比较宝贵了,所以这样会降低性能.
- Dispose(bool disposing)不是CRL提供的一个机制, 而仅仅是一个设计模式(作为一个IDisposable接口的方法),它的目的是让供类对象的使用者(客户)在使用完类对象后,可以及时手动调用非托管资源的释放,无需等到该类对象被垃圾回收那个时间点.这样类的开发者就只需把原先写在Finalize的释放非托管资源的代码,移植到Dispose(bool disposing)中. 而在Finalize中只要简单的调用 "Dispose(false)"(为什么传递false后面解释)就可以了.
为什么还需要一个Dispose()方法?难道只有一个Dispose(bool disposing)或者只有一个Dispose()不可以吗?
只有一个Dispose()不可以. 为什么呢?因为如果只有一个Dispose()而没有Dispose(bool disposing)方法.那么在处理实现非托管资源释放的代码中无法判断该方法是客户调用的还是垃圾回收器通过Finalize调用的.无法实现 判断如果是客户手动调用,那么就不希望垃圾回收器再调用Finalize()(调用GC.SupperFinalize方法).另一个可能的原因(:我们知道如果是垃圾回收器通过Finalize调用的,那么在释放代码中我们可能还会引用其他一些托管对象,而此时这些托管对象可能已经被垃圾回收了, 这样会导致无法预知的执行结果(千万不要在Finalize中引用其他的托管对象).
所以确实需要一个bool disposing参数, 但是如果只有一个Dispose(bool disposing),那么对于客户来说,就有一个很滑稽要求,Dispose(false)已经被Finalize使用了,必须要求客户以Dispose(true)方式调用,但是谁又能保证客户不会以Dispose(false)方式调用呢?所以这里采用了一中设计模式:重载 把Dispose(bool disposing)实现为 protected, 而Dispose()实现为Public,那么这样就保证了客户只能调用Dispose()(内部调用Dispose(true)//说明是客户的直接调用),客户无法调用Dispose(bool disposing).
托管资源、非托管资源
资源分为两种：
托管的内存资源，这是不需要我们操心的，系统已经为我们进行管理了；
非托管的资源，这里再重申一下，就是Stream，数据库的连接，GDI+的相关对象，还有Com对象等等这些资源，需要我们手动去释放。
托管资源的回收工作：是不需要人工干预回收的，而且你也无法干预他们的回收，所能够做的只是了解.net CLR如何做这些操作。也就是说对于您的应用程序创建的大多数对象，可以依靠 .NET Framework 的垃圾回收器隐式地执行所有必要的内存管理任务。
像简单的int,string,float,DateTime等等，.net中超过80%的资源都是托管资源。
对于非托管资源，您在应用程序中使用完这些非托管资源之后，必须显示的释放他们，例如System.IO.StreamReader的一个文件对象，必须显示的调用对象的Close()方法关闭它，否则会占用系统的内存和资源，而且可能会出现意想不到的错误。
例如文件，窗口或网络连接，对于这类资源虽然垃圾回收器可以跟踪封装非托管资源的对象的生存期，但它不了解具体如何清理这些资源。还好.net Framework提供了Finalize()方法，它允许在垃圾回收器回收该类资源时，适当的清理非托管资源。
列举几种常见的非托管资源：ApplicationContext,Brush,Component,ComponentDesigner,Container,
Context,Cursor,FileStream,Font,Icon,Image,Matrix,Object,OdbcDataReader,OleDBDataReader,Pen,Regex,Socket,StreamWriter,Timer,Tooltip 等等资源。
非托管资源如何释放？
，.NET Framework 提供 Object.Finalize 方法，它允许对象在垃圾回收器回收该对象使用的内存时适当清理其非托管资源。默认情况下，Finalize 方法不执行任何操作。
在定义一个类时，可以使用两种机制来自动释放未托管的资源。这些机制常常放在一起实现，因为每个机制都为问题提供了略为不同的解决方法。这两个机制是：
● 声明一个析构函数，作为类的一个成员：构造函数可以指定必须在创建类的实例时进行的某些操作，在垃圾收集器删除对象时，也可以调用析构函数。由于执行这个操作，所以析构函数初看起来似乎是放置释放未托管资源、执行一般清理操作的代码的最佳地方。但是，事情并不是如此简单。由于垃圾回首器的运行规则决定了，不能在析构函数中放置需要在某一时刻运行的代码，如果对象占用了宝贵而重要的资源，应尽可能快地释放这些资源，此时就不能等待垃圾收集器来释放了．
利用运行库强制执行的析构函数，但析构函数的执行是不确定的，而且，由于垃圾收集器的工作方式，它会给运行库增加不可接受的系统开销。
● 在类中实现System.IDisposable接口：推荐替代析构函数的方式是使用System.IDisposable接口。IDisposable接口定义了一个模式(具有语言级的支持)，为释放未托管的资源提供了确定的机制，并避免产生析构函数固有的与垃圾函数器相关的问题。IDisposable接口声明了一个方法Dispose()，它不带参数，返回void
Dispose()的执行代码显式释放由对象直接使用的所有未托管资源，并在所有实现IDisposable接口的封装对象上调用Dispose()。这样，Dispose()方法在释放未托管资源时提供了精确的控制。
IDisposable接口提供了一种机制，允许类的用户控制释放资源的时间，但需要确保执行Dispose()。
一般情况下，最好的方法是执行这两种机制，获得这两种机制的优点，克服其缺点。假定大多数程序员都能正确调用Dispose()，实现IDisposable接口，同时把析构函数作为一种安全的机制，以防没有调用Dispose()。
对于某些类来说，使用Close()要比Dispose()更富有逻辑性，例如，在处理文件或数据库连接时，就是这样。在这些情况下，常常实现 IDisposable接口，再执行一个独立的Close()方法，来调用Dispose()。这种方法在类的使用上比较清晰，还支持C#提供的 using语句。
public class ResourceHolder : IDisposable { private bool isDispose ＝ false; // Pointer to an external unmanaged resource. private IntPtr handle; // Other managed resource this class uses. private Component Components; // 显示调用的Dispose方法 public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } // 实际的清除方法 protected virtual void Dispose(bool disposing) { if (!isDisposed) { if (disposing) { // 这里执行清除托管对象的操作. } // 这里执行清除非托管对象的操作 CloseHandle(handle); handle = IntPtr.Zero; } isDisposed=true; } // 析构函数 ~ResourceHolder() { Dispose (false); } }
Dispose()有第二个protected重载方法，它带一个bool参数，这是真正完成清理工作的方法。Dispose(bool)由析构函数和IDisposable.Dispose()调用。这个方式的重点是确保所有的清理代码都放在一个地方。
传递给Dispose(bool)的参数表示Dispose(bool)是由析构函数调用，还是由IDisposable.Dispose()调用——Dispose(bool)不应从代码的其他地方调用，其原因是：
● 如果客户调用IDisposable.Dispose()，该客户就指定应清理所有与该对象相关的资源，包括托管和非托管的资源。
● 如果调用了析构函数，在原则上，所有的资源仍需要清理。但是在这种情况下，析构函数必须由垃圾收集器调用，而且不应访问其他托管的对象，因为我们不再能确定它们的状态了。在这种情况下，最好清理已知的未托管资源，希望引用的托管对象还有析构函数，执行自己的清理过程。
isDispose成员变量表示对象是否已被删除，并允许确保不多次删除成员变量。这个简单的方法不是线程安全的，需要调用者确保在同一时刻只有一个线程调用方法。要求客户进行同步是一个合理的假定，
IDisposable.Dispose()包含一个对System.GC. SuppressFinalize()方法的调用。SuppressFinalize()方法则告诉垃圾收集器有一个类不再需要调用其析构函数了。因为 Dispose()已经完成了所有需要的清理工作，所以析构函数不需要做任何工作。调用SuppressFinalize()就意味着垃圾收集器认为这个对象根本没有析构函数．
托管资源：是指由CLR管理分配和释放的资源，一般是托管内存
托管资源:从文字上看就是托付给别人管理，就像.NET的CLR，java的jvm
Net平台中，CLR为程序员提供了一种很好的内存管理机制，使得程序员在编写代码时不要显式的去释放自己使用的内存资源（这些在先前C和C++中是需要程序员自己去显式的释放的）。这种管理机制称为GC(garbage collection)。GC的作用是很明显的，当系统内存资源匮乏时，它就会被激发，然后自动的去释放那些没有被使用的托管资源（也就是程序员没有显式释放的对象）。
就是.net framework 负责帮你管理内存及资源释放，不需要自己控制，当然对象只针对托管资源（部分引用类型）, 不回收非托管资源。 像数组，用户定义的类、接口、委托，object，字符串等引用类型，栈上保存着一个地址而已，当栈释放后， 即使对象已经没有用了，但堆上分配的内存还在，只能等GC收集时才能真正释放 ；但注意int,string,float,DateTime之类的值类型，GC会自动释放他们占用的内存，不需要GC来回收释放
非托管资源：是由系统分配和释放的资源
一般地在CLR里new 一个对象或者分配一个数组都不需要手动去释放内存，
而如windows里的句柄资源常常需要手动释放，如字体、刷子、DC等 所有的Window内核对象（句柄）都是非托管资源，如文件句柄、套接字句柄、窗体句柄……；例如文件流，数据库的连接，系统的窗口句柄，打印机资源等等，当你读取文件之后，就需要对各种Stream进行Dispose等操作。比如 SqlDataReader 读取数据完毕之后，需要 reader.Dispose();等
new出来的对象占用的内存是托管资源。
对于非托管资源，GC只能跟踪非托管资源的生存期，而不知道如何去释放它。这样就会出现当资源用尽时就不能提供资源能够提供的服务，windows的运行速度就会变慢。比如当你链接了数据库，用完后你没有显式的释放数据库资源，如果还是不断的申请数据库资源，那么到一定时候程序就会抛出一个异常。
所以，当我们在类中封装了对非托管资源的操作时，我们就需要显式，或者是隐式的释放这些资源。在.Net中释放非托管资源主要有2种方式，Dispose，Finalize，而Finalize和Dispose方法分别就是隐式和显式操作中分别使用到的方法。
Finalize一般情况下用于基类不带close方法或者不带Dispose显式方法的类，也就是说，在Finalize过程中我们需要隐式的去实现非托管资源的释放，然后系统会在Finalize过程完成后，自己的去释放托管资源。
在.NET中应该尽可能的少用析构函数释放资源，MSDN2上有这样一段话:实现 Finalize 方法或析构函数对性能可能会有负面影响，因此应避免不必要地使用它们。用 Finalize 方法回收对象使用的内存需要至少两次垃圾回收。所以有析构函数的对象，需要两次，第一次调用析构函数，第二次删除对象。而且在析构函数中包含大量的释放资源代码，会降低垃圾回收器的工作效率，影响性能。
所以对于包含非托管资源的对象，最好及时的调用Dispose()方法来回收资源，而不是依赖垃圾回收器。