.net内存回收与Dispose﹐Close﹐Finalize方法2

5.看下面这个例子
using System;
using System.IO;

public class TestFileStream
...{
public static void Main(string[] args)
...{
//创建一个FileStream对象
FileStream fs = new FileStream(@"C: est.txt", FileMode.OpenOrCreate);
Console.WriteLine("您可以尝试在系统中删除c盘下的test.txt(回车键继续)");
//暂停程序执行﹐并尝试在系统中删除那个文件
Console.ReadLine();

/**//**//**//*进行垃圾收集*/
GC.Collect();
Console.WriteLine("再删一下试试");
Console.ReadLine();
}
}6.注意中间那行代码:
GC.Collect();
这是强制要.net垃圾收集器进行垃圾收集。
我们再去尝试删除test.txt﹐居然可以被删除了﹐为什么呀?(fs不是没有关闭那个SafeFileHandle吗?)﹐让我细细道来﹕

7.我们首先了解一下.net垃圾收集器进行垃圾收集的四种时机(参见﹕.net框架程序设计 李建忠译)
a.最常见的﹕当.net觉得合适时﹐例如它感到内存紧张了(朮语称为﹕0代对象充满)
b.微软强烈不建议使用的﹕GC的Collect方法调用(就是我们上面用的这种啦﹐因为会降低性能﹐会挂起进程, 等等﹐反正听微软的吧。当然某些时候可以用﹐就像我上面用来测试的代码﹐呵呵...)
c.应用程序域卸载时(AppDomain)
d.CLR被关闭时

8.现在我们可以明白第1个例子为什么在程序结束后文件可以被删除﹐因为CLR被关闭时﹐.net执行了垃圾收集(也就是等同于第二个例子的GC.Collect()代码)

9.所以现在所有的问题都集中到垃圾收集上面﹐它做了什么?

a.垃圾收集器在判断一个对象不会再被引用到后﹐就开始对它进行垃圾收集(即回收内存)
b.清空内存(即把托管堆中的内存收回来)
c.但是对象的有些字段引用到了非托管资源怎么办?如FileStream的_handle
d.所以我们必须告诉垃圾收集器﹐在你回收我的内存之前﹐先帮我执行一个方法来收回我的非托管资源﹐以免托管堆的内存被你回收了﹐而我引用的非托管资源的内存却被泄漏了。
e.这个方法就是Finalize()﹐也就是C#的 ~ClassName() 方法(同C++中的析构语法)
f.所以一个对象如果存在Finalize方法时﹐垃圾收集器在收回它的内存之前就会自动调用这个方法
g.这样我们就可以把那些东东(非托管资源)给清理干净了

由此看来﹐垃圾收集器提供的这种机制就是为了更好的完善.net的自动内存管理的功能﹐让我们也可以参与到垃圾收集中去

10.我们再来看看GC.Collect()这行代码或CLR关闭时.Net做了什么﹕
a.垃圾收集器启动﹐发现fs引用的那个对象已经没用了(当然CLR关闭时才不管你有没有用﹐通通回收)﹐于是对它进行内存回收
b.发现fs的类型﹕FileStream提供了Finalize方法﹐于是先调用这个方法
(以下通过Reflector继续)
c.Finalize方法中有 this._handle.Dispose()代码﹐于是调用SafeHandler.Dispose()
d.接着转到(当然好多个圈﹐您悠着点...)SafeFileHandle.ReleaseHandle方法﹐发现代码﹕Win32Native.CloseHandle() (即关闭非托管资源--文件HANDLE)

真相大白﹕原来是垃圾收集器帮我们关闭了那个非托管资源(当然还是通过我们自己写的Finalize方法)﹐因此后面就可以删除文件了。

11.有人会问﹕好像我们平时在使用FileStream对象时﹐没这么复杂呀?
答﹕Very Good!

一部分人﹕是因为大家都和我的例1一样有好运气﹐那个C盘下的test.txt文件自从被创建后﹐我压根就不会再去用它﹐管它这部分资源有没有被泄漏﹐有没有被锁定﹐最后程序结束时﹐被垃圾收集器帮了忙﹐把忘了关闭的文件HANDLE给收回来了。

剩下的一部分人﹕在程序里埋下了一颗"哑弹"﹐不知什么时候会爆炸﹐就像我例子中的File.Delete方法就出现了异常。

(不过我觉得)绝大多数人﹕是在看了很多诸如.net编程忠告﹐Microsoft强烈建议﹐MSDN标准做法等等等等( 还有我这篇blog﹐呵呵)之后﹐知道了在使用如FileStream,SqlConnection这些东东时﹐必须将其Close。

12.Close与Dispose
查看我们那两个例子的代码﹐都是不标准的﹐正确做法应该在使用完那个FileStream后﹐调用fs.Close()将其关闭﹐以保证资源的安全。

附﹕正确做法
using System;
using System.IO;

public class TestFileStream
...{
public static void Main(string[] args)
...{
//创建一个FileStream对象
FileStream fs = new FileStream(@"C: est.txt", FileMode.OpenOrCreate);

/**//**//**//*在用完FileStream后关闭*/
fs.Close();
//删除文件测试
try
...{
File.Delete(@"c: est.txt");
}
catch (IOException ex)
...{
Console.WriteLine("[Error]程序删除文件失败﹕{0}", ex.Message);
}
}
13.有人举手﹐讲这么多﹐早告诉我调用fs.Close不就得了。
哥们﹐fs.Close()方法是由您写的﹐调不调用﹐手在您身上﹐您不调用的话﹐哪天程序出了问题﹐您有会叫﹕微软真垃圾﹐.net真不稳定﹐还是java好﹐安全﹐可靠... 为防您的国骂﹐MS只好在垃圾收集中加这一款﹐以防不测...

14.Dispose模式
认真查看.net类库中的那些基本类别﹐凡是有Finalize方法的类别﹐基本上都提供了诸如Dispose,Close,Dispose(bool)等方法(FileStream也不例外)

15.其实不管是Dispose,Close,Finalize方法﹐最终应该都是执行相同的代码
区别﹕
Finalize方法﹕只能由微软调用
Dispose和Close方法﹕提供给您调用
因此在您使用完那些类别后﹐那就直接调用Close吧(没有Close﹐再调用Dispose方法)﹐当然万一您忘了﹐也别担心﹐还有垃圾收集器帮您垫后。

七.第二个结论﹕
1.在您开发一个封装非托管资源(即类中的字段引用到了非托管资源)的类别时﹕
A:强烈建议您提供Finalize方法进行非托管资源的释放﹐.net垃圾收集器不会帮您自动回收那部分资源﹐而是通过调用您的Finalize方法来帮您释放。(这样可以保证﹕在使用您类别的那位程序员忘了手动回收内存时﹐还可通过垃圾收集器来补救)

B.强烈建议您提供一个Close或Dispose方法﹐以便使用您类别的程序员可以手动释放您的类别中的非托管资源。(参见.net框架程序设计 自动内存管理一章实现Dispose模式)

C.如果类别封装了像FileStream这样的对象(即对非托管资源的再次封装)时﹐一般也应该提供一 个Close或Dispose方法﹐除非您的这个成员保证在每次使用后﹐都被正常的关闭﹐即对调用者透明。

2.在您使用一个封装非托管资源的类别时﹕
A:强烈建议您在明确知道这个类别没有用之后﹐调用其提供的Close或Dispose方法手动释放其非托管资源的 内存。有道是﹕有借有还﹐再借不难;借了不还﹐再借休想~~

B:注意在手动释放后﹐不要再调用该对象的相关方法了﹐因为对象已经损毁了

再次BTW:不管是Finalize﹐Close还是Dispose﹐您都无法显式释放托管堆内存﹐它们永远是微软的"私人财产 "﹕)

有人议论：

.net 不要把对象 = null 的;
一位在一般情况下.net的的一个变量如
FileStream fs = new FileStream(@"C:/test.txt", FileMode.OpenOrCreate);

这个 fs 类似c 语言里的指针，只是一个地址而已
= null 是没啥用的

如果等于null 反倒影响gc 回收了

还有.net Windows 程序
和 ASP.NET 下 GC 的回收也许会有些不同
所以一个这样的列子不会完全说明问题的。

还有如个cpu占有率比较高的情况下 GC 也许回收对象很慢
要比正常情况下慢很多。

原则上还是、能 Dispose 的类就要 Dispose
类似FileStream 的对象如果不在后面的代码中使用，不用 close 直接
Dispose 即可，Dispose 隐含 close 的其实
数据连接对象也是推荐使用 using 代码块自动释放以防止中途出现异常