类型加载器：从 IL 元数据到运行时类型的完整旅程
系列：C#与常用数据结构源码剖析 · 运行时底层剖析 阅读时间：约 40 分钟 前置知识：MethodTable、IL 基础、元数据概念
一、引言
前面的文章介绍了 MethodTable 的结构和编译全链路。本文聚焦于连接两者的关键环节：类型加载器（TypeLoader）。
当你写下 var list = new List<int>()，这个 List<int> 类型在运行时是如何从程序集的元数据"变为"一个可以分配对象、调用方法的真实类型的？答案在类型加载器中。
类型加载器是 CLR 中最容易被低估的子系统。它的设计面临几个艰难的约束：
类型加载器的回答是：分级加载（Phased Loading）——将类型加载拆成多个阶段，每完成一个阶段就"发布"一部分信息，允许其他类型引用。
二、类型加载的触发时机
类型加载不是主动的——它是被"拉"的。以下场景会触发类型加载：
2.1 JIT 编译时触发（最常见的场景）
当 JIT 编译器编译一个方法时，如果方法体引用了尚未加载的类型，JIT 会回调运行时要求加载该类型：
void Foo() {
var x = new MyType(); // 首次编译 Foo 时触发加载 MyType
}
JIT 通过 ICorJitInfo 接口回调运行时。这是类型加载最常见的触发路径，也是性能最敏感的路径——因为 JIT 编译在方法首次调用时发生，类型的加载速度直接影响用户体验。
2.2 其他触发场景
- 反射调用：Assembly.GetType("MyType")、typeof(MyType)、Activator.CreateInstance
- 反序列化：BinaryFormatter 或 JSON 反序列化时根据类型名加载
- 泛型实例化：typeof(List<int>) 首次使用时加载 List<int>（开放类型 List<> 在此前可能已加载）
- 静态构造器触发：即使不 new 对象，访问静态字段也会加载类型
源码位置：src/coreclr/vm/class.cpp 中的 ClassLoader::LoadTypeHandle() 是核心入口。
三、分级加载机制详解
3.1 为什么需要分级加载
假设没有分级加载——当你加载类型 A 时，必须同时加载它的父类型 B、接口 C、字段类型 D、方法参数类型 E……而这又会触发加载它们的依赖，形成无限递归。更糟的是，如果 A 和 B 互相依赖（A 继承 B，B 的字段是 A），就会陷入死锁。
分级加载的解决方案：先创建一个"占位"的类型结构，允许被引用，然后再逐步填充细节。
3.2 加载级别（Load Level）从 CLASS_LOAD_BEGIN 到 CLASS_LOADED
源码 src/coreclr/vm/classloadlevel.h 定义了完整的加载级别枚举。核心级别包括：
| 0 | CLASS_LOAD_BEGIN | 开始加载，尚未分配 MethodTable | 不能 |
| 1 | CLASS_LOAD_UNRESTOREDTYPEKEY | 已分配 MethodTable 空壳 | 基本可以（被其他类型引用） |
| 2 | CLASS_LOAD_UNRESTORED | 已设置父类型和接口（可能是近似值） | 可以 |
| 3 | CLASS_LOAD_APPROXPARENTS | 父类型的近似值已确定 | 可以 |
| 4 | CLASS_LOAD_EXACTPARENTS | 父类型和接口已精确确定 | 可以 |
| 5 | CLASS_LOADED | 完全加载，包括方法表和字段布局 | 完全可用 |
3.3 加载过程示例
以加载一个简单类型 class MyList : List<int>, IDisposable 为例：
Level 1：分配 MethodTable 结构体，设置基本标志（IsClass、HasVtable 等）。此时 MethodTable 的父类型和接口字段还是空。
Level 2-3：加载 List<int>（父类型）和 IDisposable（接口）。这里 List<int> 本身是一个闭合泛型类型，需要先加载 List<>（开放泛型类型），再为 int 参数创建闭合版本。如果 List<int> 也未被加载，这条加载链会递归触发。
Level 4：确认父类型和接口的精确引用。此前的近似值（如果有循环依赖）被替换为真实引用。
Level 5：加载方法定义（MethodDesc）和字段定义（FieldDesc）。计算每个字段在对象中的偏移量。构建 vtable（需要合并父类型的 vtable 槽位）。注册 Finalizer（如果有析构函数）。
3.4 PushFinalLevels——协作提升
最后的几个加载级别使用特殊的"协作提升"机制（PushFinalLevels）。当一个类型需要从 Level 4 提升到 Level 5 时，它可能要求所有相关的类型也同时提升到 Level 5。这确保了类型的完整性——不会出现"A 的 vtable 完整但 B 的 vtable 不完整"的半成品状态。
四、TypeHandle 与 TypeDesc
4.1 TypeHandle 的设计
TypeHandle 是 CLR 中类型的统一句柄。它可以指向两种不同的运行时结构：
区分它们的技巧是低位标记：
TypeHandle = MethodTable pointer (bit 0 = 0)
= (TypeDesc* | 2) (bit 0 = 0, bit 1 = 1)
检查一个 TypeHandle 是指向 MethodTable 还是 TypeDesc 时，使用 (TypeHandle & 2) != 0 来判断。这个设计不用额外的字段存储类型区别，节省了内存。
4.2 TypeDesc 的层次结构
TypeDesc 是多种特殊类型的基类：
- ParamTypeDesc：表示数组类型（T[]）、指针类型（T*）、引用类型（T&）。关键信息：元素类型（TypeHandle）。
- FunctionTypeDesc：表示函数指针类型（delegate*<…>）。
- TypeVarTypeDesc：表示泛型方法中的类型参数（<T> 中的 T）。
这些类型无需完整的 MethodTable——它们没有实例、不需要 GC 扫描——所以使用轻量级的 TypeDesc 表示。
五、泛型类型的加载
5.1 开放类型 vs 闭合类型
typeof(List<>) // 开放泛型类型：没有指定类型参数
typeof(List<int>) // 闭合泛型类型：类型参数已确定
两者的加载机制截然不同：
开放泛型类型（如 List<>）：在程序集首次访问时加载。加载的是模板——MethodTable 中的方法定义是通用的（使用占位符 T 代替具体类型）。
闭合泛型类型（如 List<int>）：在首次使用时（JIT 或反射）由两部分组合而成：
5.2 泛型实例化的缓存
每个 Module 内部维护一个哈希表，用于缓存已经创建的闭合泛型类型。键是（开放类型, 类型参数列表），值是闭合类型的 MethodTable。
当请求 List<int> 时：
这个缓存机制确保同一泛型类型只有一份运行时表示——typeof(List<int>) 无论调用多少次，返回的永远是同一个 Type 对象。
5.3 引用类型 vs 值类型的差异化处理
- 引用类型参数（List<string>）：可以共享 EEClass（因为所有引用类型大小相同）。这节省了大量内存——无论有多少个 List<SomeRefType>，只需要一个 EEClass。
- 值类型参数（List<int>）：独立 EEClass。每个 List<ValueType> 都需要自己的方法定义和字段布局。
六、循环依赖的处理——分级加载的杀手锏
6.1 循环依赖场景
class A : B { }
class B {
A field; // B 的字段类型是 A
}
加载 B 时需要加载 A（因为字段类型是 A）。加载 A 时需要加载 B（因为 A 继承自 B）。死循环！
6.2 近似类型（Approximation Type）机制
分级加载的解决之道：
这就像建筑中的"脚手架"——先搭一个临时结构，让整个工程能继续推进，最后再拆除脚手架换上正式结构。
七、类型加载与数据结构的关系
7.1 泛型集合的首次使用成本
当你首次写 var dict = new Dictionary<string, List<int>>()，类型加载器需要依次加载：
这一连串的加载产生了显著的"首次命中"延迟。因此，许多高性能 .NET 应用会在启动时通过"预热"代码触发关键类型的加载。
7.2 IL2CPP 下的泛型注册
在 IL2CPP AOT 编译下，上述加载过程变成了编译时的工作。IL2CPP 分析你的代码，找出所有泛型实例化，在编译期生成特化代码。但如果泛型实例化只发生在反射中（如 MakeGenericType），IL2CPP 无法发现，运行时就会抛出 MissingMethodException。解决方法是提供"补充元数据"或使用 link.xml 保留所需的类型。
八、总结
类型加载器是 CLR 中最精巧的工程设计之一。分级加载机制优雅地解决了"递归依赖"和"循环依赖"的死锁问题，泛型缓存避免了重复创建类型表示，近似类型机制保证了加载过程的安全推进。
对于数据结构的使用者来说，关键收获是：
下一篇：JIT 编译管线：RyuJIT 的完整阶段
