关于CLR内存管理一些深层次的讨论[下篇]

《上篇》中我们主要讨论的是程序集（Assembly）和应用程序域（AppDomain）的话题，着重介绍了两个不同的程序集加载方式——独占方式和共享方式（中立域方式）；以及基于进程范围内的字符串驻留。这篇将关注点放在托管对象创建时内存的分配和对大对象（LO：Large Object）的回收上，不对之处，还望各位能够及时指出。

目录
一、从类型（Type）与实例（Instance）谈起
二、实例内存分配不仅限于GC堆
三、实例对类型的引用
四、LOH中的对象如何被回收

一、从类型（Type）与实例（Instance）谈起

在面向对象的世界中，类型和实例是两个核心的要素。不论是类型和实例，相关的信息比如加载到内存中，对应着某一块或者多块连续或者不连续的内存。那么对类型和实例的内存分配时如何进行的呢？对象是“状态”和“行为”的组合体，所以从.NET Framework的角度来看类型，它只具有两种类型的成员——字段和方法（实际还有嵌套类型），前者表示状态，后者表示行为。类型是对元数据的描述，而实例则是符合该元数据描述的单个个体。同一个类型下的所有实例具有相同的行为，它们通过状态值的不同得以区分。所以内存中的实例（本篇所说的实例指代引用类型的实例）表示的是字段值，而内存中的类型表示的则是类型成员结构的元数据。很多人都知道，当我们创建一个对象的时候，CLR会在GC堆（Heap）中开辟一块连续的内存空间保存字段值。那么类型信息又是保存在那块内存上呢？

实际上，类型信息保存在“另一堆”上，我们称之为加载器堆（Loader Heap）。每一个应用程序域都具有各自的加载器堆，即包括我们创建的普通应用程序域，也包括《上篇》中提到的三个特殊应用程序域：系统程序域、共享程序域和默认程序域。如果说GC堆是实例的容器，那么基于应用程序域的加载器堆就是类型的容器。CLR采用“按需加载(这里指的是类型，不是程序集)、及时编译”的运行机制。当某个类型被第一次使用的时候，CLR试图加载该类型。如果该类型对应的程序没有独自地加载到本应用程序域中，或者没有通过中立域的形式加载到共享程序域中，它会按照相应的方式加载程序集（在这里我们假设采用独占方式加载）。然后，将使用到的这个类型加载到本应用程序域的加载器堆中。

加载器堆维护着自应用程序域创建以来使用过的所有类型记录，它们对应着一个特殊的对象——方法表（Method Table）。当程序第一次执行到某个方法的时候，CLR会定位到方法表中该条目，获取相关信息进行JIT编译。所以如果某个类型在加载器堆中的方法表的某个条目至少被执行一次，它就会指向一段JIT编译后的机器指令。

二、实例内存分配不仅限于GC堆

到现在为止，我们知道了类型和实例分别分配于基于应用程序域的加载器堆和GC堆中，那么CLR的内存分配仅仅限于这“两堆”吗？当然不是，除了这“两堆”以及默认的进程堆，还有额外“两堆”，一是存放JIT编译后机器指令的JIT堆（JIT Heap），另一个则是专门用于“大对象”的大对象堆（LOH： Large Object Heap）。下图反映了CLR主要维护的这些个不同的“堆”。

对于大对象堆，在本文后续部分还会讲述，在这里我们需要先了解CLR认为怎样的对象是“大对象”。当我们实例化一个对象的时候，如果该对象大于或者等于85，000字节（这种对象一般是数组，一般对象不会这么大），CLR将认为是“大对象”并被放到LOH中，否则放到GC堆中。这里有一点需要读者注意的是，作为垃圾回收器的GC并不仅仅限于针对GC堆中对象的回收，LOH中的对象的回收工作通过在GC的管辖之下。所以从某种意义上讲：你可以将之前提到的GC堆理解为SOH（Small Object Heap），或者称之为“狭义GC堆”，而将“广义GC堆”理解为SOH+LOH。

三、实例对类型的引用

实例是类型的实例，实例和它所对应的类型需要维持一种联系。反映在内存中，就以为着分配在GC堆或者是LOH中的对象具有一个对位于加载器堆中该类型的方法表的引用。实例对类型的引用通过一个特殊的对象来维系——TypeHandle。我们举个例子，在如下一段简单的对象实例化代码中 ，我先后实例化了四个对象：字符串“ABC”、System.Object对象、自定义Bar对象和具有85000个元素的字节数组。

string strInstance         = "ABC";
object objectInstance      = new object();
Bar barInstance            = new Bar()
byte[] largeObjInstance    = new byte[85000];

当上面的程序执行后，围绕着实例化的四个对象和类型信息，在内存中将会具有如下一个关系。最左边的是现成调用栈中的上述四个变量，对于字符串类型的strInstance，由于《上篇》所讲述的关于字符串驻留机制，最后总的字符串被分配到系统程序域中；Object和Bar类型的objectInstance与barInstance由于是小于85000字节的小对象，所以被分配到GC堆中。objectInstance通过TypeHandle指向位于共享程序域中System.Objhect类型对应的方法表（因为定义该类型的mscorlib程序集以中立域的方式加载），而barInstance得TypeHandle指向的基于Bar类型的方法表则位于默认程序域中（因为程序域默认采用独占的方式加载）。元素个数为85000的字节数组largeObjInstance属于大对象，直接分配到LOH中。largeObjInstance的TypeHandle指向的基于System.Byte[]类型的方法表，该System.Byte[]类型同样定义在mscorlib程序集中，所以该方法表同样存在于共享程序域的加载器堆。

 

四、LOH中的对象如何被回收

了解GC的读者应该都知道CLR采用基于“代龄（Generation）”的垃圾回收机制。代龄，个人觉得是一个很准确的词语，它充分体现了设计者用于表现“不同的对象具有不同生命周期”的意思。所有对象分三代，即G0、G1和G2，这实际上代表了三个不同的连续的内存块。“辈分”越高，表明时间越久；“辈分”越低，被扫荡（GC回收）的频率就越高。关于基于代龄的垃圾回收机制，限于篇幅，就说到这里。我们的重点是GC采用怎样的机制对LOH的对象进行回收。

到目前为止，对于LOH和GC堆中的对象，除了大小之外，我们好像没有觉得它们之间有何不同。实际上，将大对象放在LOH中，目的在于对其实施特殊的回收机制。关于垃圾收回，我们应该有这样的认知：回收的成本是和对象的大小基本成“正向”关系，对象越大，回收成本就越大。所以我们不能对大对象频繁地实施垃圾回收，实际上CLR是将LOH对象当成最高代龄的对象。也就是说，针对LOH的回收工作是和GC堆中G2一并进行的。换句话说，当G2或者LOH的剩余空间低于某个限度，针对它们的垃圾回收便被触发。关于LOH的垃圾回收机制，我们可以通过一个非常简单的程序来验证。

class Program
{
    static WeakReference SmallObjRef;
    static WeakReference LargeObjRef;

    static void Main(string[] args)
    {
        SetValues();
        GC.Collect(0);
        Console.WriteLine("GC.Collect(0)");
        Console.WriteLine("SmallObjRef.Target == null? {0}", SmallObjRef.Target == null);
        Console.WriteLine("LargeObjRef.Target == null? {0}\n", LargeObjRef.Target == null);

        GC.Collect(1);
        Console.WriteLine("GC.Collect(1)");
        Console.WriteLine("LargeObjRef.Target == null? {0}\n", LargeObjRef.Target == null);

        GC.Collect(2);
        Console.WriteLine("GC.Collect(2)");
        Console.WriteLine("LargeObjRef.Target == null? {0}\n", LargeObjRef.Target == null);
    }

    static void SetValues()
    {
        SmallObjRef = new WeakReference(new byte[84000]);
        LargeObjRef = new WeakReference(new byte[85000]);
    }
}

输出结果：

GC.Collect(0)
SmallObjRef.Target == null? True
LargeObjRef.Target == null? False

GC.Collect(1)
LargeObjRef.Target == null? False

GC.Collect(2)
LargeObjRef.Target == null? True

在上面的代码中没，我创建了两个WeakReference对象，它们的Target分别被设置成byte[84000]和byte[85000]。按照我们上面关于对“大对象”的界定，后者是大对象，前者不是。然后，我们先后三次对G0、G1和G2实施垃圾回收，我们发现“小对象”在实施针对G0的垃圾回收后就没了；而“大对象”会一直存活直到针对G2的垃圾回收被执行。

 

关于CLR内存管理一些深层次的讨论[上篇]
关于CLR内存管理一些深层次的讨论[下篇]