.Net 垃圾收集（Garbage Collection）

 

.Net 垃圾收集（Garbage Collection）

垃圾收集（Garbage Collection）

5.1 什么是垃圾收集？ 垃圾收集是一种由运行时组件负责管理对象生命期以及它们所占用的堆内存（heap memory）的系统。对于.NET来说，这并不是什么新东西，Java以及很多其它语言/运行时使用垃圾收集机制已经有那么一段时间了。 5.2 当对象最后一个引用被解除时，它也并不总是立即被销毁，真的吗？ 没错。对于对象的销毁以及它所占用的内存的回收时机，垃圾收集器没有提供任何担保。 在档案库里有一个有意思的线索，由Chris Sells发起，是关于C#中对象的非确定性销毁的： http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R24819 2000年十月，微软Brian Harry投递了对这个问题的长篇分析： http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572 可在这儿看到Chris Sells对Brian贴子的应答： http://discuss.develop.com/archives/wa.exe?A2=ind0010C&L=DOTNET&P=R983 5.3 为什么.NET运行时不提供确定性的销毁机制？ 这要归因于垃圾收集算法。.NET垃圾收集器的工作机理是，周期性地遍历被应用当前引用的所有对象的列表。在这个搜索过程中，凡是没有发现的对象，都将准备予以销毁，它们占用的内存也将被收回。这种算法暗示当对象的最后一个引用也被解除时，运行时并不会立即接到通知，只有下一次对堆（heap）进行清扫时，才能发现这个情况。 进一步而言，执行垃圾收集清扫次数越少，这类算法工作得越好。通常来说，堆的耗尽是收集清扫的触发条件。 5.4 缺乏确定性的销毁机制在.NET中成个问题吗？ 当然是个问题，它影响了组件的设计。假如你的对象持有代价昂贵或稀缺的资源（比如数据库锁），你应该提供某种办法，使得客户程序可以在完事时，告诉对象释放掉这些资源。微软建议你提供一个叫Dispose()的方法来达到这个目的。然而，对于分布式对象来说，这将会导致问题。在一个分布式的系统中，谁来调用Dispose()方法？需要有某种形式的引用计数机制或所有权管理机制，来操纵分布式对象，不幸的是，运行时对此没有提供任何帮助。 5.5 非确定性销毁机制对从托管代码（managed code）中使用COM对象有影响吗？ 是的。当在托管代码中使用COM对象时，你大大依赖于垃圾收集器来调用终结方法，以释放你的对象。假如你的COM对象持有一个代价高昂的资源，而它只能在最终释放时得以清除的话，你可能要为你的对象提供一个新的接口，从而支持显式的Dispose()方法。 5.6 我听说应该避免使用Finalize方法，我应该在我的类里实现Finalize方法吗？ 一个具有Finalize方法的对象比没有这个方法的对象更适合于垃圾收集器。不存在关于对象终结顺序的保证，因此，从Finalize方法中去存取别的对象是有问题的。最后，不存在对一个对象调用Finalize方法的任何担保，因此，永远都不应该依赖它来清除对象所占用的资源。 微软推荐如下解决模式： public class CTest : IDisposable { public void Dispose() { ... // Cleanup activities GC.SuppressFinalize(this); } ~CTest() // C# syntax hiding the Finalize() method { Dispose(); } } 通常情况下，客户调用Dispose()，对象的资源得到了释放，垃圾收集器通过调用SuppressFinalize()，以免除履行终结义务。在最坏的情况下，也就是说，在客户忘记调用Dispose()的情况下，就有一个合情合理的机会，通过垃圾收集器对Finalize()的调用，对象的资源将最终得到释放。鉴于垃圾收集算法的局限性，这看起来象是一个相当合理的办法。 5.7 我能对垃圾收集算法作些控制吗？ 一点点。举例来说，System.GC类暴露了一个Collect方法，它强迫垃圾收集器立即去收集所有不再被引用的对象。 5.8 我怎么才能看出来垃圾收集器正在干些什么事？ 许多有意思的统计结果经由“.NET CLR xxx”性能计数器从.NET运行时输出，可以使用性能监视器来查看它们。