.NET中的内存管理，GC机制，内存释放过程

引言

作为一个.NET程序员，我们知道托管代码的内存管理是自动的。.NET可以保证我们的托管程序在结束时全部释放，这为我们编程人员省去了不少麻烦，我们可以连想都不想怎么去管理内存，反正.NET自己会保证一切。好吧，有道理，有一定的道理。问题是，当我们用到非托管资源时.NET就不能自动管理了。这是因为非托管代码不受CLR（Common Language Runtime）控制，超出CLR的管理范围。那么如何处理这些非托管资源呢，.NET又是如何管理并释放托管资源的呢？

---

自动内存管理和GC

在原始程序中堆的内存分配是这样的：找到第一个有足够空间的内存地址（没被占用的），然后将该内存分配。当程序不再需要此内存中的信息时程序员需要手动将此内存释放。堆的内存是公用的，也就是说所有进程都有可能覆盖另一进程的内存内容，这就是为什么很多设计不当的程序甚至会让操作系统本身都down掉。我们有时碰到的程序莫名其妙的死掉了（随机现象），也是因为内存管理不当引起的（可能由于本身程序的内存问题或是外来程序造成的）。另一个常见的实例就是大家经常看到的游戏的Trainer，他们通过直接修改游戏的内存达到"无敌"的效果。明白了这些我们可以想象如果内存地址被用混乱了的话会多么危险，我们也可以想象为什么C++程序员（某些）一提起指针就头疼的原因了。另外，如果程序中的内存不被程序员手动释放的话那么这个内存就不会被重新分配，直到电脑重起为止，也就是我们所说的内存泄漏。所说的这些是在非托管代码中，CLR通过AppDomain实现代码间的隔离避免了这些内存管理问题，也就是说一个AppDomain在一般情况下不能读/写另一AppDomain的内存。托管内存释放就由GC（Garbage Collector）来负责。我们要进一步讲述的就是这个GC，但是在这之前要先讲一下托管代码中内存的分配，托管堆中内存的分配是顺序的，也就是说一个挨着一个的分配。这样内存分配的速度就要比原始程序高，但是高出的速度会被GC找回去。为什么？看过GC的工作方式后你就会知道答案了。

---

GC工作方式

首先我们要知道托管代码中的对象什么时候回收我们管不了（除非用GC.Collect强迫GC回收，这不推荐，后面会说明为什么）。GC会在它"高兴"的时候执行一次回收（这有许多原因，比如内存不够用时。这样做是为了提高内存分配、回收的效率）。那么如果我们用Destructor呢？同样不行，因为.NET中Destructor的概念已经不存在了，它变成了Finalizer，这会在后面讲到。目前请记住一个对象只有在没有任何引用的情况下才能够被回收。为了说明这一点请看下面这一段代码：

[C#]
object objA = new object();
object objB = objA;
objA = null;
// 强迫回收。
GC.Collect();
objB.ToString(); 

[Visual Basic]
Dim objA As New Object()
Dim objB As Object = objA
objA = Nothing
' 强迫回收。 
GC.Collect()
objB.ToString() 

这里objA引用的对象并没有被回收，因为这个对象还有另一个引用，ObjB。

对象在没有任何引用后就有条件被回收了。当GC回收时，它会做以下几步：

确定对象没有任何引用。

检查对象是否在Finalizer表上有记录。

如果在Finalizer表上有记录，那么将记录移到另外的一张表上，在这里我们叫它Finalizer2。

如果不在Finalizer2表上有记录，那么释放内存。

在Finalizer2表上的对象的Finalizer会在另外一个low priority的线程上执行后从表上删除。当对象被创建时GC会检查对象是否有Finalizer，如果有就会在Finalizer表中添加纪录。我们这里所说的记录其实就是指针。如果仔细看这几个步骤，我们就会发现有Finalizer的对象第一次不会被回收，也就是，有Finalizer的对象要一次以上的Collect操作才会被回收，这样就要慢一步，所以作者推荐除非是绝对需要不要创建Finalizer。为了证明GC确实这么工作而不是作者胡说，我们将在对象的复活一章中给出一个示例，眼见为实，耳听为虚嘛！^_^

GC为了提高回收的效率使用了Generatio