引言

内存管理是计算机科学中一个相当复杂而有趣的领域。在计算机诞生的这几十年间，内存的管理的技术不断进步，使系统能够更加有效地利用内存这一计算机必不可少的资源。

一般而言，内存管理可以分为三类：硬件管理（如TLB），操作系统管理（如Buddy System，Paging，Segmentation），应用程序管理（如C++，Java，.net的内存管理机制）。鉴于篇幅和笔者水平的限制，本文只涉及了内存管理的很小一部分，即.net中的内存管理方法。.net是一个当代的应用程序框架，采用了内存自动管理技术，就是通常所说的内存垃圾自动回收技术――Garbage Collection（下文中简称GC），对.net的剖析比较具有代表性。

GC的历史与好处

虽然本文是以.net作为目标来讲述GC，但是GC的概念并非才诞生不久。早在1958年，由鼎鼎大名的图林奖得主John McCarthy所实现的Lisp语言就已经提供了GC的功能，这是GC的第一次出现。Lisp的程序员认为内存管理太重要了，所以不能由程序员自己来管理。但后来的日子里Lisp却没有成气候，采用内存手动管理的语言占据了上风，以C为代表。出于同样的理由，不同的人却又不同的看法，C程序员认为内存管理太重要了，所以不能由系统来管理，并且讥笑Lisp程序慢如乌龟的运行速度。的确，在那个对每一个Byte都要精心计算的年代GC的速度和对系统资源的大量占用使很多人的无法接受。而后，1984年由Dave Ungar开发的Small talk语言第一次采用了Generational garbage collection的技术（这个技术在下文中会谈到），但是Small talk也没有得到十分广泛的应用。

直到20世纪90年代中期GC才以主角的身份登上了历史的舞台，这不得不归功于Java的进步，今日的GC已非吴下阿蒙。Java采用VM（Virtual Machine）机制，由VM来管理程序的运行当然也包括对GC管理。90年代末期.net出现了，.net采用了和Java类似的方法由CLR(Common Language Runtime)来管理。这两大阵营的出现将人们引入了以虚拟平台为基础的开发时代，GC也在这个时候越来越得到大众的关注。

为什么要使用GC呢？也可以说是为什么要使用内存自动管理？有下面的几个原因：

l          提高了软件开发的抽象度；

l          程序员可以将精力集中在实际的问题上而不用分心来管理内存的问题；

l          可以使模块的接口更加的清晰，减小模块间的偶合；

l          大大减少了内存人为管理不当所带来的Bug；

l          使内存管理更加高效。

总的说来就是GC可以使程序员可以从复杂的内存问题中摆脱出来，从而提高了软件开发的速度、质量和安全性。

什么是GC

GC如其名，就是垃圾收集，当然这里仅就内存而言。Garbage Collector（垃圾收集器，在不至于混淆的情况下也成为GC）以应用程序的root[1]为基础，遍历应用程序在Heap上动态分配的所有对象[2]，通过识别它们是否被引用来确定哪些对象是已经死亡的哪些仍需要被使用。已经不再被应用程序的root或者别的对象所引用的对象就是已经死亡的对象，即所谓的垃圾，需要被回收。这就是GC工作的原理。为了实现这个原理，GC有多种算法。比较常见的算法有Reference Counting，Mark Sweep，Copy Collection等等。目前主流的虚拟系统.net CLR，Java VM和Rotor都是采用的Mark Sweep算法。本文以.net为基础，这里只对Mark Sweep算法进行讲述。

相关的GC算法

Mark Sweep

在程序运行的过程中，不断的把Heap的分配空间给对象，当Heap的空间被占用到不足以为下一个对象分配的时候Mark Sweep算法被激活，将垃圾内存进行回收并将其返回到free list[3]中。

Mark Sweep就像它的名字一样在运行的过程中分为两个阶段，Mark阶段和Sweep阶段。Mark阶段的任务是从root出发，利用相互的引用关系遍历整个Heap，将被root和其它对象所引用的对象标记起来。没有被标记的对象就是垃圾。之后是Sweep阶段，这个阶段的任务就是回收所有的垃圾。

Mark Sweep算法虽然速度比Reference Counting要快，并且可以避免循环引用造成的内存泄漏。但是也有不少缺点，它需要遍历Heap中所有的对象（存活的对象在Mark阶段遍历，死亡的对象在Sweep阶段遍历）所以速度也不是十分理想。而且对垃圾进行回收以后会造成大量的内存碎片。

(简单地把.NET的GC算法看作Mark-Compact算法。阶段1: Mark-Sweep 标记清除阶段，先假设heap中所有对象都可以回收，然后找出不能回收的对象，给这些对象打上标记，最后heap中没有打标记的对象都是可以被回收的；阶段2: Compact 压缩阶段，对象回收之后heap内存空间变得不连续，在heap中移动这些对象，使他们重新从heap基地址开始连续排列，类似于磁盘空间的碎片整理。Heap内存经过回收、压缩之后，可以继续采用前面的heap内存分配方法，即仅用一个指针记录heap分配的起始地址就可以。主要处理步骤：将线程挂起→确定roots→创建reachable objects graph→对象回收→heap压缩→指针修复。可以这样理解roots：heap中对象的引用关系错综复杂（交叉引用、循环引用），形成复杂的graph，roots是CLR在heap之外可以找到的各种入口点。GC搜索roots的地方包括全局对象、静态变量、局部对象、函数调用参数、当前CPU寄存器中的对象指针（还有finalization queue）等。主要可以归为2种类型：已经初始化了的静态变量、线程仍在使用的对象（stack+CPU register） 。    Reachable objects：指根据对象引用关系，从roots出发可以到达的对象。例如当前执行函数的局部变量对象A是一个root object，他的成员变量引用了对象B，则B是一个reachable object。从roots出发可以创建reachable objects graph，剩余对象即为unreachable，可以被回收)

为了解决这两个问题，Mark Sweep算法得到了改进。首先是在算法中加入了Compact阶段，即先标记存活的对象，再移动这些对象使之在内存中连续，最后更新和对象相关的地址和free list。这就是Mark Compact算法，它解决了内存碎片的问题。而为了提高速度，Generation的概念被引入了。

Generation

Generational garbage collector（又被称为ephemeral garbage collector）是基于以下几个假设的：

l          对象越年轻则它的生命周期越短；

l          对象越老则它的生命周期越长；

l          年轻的对象和其它对象的关系比较强，被访问的频率也比较高；

l          对Heap一部分的回收压缩比对整个Heap的回收压缩要快。

Generation的概念就是对Heap中的对象进行分代（分成几块，每一块中的对象生存期不同）管理。当对象刚被分配时位于Generation 0中，当Generation 0的空间将被耗尽时，Mark Compact算法被启动。经过几次GC后如果这个对象仍然存活则会将其移动到Generation 1中。同理，如果经过几次GC后这对象还是存活的，则会被移动到Generation 2中，直到被移动到最高级中最后被回收或者是同程序一同死亡。 采用Generation的最大好处就在于每次GC不用对整个Heap都进行处理，而是每次处理一小块。对于Generation 0中的对象，因为它们死亡的可能性最大，所以对它们GC的次数可以安排多一些，而其它相对死亡的可能性小一些的对象所在的Generation可以少安排几次GC。这样做就使得GC的速度得到了一定程度的提高。这样就产生了几个有待讨论的问题，首先是应该设置几个Generation，每个Generation应该设置成多大，然后是对每个对象升级时它应该是已被GC了多少次而仍然存活。关于.net CLR对这个问题的处理，在本文的最后将给出一个例子对其进行测试。

相关的数据结构

与.net GC相关的数据结构有三个Managed Heap，Finalization Queue和Freachable Queue。

Managed Heap

Managed Heap是一个设计简单而优化的堆，它与传统的C-runtime的堆不太一样。它的简单管理方法是为了提高对堆的管理速度，同时也是基于一个简单的（也是不可能的）假设。对Managed Heap的管理假设内存是无穷无尽的。在Managed Heap上有一个称为NextObjPtr的指针，这个指针用于指示堆上最后一个对象的地址。当有一个新的对象要分配到这个堆上时，所要做的仅仅是将NextObjPtr的值加上新对象的大小形成新的NextObjPtr。这只是一个简单的相加，当NextObjPtr的值超出了Managed Heap边界的时候说明堆已经满了，GC将被启动。

Finalization Queue和Freachable Queue

这两个队列和.net对象所提供的Finalize[4]方法有关。这两个队列并不用于存储真正的对象，而是存储一组指向对象的指针。当程序中使用了new操作符在Managed Heap上分配空间时，GC会对其进行分析，如果该对象含有Finalize方法则在Finalization Queue中添加一个指向该对象的指针。在GC被启动以后，经过Mark阶段分辨出哪些是垃圾。再在垃圾中搜索，如果发现垃圾中有被Finalization Queue中的指针所指向的对象，则将这个对象从垃圾中分离出来，并将指向它的指针移动到Freachable Queue中。这个过程被称为是对象的复生（Resurrection），本来死去的对象就这样被救活了。为什么要救活它呢？因为这个对象的Finalize方法还没有被执行，所以不能让它死去。Freachable Queue平时不做什么事，但是一旦里面被添加了指针之后，它就会去触发所指对象的Finalize方法执行，之后将这个指针从队列中剔除，这是对象就可以安静的死去了。.net framework的System.GC类提供了控制Finalize的两个方法，ReRegisterForFinalize和SuppressFinalize。前者是请求系统完成对象的Finalize方法，后者是请求系统不要完成对象的Finalize方法。ReRegisterForFinalize方法其实就是将指向对象的指针重新添加到Finalization Queue中。这就出现了一个很有趣的现象，因为在Finalization Queue中的对象可以复生，如果在对象的Finalize方法中调用ReRegisterForFinalize方法，这样就形成了一个在堆上永远不会死去的对象，像凤凰涅槃一样每次死的时候都可以复生。

托管资源：

　　.NET中的所有类型都是（直接或间接）从System.Object类型派生的。

　　CTS中的类型被分成两大类——引用类型（reference type，又叫托管类型[managed type]），分配在内存堆上；值类型（value type），分配在堆栈上。如图：

值类型在栈里，先进后出，值类型变量的生命有先后顺序，这个确保了值类型变量在退出作用域以前会释放资源。比引用类型更简单和高效。堆栈是从高地址往低地址分配内存。

　　引用类型分配在托管堆(Managed Heap)上，声明一个变量在栈上保存，当使用new创建对象时，会把对象的地址存储在这个变量里。托管堆相反，从低地址往高地址分配内存，如图：

.NET中超过80%的资源都是托管资源。

　　非托管资源：　

　　ApplicationContext, Brush, Component, ComponentDesigner, Container, Context, Cursor, FileStream, Font, Icon, Image, Matrix, Object, OdbcDataReader, OleDBDataReader, Pen, Regex, Socket, StreamWriter, Timer, Tooltip, 文件句柄, GDI资源, 数据库连接等等资源。可能在使用的时候很多都没有注意到！

.NET的GC机制有这样两个问题：

　　首先，GC并不是能释放所有的资源。它不能自动释放非托管资源。

　　第二，GC并不是实时性的，这将会造成系统性能上的瓶颈和不确定性。

　　GC并不是实时性的，这会造成系统性能上的瓶颈和不确定性。所以有了IDisposable接口，IDisposable接口定义了Dispose方法，这个方法用来供程序员显式调用以释放非托管资源。使用using语句可以简化资源管理。

对GC的直接控制

.net framework的System.GC类提供一些可以对GC直接进行操作的方法。而System.Runtime.InteropServices.GCHandle类提供从非托管内存访问托管对象的方法（这里对此不作讨论）。先来看下面的这个利用System.GC进行直接操作的例子。

using System;

namespace gcTest

{

     class gcDemo

     {

         private static void GenerationDemo()

         {

              // Let‘s see how many generations the GCH supports (we know it‘s 2)

              Console.WriteLine("Maximum GC generations: {0}", GC.MaxGeneration);

              // Create a new BaseObj in the heap

              GenObj obj = new GenObj("Generation");

              // Since this object is newly created, it should be in generation 0

              obj.DisplayGeneration();    // Displays 0

              for(int i = 1; i <= GC.MaxGeneration; i++)

              {

                   // Performing a garbage collection promotes the object‘s generation

                   GC.Collect();

                   obj.DisplayGeneration();    // Displays i

              }

              obj = null;         // Destroy the strong reference to this object

              for(int i = 0; i <= GC.MaxGeneration; i++)

              {

                   GC.Collect(i);                  

                   GC.WaitForPendingFinalizers();

                   //suspend this thread until the freachable queue of

                   //the i generation has been emptied

                   //only when i = GC.MaxGeneration, this finalization method

                   //of obj will be performed

              }

              Console.WriteLine("Demo stop: Understanding Generations.");

              //total gc times

              //generation 0 : 5 times

              //generation 1 : 4 times

              //generation 2 : 3 times

         }

         public static void Main()

         {

              GenerationDemo();

         }

     }

     class GenObj

     {

         private string objName;

         public GenObj(string name)

         {

              this.objName = name;

         }

         public void DisplayGeneration()

         {

              Console.WriteLine("I am in Generation {0}", GC.GetGeneration(this));

         }

     };

}

这是个有趣的例子，首先利用GC.MaxGeneration()得知了在.net CLR中的GC采用了3代的结构，即Generation 0～2。接下来在Managed Heap上分配了一个GenObj的实例obj。在开始时obj位于Generation 0中，然后对整个Managed Heap进行两次GC。可以发现每进行一次GC存活的对象都会升一级直至到达Generation 2中。设置obj = null，这样做是为了取消root对obj的强引用，使obj成为垃圾。紧接着利用GC.Collect(i)对Managed Heap逐级进行GC，这个方法会对Generation 0～i进行GC。GC.WaitForPendingFinalizers()的作用是使整个进程挂起，等到Freachable Queue中所指向的对象的Finalize方法被调用。这样做的目的是为了保障对本次GC所确定的垃圾进行完全的回收，而不会因为对象的Finalize方法使对象复生。

这个例子得到的一些结果可以直观的看出.net CLR对GC的处理，要想得到更具体的数据读者可以使用Windows提供的性能监视器perfmon.exe对.net应用程序进行测试。

还要提到的是GC对大对象（large object）的处理，这个处理和以上所讨论的大同小异，只是GC不会进行Compact这个过程，因为要在内存中移动一个较大的对象对系统性能带来的不良影响是显而易见的。

GC.Collect() 方法

　　作用：强制进行垃圾回收。

　　GC的方法：

　　GC注意事项：

　　1、只管理内存，非托管资源，如文件句柄，GDI资源，数据库连接等还需要用户去管理。

　　2、循环引用，网状结构等的实现会变得简单。GC的标志-压缩算法能有效的检测这些关系，并将不再被引用的网状结构整体删除。

　　3、GC通过从程序的根对象开始遍历来检测一个对象是否可被其他对象访问，而不是用类似于COM中的引用计数方法。

　　4、GC在一个独立的线程中运行来删除不再被引用的内存。

　　5、GC每次运行时会压缩托管堆。

　　6、你必须对非托管资源的释放负责。可以通过在类型中定义Finalizer来保证资源得到释放。

　　7、对象的Finalizer被执行的时间是在对象不再被引用后的某个不确定的时间。注意并非和C++中一样在对象超出声明周期时立即执行析构函数

　　8、Finalizer的使用有性能上的代价。需要Finalization的对象不会立即被清除，而需要先执行Finalizer.Finalizer，不是在GC执行的线程被调用。GC把每一个需要执行Finalizer的对象放到一个队列中去，然后启动另一个线程来执行所有这些Finalizer，而GC线程继续去删除其他待回收的对象。在下一个GC周期，这些执行完Finalizer的对象的内存才会被回收。

　　9、.NET GC使用"代"(generations)的概念来优化性能。代帮助GC更迅速的识别那些最可能成为垃圾的对象。在上次执行完垃圾回收后新创建的对象为第0代对象。经历了一次GC周期的对象为第1代对象。经历了两次或更多的GC周期的对象为第2代对象。代的作用是为了区分局部变量和需要在应用程序生存周期中一直存活的对象。大部分第0代对象是局部变量。成员变量和全局变量很快变成第1代对象并最终成为第2代对象。

　　10、GC对不同代的对象执行不同的检查策略以优化性能。每个GC周期都会检查第0代对象。大约1/10的GC周期检查第0代和第1代对象。大约1/100的GC周期检查所有的对象。重新思考Finalization的代价：需要Finalization的对象可能比不需要Finalization在内存中停留额外9个GC周期。如果此时它还没有被Finalize，就变成第2代对象，从而在内存中停留更长时间。