What is "Type" in managed heap?

我们知道，在程序运行过程中，每个对象（object）都是对应了一块内存，这里的对象不仅仅指的是某个具体类型的实例（instance），也包括类型（type）本身。我想大家也很清楚CLR如何为我们创建一个类型的实例（instance）的：CLR计算即将被创建的Instance的size（所有的字段加上额外的成员所占的空间：TypeHandle和SyncBlockIndex）；在当前AppDomain对应的managed heap中为之开辟一块连续的内存空间；初始化Instance的这两个额外的成员TypeHandle和SyncBlockIndex（TypeHandle是一个指针，指向Type的method table，SyncBlockIndex用于在多线程的条件下确保对该Instance操作的同步，它指向一块被称为Synchronization Block的内存块，我们对该Instance加锁， CLR会使instance的SyncBlockIndex指向某一个Synchronization Block，反之解锁会重置SyncBlockIndex）；最后调用对应的constructor。

在面向对象的原则下，Instance的Field代表的是对象的状态（state）, 而方法则体现的是对象的行为（behavior）。状态只能和具体的Instance绑定在一起，而属于同一类型的不同的Instance则具有一样的行为，所以行为是和Type绑定在一起的。同时Type定义了很多原数据的信息。这些基于Type的信息是如何保存的，今天我们就来简单地讨论这个问题。

一、 Sample

在开始介绍之前我们给出一个有趣例子。在讨论String interning的时候，我通过对具有相同字符序列的string进行加锁，证明了基于进程的string interning。今天我仍然沿用这种机制，不过进行加锁的对象不是string，而是Type对象。

上面是整个Solution的结构，为了把CustomType类型定义在一个和主程序不同的Assembly中，我添加了Artech.TypeInManagedHeap.ClassLibrary Project。CustomType是一个空的Class，没有定义任何的成员，因为我们需要的仅仅是CustomType这个Type本身：

using System;
using System.Collections.Generic;
using System.Text;

namespace Artech.TypeInManagedHeap.ClassLibrary
{
    public class CustomType
    {
    }
}

在Main所在的Artech.TypeInManagedHeap.ConsoleApp Project，我定义了一个MarshalByRefType，他继承自MarshalByRefObject，因为我需要让它在不同的AppDomain中以By Reference进行传递。唯一的方法ExecuteWithTypeLocked中，先对传入的Type对象加锁，获得锁后做一些输出，随后进行10s的时间延迟。

class MarshalByRefType : MarshalByRefObject
     {
        public void ExecuteWithTypeLocked(Type type)
        {
            lock (type)
            {
                Console.WriteLine("The operation with a Type locked is executed\n\tAppDomain:\t{0}\n\tTime:\t\t{1}\n\tType:{2}\n",
                   AppDomain.CurrentDomain.FriendlyName, DateTime.Now, type);
                Thread.Sleep(10000);
            }
        }
}
class Program
     {
        static void Main(string[] args)
        {
            try
            {
                AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");
                AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");

                MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap("Artech.TypeInManagedHeap.ConsoleApp", "Artech.TypeInManagedHeap.ConsoleApp.MarshalByRefType") as MarshalByRefType;
                MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap("Artech.TypeInManagedHeap.ConsoleApp", "Artech.TypeInManagedHeap.ConsoleApp.MarshalByRefType") as MarshalByRefType;

                Thread thread1 = new Thread(new ParameterizedThreadStart(Execute));
                Thread thread2 = new Thread(new ParameterizedThreadStart(Execute));

                thread1.Start(marshalByRefObj1);
                thread2.Start(marshalByRefObj2);

                Console.Read();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.Read();
            }
        }

        static void Execute(object obj)
        {
            try
            {
                MarshalByRefType marshalByRefObj = obj as MarshalByRefType;
                marshalByRefObj.ExecuteWithTypeLocked(typeof(int));
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.Read();
            }
        }
}

在主程序中，我在两个新创建的AppDomain中创建了MarshalByRefType 实例，并在各自的线程中调用ExecuteWithTypeLocked方法。该程序的目的是证明在不同线程中被加锁的Type对象是否是同一个对象，如果是同一个对象，果是两个线程中的操作的执行间隔应该是10s，否则他们几乎在同一个时刻执行。

首先进行加锁的对象是System.Int32 Type(typeof(int)))我们来运行程序，看看输出结果：

输出的两个时间刚好相差10s，这充分说明了在不同的AppDomain中进行加锁的System.Int32 Type是同一个对象。

我们现在来对我们自定义的CustomType Type进行加锁，我只需修改Execute方法：

static  void Execute( object obj)
         {
            try
            {
                MarshalByRefType marshalByRefObj = obj as MarshalByRefType;
                marshalByRefObj.ExecuteWithTypeLocked(typeof(CustomType));                
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.Read();
            }
        }

现在看看输出的结果：

两个操作输出了相同的时间，这说明了在两个不同AppDomain中进行加锁的CustomType Type对象并非同一个对象。

我们进一步作一些修改，在Main方法上运用LoaderOptimizationAttribute：

    [LoaderOptimizationAttribute(LoaderOptimization.MultiDomain)]
         static  void Main( string[] args)
         {
            … …
        }

看看现在的输出又如何：

现在的时间间隔又变成了10s，也就是说，在这种情况下，CustomType Type虽然使用在不同的AppDomain中，但是它们实际是同一个对象。

二、Managed code的执行

我先不对上面出现的现象做出解释，我首先对在CLR下托管代码的执行过程做一个简单的介绍。我们就以上面的Sample为例，对于下面的4行code, 如果MarshalByRefType实现在另外一个Assembly中（假设叫做CustomAssembly.dll）, 我们来看看CLR到底会为为我们做些什么。

AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");
AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");

MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap("Artech.TypeInManagedHeap.ConsoleApp", "Artech.TypeInManagedHeap.ConsoleApp.MarshalByRefType")  as MarshalByRefType;
MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap("Artech.TypeInManagedHeap.ConsoleApp", "Artech.TypeInManagedHeap.ConsoleApp.MarshalByRefType")  as MarshalByRefType;

CLR先创建了两个AppDomain：Artech.AppDomain1和Artech.AppDomain2。接着调用CreateInstanceAndUnwrap方法。发现一个MarshalByRefType类型，并且该类型并没有在已经加载的Assembly中定义，于是CLR会在一些特殊的目录或者GAC中试着找到定义了MarshalByRefType的CustomAssembly.dll，找到后加载该Assembly。注意该Assembly的加载是基于AppDomain的，也就是说，两个CustomAssembly.dll被分别加载到Artech.AppDomain1和Artech.AppDomain2中。

每个AppDomain都具有一段限于自己使用的、被隔离的托管堆。托管堆中又具有很多不同的划分，分别基于不同的目的用于存储不同的信息。其中最重要的是GC heap和Loader heap。GC heap用于Reference type实例的存储，每个实例的生命周期受GC的管理。GC以某种机制进行垃圾收集回收垃圾对象的内存。Loader heap在存储原数据相关的信息，也就是我们说的Type。每个Type在Loader heap中体现为一个MethodTable，MethodTable主要记录了这些metadata的信息，比如Type的base type，实现的interface, Type被定义的module, static field，以及所有的方法，而System.Type则可以看成是对MethodTable的封装，在程序执行过过程中一个Type对象对应着一个具体的MethodTable。

当基于Type的Meta data被成功加载在各自AppDomain的Loader heap中之后，CLR便按照开篇介绍的Instance创建的过程创建对象，Instance对应的managed heap就是GC heap。在初始化Instance额外成员TypeHandle过程中，就是把它指向在Loader heap 的MethodTable。通过TypeHandle这个指针就可以定位到具体的Type。

如果我们执行了Intance的某个方法，那么CLR根据TypeHandle找到对应的MethodTable，随后定位到具体的方法，通过JIT Compiler把IL指令变成基于处理器的machine instruction，并执行之，该machine instruction被保存，用于下一次执行。

通过上面的介绍，我们说Assembly的加载和Type在Loader heap的加载都是基于某个单独AppDomain，是被AppDomain隔离起来，不能被其他的AppDomain共享。这样充分的利用AppDomain提供的内存隔离机制，保证了托管程序的健壮性。但是，从另一方面讲，由于在不同的AppDomain使用的Type，都会在该AppDomain中加载对应的Assembly，并在AppDomain所在的Loader heap加载基于Type的metadata，这样对于一些不是很Common的Type来说没有问题，但是对一些我们经常使用的基本类型，比如int，Array，object等，则会带来Performance的损耗和内存的压力。于是出现了另一种加载机制：以中立域的方式加载。

在《再说string》中，我提到过，在CLR初始化过程中，会创建3个Domain：SystemDomain，SharedDomain和DefaultDomain。SharedDomain中加载的是一些AppDomain中性，能被各不同的AppDomain共享的信息。定义了一些基本类型，比如int，object，Array等的Assembly -MSCorLib.dll就是被加载到SharedDomain中供同一个进程的各个AppDomain共享。同理存储于SharedDomain的Loader heap的Type也是被各个AppDomain共享的。

MSCorLib.dll在初始化的时候被自动地加载到SharedDomain，而对于一般的Assembly，CLR为我们提供了一些方式实现这样的加载方式，比如在Main方法上运用LoaderOptimizationAttribute。

三、回到Sample

有了上面的理论基础，我们再一次回到我们第一部分的Sample，对于运行的现象就很容易理解了：

首先对System.Int32 Type进行加锁，由于System.Int32 是定义在MSCorLib.dll中，并且该Assembly一中立的方式加载到SharedDomain中，同一个进程中的各个AddDomain用到的System.Int32 Type实际上是同一个对象。

后来我们又对我们自定义的CustomType进行加锁，这个Type对应的Assembly为Artech.TypeInManagedHeap.ClassLibrary.dll, 在某人的情况下两个Assembly被加载到我们新创建的两个AppDomain中，所以在AppDomain1和AppDomain2的CustomType Type是不同的对象。

最后我们在Main上运用了[LoaderOptimizationAttribute(LoaderOptimization.MultiDomain)]，实际上就是指示CLR以中立的方式把Artech.TypeInManagedHeap.ClassLibrary.dll加载到SharedDomain中，所以这时候爱两个AppDomain中的CustomType Type是相同的对象。

四、 一点补充

由于Type对象是基于Loader heap的，而非GC heap，所以Type的生命周期会保持到AppDomain被卸载，对于以中立的方式加载到SharedDomain的情况，Type对象的生命周期会延续要进程的结束。

另外，切忌对Type进行加锁，如果你对Type加锁，你实际上相当于对所有的该Type对应的instance加锁，粒度太大，极易形成死锁。

关于CLR如何创建对象，请参考：

《Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects》
  By Hanu Kommalapati and Tom Christian