C＃锐利体验(五)

　　由于.NET平台的自动垃圾收集机制，C#语言中类的析构器不再如传统C++那么必要，析构器不再承担对象成员的内存释放--自动垃圾收集机制保证内存的回收。实际上C#中已根本没有delete操作！析构器只负责回收处理那些非系统的资源，比较典型的如：打开的文件，获取的窗口句柄，数据库连接，网络连接等等需要用户自己动手释放的非内存资源。我们看下面例子的输出：

　　编译程序并运行可以得到下面的输出：

　　其中程序中最后两句是保证类的析构器得到调用。GC.Collect()是强迫通用语言运行时进行启动垃圾收集线程进行回收工作。而GC.WaitForPendingFinalizers()是挂起目前的线程等待整个终止化（Finalizaion）操作的完成。终止化（Finalizaion）操作保证类的析构器被执行，这在下面会详细说明。

　　析构器不会被继承，也就是说类内必须明确的声明析构器，该类才存在析构器。用户实现析构器时，编译器自动添加调用父类的析构器，这在下面的Finalize方法中会详细说明。析构器由于垃圾收集机制会被在合适的的时候自动调用，用户不能自己调用析构器。只有实例析构器，而没有静态析构器。

　　那么析构器是怎么被自动调用的？这在 .Net垃圾回收机制由一种称作终止化（Finalizaion）的操作来支持。.Net系统缺省的终止化操作不做任何操作，如果用户需要释放非受管资源，用户只要在析构器内实现这样的操作即可--这也是C#推荐的做法。我们看下面这段代码：

　　而实际上，从生成的中间代码来看我们可以发现，这些代码被转化成了下面的代码：

　　实际上C#编译器不允许用户自己重载或调用Finalize方法--编译器彻底屏蔽了父类的Finalize方法（由于C#的单根继承性质，System.Object类是所有类的祖先类，自然每个类都有Finalize方法），好像这样的方法根本不存在似的。我们看下面的代码实际上是错的：

　　但下面的代码却是正确的：

　　实际上这里的Finalize方法已经彻底脱离了“终止化操作”的语义，而成为C#语言的一个一般方法了。值得注意的是这也屏蔽了父类System.Object的Finalize方法，所以要格外小心！

　　终止化操作在.Net运行时里有很多限制，往往不被推荐实现。当对一个对象实现了终止器（Finalizer）后，运行时便会将这个对象的引用加入一个称作终止化对象引用集的队列，作为要求终止化的标志。当垃圾收集开始时，若一个对象不再被引用但它被加入了终止化对象引用集的队列，那么运行时并不立即对此对象进行垃圾收集工作，而是将此对象标志为要求终止化操作对象。待垃圾收集完成后，终止化线程便会被运行时唤醒执行终止化操作。显然这之后要从终止化对象引用集的链表中将之删去。而只有到下一次的垃圾收集时，这个对象才开始真正的垃圾收集，该对象的内存资源才被真正回收。容易看出来，终止化操作使垃圾收集进行了两次，这会给系统带来不小的额外开销。终止化是通过启用线程机制来实现的，这有一个线程安全的问题。.Net运行时不能保证终止化执行的顺序，也就是说如果对象A有一个指向对象B的引用，两个对象都有终止化操作，但对象A在终止化操作时并不一定有有效的对象A引用。.Net运行时不允许用户在程序运行中直接调用Finalize()方法。如果用户迫切需要这样的操作，可以实现IDisposable接口来提供公共的Dispose()方法。需要说明的是提供了Dispose()方法后，依然需要提供Finalize方法的操作，即实现假托的析构函数。因为Dispose()方法并不能保证被调用。所以.Net运行时不推荐对对象进行终止化操作即提供析构函数，只是在有非受管资源如数据库的连接，文件的打开等需要严格释放时，才需要这样做。

　　大多数时候，垃圾收集应该交由.Net运行时来控制，但有些时候，可能需要人为地控制一下垃圾回收操作。例如在操作了一次大规模的对象集合后，我们确信不再在这些对象上进行任何的操作了，那我们可以强制垃圾回收立即执行，这通过调用System.GC.Collect() 方法即可实现，但频繁的收集会显著地降低系统的性能。还有一种情况，已经将一个对象放到了终止化对象引用集的链上了，但如果我们在程序中某些地方已经做了终止化的操作，即明确调用了Dispose()方法，在那之后便可以通过调用System.GC.SupressFinalize()来将对象的引用从终止化对象引用集链上摘掉，以忽略终止化操作。终止化操作的系统负担是很重的。

　　在深入了解了.NET运行时的自动垃圾收集功能后，我们便会领会C#中的析构器为什么绕了这么大的弯来实现我们的编程需求，才能把内存资源和非内存资源的回收做的游刃有余--这也正是析构的本原！

查看本文来源