标签：
知道类型如何实现dispose模式之后，接下来看一下开发人员怎样使用提供了dispose模式的类型。这里不再讨论前面的SafeHandle类，而是讨论更常用的FileStream类。
可以利用FileStream打开一个文件，从文件中读取字节，向文件中写入字节，并关闭文件。一个FileStream对象在构造时，它会调用Win32 CreateFile函数，函数返回的句柄保存在SafeFileHandle中，然后通过FileStream对象的一个私有字段来维护运载该对象的引用，FileStream还提供了额外的几个属性(例如：Length,Position，CanRead等)和方法(例如：Read，Write,Flush等)。
假设要写代码来创建一个临时文件，并向其中写入一些字节，然后再删除该文件。开始可能会像下面这样写代码：
遗憾的是生成并运行上面的代码，它也许能工作，但是大多数情况下是不能的，问题是File的Delete方法要求Window删除一个仍然打开的文件。所以Delete方法抛出一个IOException异常.
但在某些情况下，文件可能“误打误撞”地被删除！如果另外一个线程不知怎么造成一次垃圾回收，而且这次垃圾回收刚好在调用Write之后、调用Delete之前发生，那么FileStream的SafeFileHandle字段的Finalize方法就会被调用，这回关闭文件，随后Delete操作也能正常运行。发生这种情况的概率非常小，上面代码无法运行的可能性在99%以上。
幸好FileStream实现了Dispose模式，所以可以修改代码来显示额关闭文件。下面是修改之后的源代码：
static void Main(string[] args)
{
Byte[] byteWrite = new Byte[] { 1, 2, 3, 4, 5 };
FileStream fs = new FileStream("Temp.dat", FileMode.Create);
fs.Write(byteWrite, 0, byteWrite.Length);
fs.Dispose();
File.Delete(@"d:\用户目录\我的文档\visual studio 2010\Projects\ConsoleApplication1\ConsoleApplication1\bin\Debug\Temp.dat");
}
上面代码唯一的区别是添加了FileStream的dispose方法的调用。Dispose方法的调用接受一个boolen参数的dispose方法，后者在safehandle对象上调用dispose方法，该方法调用win 32的closeHandle函数，造成Windows关闭文件，然后调用File的Delete方法时，Window发现该文件已经关闭，所以成功的删除它。由于FileStream还提供了一个Close方法，所提也可以用Close方法关闭。
注意：Close方法不是dispose类正式的一部分，有的提供了Close方法，有的没有。
需要注意的是，调用Dispose或Close只是为了能在一个确定的事件强迫对象执行清理；这两个方法并不能控制托管堆中的对象所占用的内存的生存期。这意味着即使一个对象已经完成清理，扔可在它上面调用方法。以下代码演示了关闭后调用Write方法，试图想文件写入更多的字节，显示，这个字节再无法写入文件。代码执行时，对Write方法的第二个调用将抛出一个System.ObjectDisposedException异常，并显示以下字符创：无法访问已关闭的文件。
这里不会出现内存的损坏情况，因为FileStream对象的内存依然“健在”。只是在执行了清理之后，对象不能再成功的执行它的方法。
重要提示：我不赞成无脑的调用dispose和close方法。理由是CLR的垃圾回收期已经做得非常好了，理应把工作要给它去做。垃圾回收期知道一个对象何时不再调用应用程序的代码，而且只有到那个时候才会回收，而当应用程序调用dispose或Close方法时，实际实在信誓旦旦的说它知道应用程序在什么时候不需要一个对象，但对于应用程序来说，都不可能知道一个对象在什么时候不需要。
例如：假定在方法A的代码中构造一个新对象，然后将对该对象的引用传给方法B，方法B可能将对该对象的引用保存在某个内部字段变量中（一个根）。然而，方法A并不知道这个情况，它当然可以调用dispose和close方法，但在此之后，其它代码可能试图访问该对象，造成跑出一个ObjectDisposedException。
建议只有在以下这两种情况下才调用dispose或close:确定必须清理资源，或者确定可以安全的调用dispose或close，并希望将对象从终结列表中删除，禁止对象提供到另一代，从而提升性能。
标签：
原文地址：http://www.cnblogs.com/bingbinggui/p/4401098.html
