详谈.net中的垃圾回收机制

1. 自动内存管理和gc
　　在原始程序中堆的内存分配是这样的：找到第一个有足够空间的内存地址（没被占用的），然后将该内存分配。当程序不再需要此内存中的信息时程序员需要手动将此内存释放。堆的内存是公用的，也就是说所有进程都有可能覆盖另一进程的内存内容，这就是为什么很多设计不当的程序甚至会让操作系统本身都down掉。我们有时碰到的程序莫名其妙的死掉了（随机现象），也是因为内存管理不当引起的（可能由于本身程序的内存问题或是外来程序造成的）。另一个常见的实例就是大家经常看到的游戏的trainer，他们通过直接修改游戏的内存达到"无敌"的效果。明白了这些我们可以想象如果内存地址被用混乱了的话会多么危险，我们也可以想象为什么c++程序员（某些）一提起指针就头疼的原因了。另外，如果程序中的内存不被程序员手动释放的话那么这个内存就不会被重新分配，直到电脑重起为止，也就是我们所说的内存泄漏。所说的这些是在非托管代码中，clr通过appdomain实现代码间的隔离避免了这些内存管理问题，也就是说一个appdomain在一般情况下不能读/写另一appdomain的内存。托管内存释放就由gc（garbage collector）来负责。我们要进一步讲述的就是这个gc，但是在这之前要先讲一下托管代码中内存的分配，托管堆中内存的分配是顺序的，也就是说一个挨着一个的分配。这样内存分配的速度就要比原始程序高，但是高出的速度会被gc找回去。为什么？看过gc的工作方式后你就会知道答案了。
2. gc工作方式
　　首先我们要知道托管代码中的对象什么时候回收我们管不了（除非用gc.collect**gc回收，这不推荐，后面会说明为什么）。gc会在它"高兴"的时候执行一次回收（这有许多原因，比如内存不够用时。这样做是为了提高内存分配、回收的效率）。那么如果我们用destructor呢？同样不行，因为.net中destructor的概念已经不存在了，它变成了finalizer，这会在后面讲到。目前请记住一个对象只有在没有任何引用的情况下才能够被回收。为了说明这一点请看下面这一段代码：

view sourceprint?object obja = new object(); 
object objb = obja; 
obja = null; 
// **回收。 
gc.collect(); 
objb.tostring();

　　这里obja引用的对象并没有被回收，因为这个对象还有另一个引用，objb。对象在没有任何引用后就有条件被回收了。
　　当gc回收时，它会做以下几步：
　　1、确定对象没有任何引用。
　　2、检查对象是否在finalizer表上有记录。如果在finalizer表上有记录，那么将记录移到另外的一张表上，在这里我们叫它finalizer2。如果不在finalizer2表上有记录，那么释放内存。在finalizer2表上的对象的finalizer会在另外一个low priority的线程上执行后从表上删除。当对象被创建时gc会检查对象是否有finalizer，如果有就会在finalizer表中添加纪录。我们这里所说的记录其实就是指针。如果仔细看这几个步骤，我们就会发现有finalizer的对象第一次不会被回收，也就是，有finalizer的对象要一次以上的collect操作才会被回收，这样就要慢一步，所以作者推荐除非是绝对需要不要创建finalizer。
　　gc为了提高回收的效率使用了generation的概念，原理是这样的，第一次回收之前创建的对象属于generation 0，之后，每次回收时这个generation的号码就会向后挪一，也就是说，第二次回收时原来的generation 0变成了generation 1，而在第一次回收后和第二次回收前创建的对象将属于generation 0。gc会先试着在属于generation 0的对象中回收，因为这些是最新的，所以最有可能会被回收，比如一些函数中的局部变量在退出函数时就没有引用了（可被回收）。如果在generation 0中回收了足够的内存，那么gc就不会再接着回收了，如果回收的还不够，那么gc就试着在generation 1中回收，如果还不够就在generation 2中回收，以此类推。generation也有个最大限制，根据framework版本而定，可以用gc.maxgeneration获得。在回收了内存之后gc会重新排整内存，让数据间没有空格，这样是因为clr顺序分配内存，所以内存之间不能有空着的内存。现在我们知道每次回收时都会浪费一定的cpu时间，这就是我说的一般不要手动gc.collect的原因。
　　当我们用destructor的语法时，编译器会自动将它写为protected virtual void finalize()，这个方法就是我所说的finalizer。就象它的名字所说，它用来结束某些事物，不是用来摧毁（destruct）事物。在visual basic中它就是以finalize方法的形式出现的，所以visual basic程序员就不用操心了。c#程序员得用destructor的语法写finalizer，不过千万不要弄混了，.net中已经没有destructor了。c++中我们可以准确的知道什么时候会执行destructor，不过在.net中我们不能知道什么时候会执行finalizer，因为它是在第一次对象回收操作后才执行的。我们也不能知道finalizer的执行顺序，也就是说同样的情况下，a的finalize可能先被执行，b的后执行，也可能a的后执行而b的先执行。也就是说，在finalizer中我们的代码不能有任何的时间逻辑。下面我们以计算一个类有多少个实例为示例，指出finalizer与destructor的不同并指出在finalizer中有时间逻辑的错误：

view sourceprint?public class countobject { 
  public static int count = 0; 
  public countobject() { 
    count++; 
  } 
  ~countobject() { 
    count--; 
  } 
} 
static void main() { 
  countobject obj; 
  for (int i = 0; i < 5; i++) { 
    obj = null; // 这一步多余，这么写只是为了更清晰些！ 
   obj = new countobject(); 
  } 
  // count不会是1，因为finalizer不会马上被触发，要等到有一次回收操作后才会被触发。 
  console.writeline(countobject.count); 
  console.readline(); 
}

　　注意以上代码要是改用c++写的话会发生内存泄漏，因为我们没有用delete操作符手动清理内存，但是在托管代码中却不会发生内存泄漏，因为gc会自动检测没有引用了的对象并回收。这里作者推荐你只在实现idisposable接口时配合使用finalizer，在其他的情况下不要使用（可能会有特殊情况）。
3. 对象的复活
　　什么？回收的对象也可以"复活"吗？没错，虽然这么说的定义不准确。让我们先来看一段代码：

view sourceprint?public class resurrection { 
  public int data; 
  public resurrection(int data) { 
    this.data = data; 
  } 
  ~resurrection() { 
    main.instance = this; 
  } 
} 
public class main { 
  public static resurrection instance; 
  public static void main() { 
    instance = new resurrection(1); 
    instance = null; 
    gc.collect(); 
    gc.waitforpendingfinalizers(); 
    // 看到了吗，在这里“复活”了。 
    console.writeline(instance.data); 
    instance = null; 
    gc.collect(); 
    console.readline(); 
  } 
}

　　你可能会问："既然这个对象能复活，那么这个对象在程序结束后会被回收吗？"。会，"为什么？"。让我们按照gc的工作方式走一遍你就明白是怎么回事了。
　　1、执行collect。检查引用。没问题，对象已经没有引用了。
　　2、创建新实例时已经在finalizer表上作了纪录，所以我们检查到了对象有finalizer。
　　3、因为查到了finalizer，所以将记录移到finalizer2表上。
　　4、在finalizer2表上有记录，所以不释放内存。
　　5、collect执行完毕。这时我们用了gc.waitforpendingfinalizers，所以我们将等待所有finalizer2表上的finalizers的执行。
　　6、finalizer执行后我们的instance就又引用了我们的对象。（复活了）
　　7、再一次去除所有的引用。
　　8、执行collect。检查引用。没问题。
　　9、由于上次已经将记录从finalizer表删除，所以这次没有查到对象有finalizer。
　　10、在finalizer2表上也不存在，所以对象的内存被释放了。
　　非托管资源的释放到现在为止，我们说了托管内存的管理，那么当我们利用如数据库、文件等非托管资源时呢？这时我们就要用到.net framework中的标准：idisposable接口。按照标准，所有有需要手动释放非托管资源的类都得实现此接口。这个接口只有一个方法，dispose()，不过有相对的guidelines指示如何实现此接口，在这里我向大家说一说。实现idisposable这个接口的类需要有这样的结构：

view sourceprint?public class base : idisposable { 
  public void dispose() { 
    this.dispose(true); 
    gc.supressfinalize(this); 
  } 
  protected virtual void dispose(bool disposing) { 
    if (disposing) { 
      // 托管类 
    } 
    // 非托管资源释放 
  } 
  ~base() { 
    this.dispose(false); 
  } 
} 
public class derive : base { 
  protected override void dispose(bool disposing) { 
    if (disposing) { 
      // 托管类 
    } 
    // 非托管资源释放 
    base.dispose(disposing); 
  } 
}

　　为什么要这样设计呢？让我在后面解说一下。现在我们讲讲实现这个dispose方法的几个准则：它不能扔出任何错误，重复的调用也不能扔出错误。也就是说，如果我已经调用了一个对象的dispose，当我第二次调用dispose的时候程序不应该出错，简单地说程序在第二次调用dispose时不会做任何事。这些可以通过一个flag或多重if判断实现。一个对象的dispose要做到释放这个对象的所有资源。拿一个继承类为例，继承类中用到了非托管资源所以它实现了idisposable接口，如果继承类的基类也用到了非托管资源那么基类也得被释放，基类的资源如何在继承类中释放呢？当然是通过一个virtual/overridable方法了，这样我们能保证每个dispose都被调用到。这就是为什么我们的设计有一个virtual/overridable的dispose方法。注意我们首先要释放继承类的资源然后再释放基类的资源。因为非托管资源一定要被保障正确释放所以我们要定义一个finalizer来避免程序员忘了调用dispose的情况。上面的设计就采用了这种形式。如果我们手动调用dispose方法就没有必要再保留finalizer了，所以在dispose中我们用了gc.supressfinalize将对象从finalizer表去掉，这样再回收时速度会更快。那么那个disposing和"托管类"是怎么回事呢？是这样：在"托管类"中写所有你想在调用dispose时让其处于可释放状态的托管代码。还记得我们说过我们不知道托管代码是什么时候释放的吗？在这里我们只是去掉成员对象的引用让它处于可被回收状态，并不是直接释放内存。在"托管类"中这里我们也要写上所有实现了idisposable的成员对象，因为他们也有dispose，所以也需要在对象的dispose中调用他们的dispose，这样才能保证第二个准则。disposing是为了区分dispose的调用方法，如果我们手动调用那么为了第二个准则"托管类"部分当然得执行，但如果是finalizer调用的dispose，这时候对象已经没有任何引用，也就是说对象的成员自然也就不存在了（无引用），也就没有必要执行"托管类"部分了，因为他们已经处于可被回收状态了。好了，这就是idisposable接口的全部了。现在让我们来回想一下，以前我们可能认为有了dispose内存就会马上被释放，这是错误的。只有非托管内存才会被马上释放，托管内存的释放由gc管理，我们不用管。
4. 弱引用的使用
　　 a = b，我们称这样的引用叫做强引用，gc就是通过检查强引用来决定一个对象是否是可以回收的。另外还有一种引用称作弱引用（weakreference），这种引用不影响gc回收，这就是它的用处所在。你会问到底有什么用处。现在我们来假设我们有一个很胖的对象，也就是说它占用很多内存。我们用过了这个对象，打算将它的引用去掉好让gc可以回收内存，但是功夫不大我们又需要这个对象了，没办法，重新创建实例，怎么创建这么慢啊？有什么办法解决这样的问题？有，将对象留在内存中不就快了嘛！不过我们不想这样胖得对象总占着内存，而我们也不想总是创建这样胖的新实例，因为这样很耗时。那怎么办……？聪明的朋友一定已经猜到了我要说解决方法是弱引用。不错，就是它。我们可以创建一个这个胖对象的弱引用，这样在内存不够时gc可以回收，不影响内存使用，而在没有被gc回收前我们还可以再次利用该对象。这里有一个示例：

view sourceprint?public class fat { 
  public int data; 
  public fat(int data) { 
    this.data = data; 
  } 
} 
public class main { 
  public static void main() { 
    fat ofat = new fat(1); 
    weakreference ofatref = new weakreference(ofat); 
    // 从这里开始，fat对象可以被回收了。 
    ofat = null; 
    if (ofatref.isalive) { 
      console.writeline(((fat) ofatref.target).data); // 1 
    } 
    // 强制回收。 
    gc.collect(); 
    console.writeline(ofatref.isalive); // false 
    console.readline(); 
  } 
}

　　这里我们的fat其实并不是很胖，但是可以体现示例的本意：如何使用弱引用。那如果fat有finalizer呢，会怎样？如果fat有finalizer那么我们可能会用到weakreference的另一个构造函数，当中有一参数叫做trackresurrection，如果是true，只要fat的内存没被释放我们就可以用它，也就是说fat的finalizer执行后我们还是可以恢复fat（相当于第一次回收操作后还可恢复fat）；如果trackresurrection是false，那么第一次回收操作后就不能恢复fat对象了。
5. 总结
　　我在这里写出了正篇文章的要点：
一个对象只当在没有任何引用的情况下才会被回收。
一个对象的内存不是马上释放的，gc会在任何时候将其回收。一般情况下不要强制回收工作。
如果没有特殊的需要不要写finalizer。
不要在finalizer中写一些有时间逻辑的代码。
在任何有非托管资源或含有dispose的成员的类中实现idisposable接口。
按照给出的dispose设计写自己的dispose代码。
当用胖对象时可以考虑弱引用的使用。