01-03-运行时-类型加载器-从IL元数据到运行时类型
类型加载器：从 IL 元数据到运行时类型的完整旅程
系列：C#与常用数据结构源码剖析 · 运行时底层剖析
阅读时间：约 40 分钟
前置知识：MethodTable、IL 基础、元数据概念
一、引言
前面的文章介绍了 MethodTable 的结构和编译全链路。本文聚焦于连接两者的关键环节：类型加载器（TypeLoader）。
当你写下var list = new List<int>()，这个List<int>类型在运行时是如何从程序集的元数据"变为"一个可以分配对象、调用方法的真实类型的？答案在类型加载器中。
类型加载器是 CLR 中最容易被低估的子系统。它的设计面临几个艰难的约束：
- 性能：不能每次都完整加载类型的所有信息
- 循环依赖：A 继承 B，B 的字段是 A——如何不陷入死锁？
- 泛型：开放泛型类型（
List<>）和闭合泛型类型（List<int>）的加载机制完全不同 - 并发安全：多个线程同时触发同一类型的加载
类型加载器的回答是：分级加载（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 中类型的统一句柄。它可以指向两种不同的运行时结构：
- MethodTable（普通类型、泛型闭合类型、数组类型）
- TypeDesc（特殊类型：指针、byref、泛型参数变量、函数指针）
区分它们的技巧是低位标记：
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 或反射）由两部分组合而成：
- 开放类型的模板（MethodTable for
List<>） - 类型参数
int的 TypeHandle
5.2 泛型实例化的缓存
每个 Module 内部维护一个哈希表，用于缓存已经创建的闭合泛型类型。键是（开放类型, 类型参数列表），值是闭合类型的 MethodTable。
当请求List<int>时：
- 计算哈希键
- 查缓存：如果已有，直接返回
- 否则，以
List<>的 MethodTable 为模板创建新的 MethodTable 实例 - 将新 MethodTable 加入缓存
这个缓存机制确保同一泛型类型只有一份运行时表示——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）机制
分级加载的解决之道：
- 加载 A 时，将 B 标记为"正在加载中"
- 创建 A 的 MethodTable，将父类型设置为对 B 的近似引用（一个占位符）
- 继续加载 B：B 的字段类型 A 此时已有 MethodTable（虽然未完全加载）
- 加载完成后，用精确引用替换近似引用
这就像建筑中的"脚手架"——先搭一个临时结构，让整个工程能继续推进，最后再拆除脚手架换上正式结构。
七、类型加载与数据结构的关系
7.1 泛型集合的首次使用成本
当你首次写var dict = new Dictionary<string, List<int>>()，类型加载器需要依次加载：
Dictionary<,>（开放类型）Dictionary<string, List<int>>（闭合类型）List<>（开放类型）List<int>（闭合类型）
这一连串的加载产生了显著的"首次命中"延迟。因此，许多高性能 .NET 应用会在启动时通过"预热"代码触发关键类型的加载。
7.2 IL2CPP 下的泛型注册
在 IL2CPP AOT 编译下，上述加载过程变成了编译时的工作。IL2CPP 分析你的代码，找出所有泛型实例化，在编译期生成特化代码。但如果泛型实例化只发生在反射中（如MakeGenericType），IL2CPP 无法发现，运行时就会抛出MissingMethodException。解决方法是提供"补充元数据"或使用link.xml保留所需的类型。
八、总结
类型加载器是 CLR 中最精巧的工程设计之一。分级加载机制优雅地解决了"递归依赖"和"循环依赖"的死锁问题，泛型缓存避免了重复创建类型表示，近似类型机制保证了加载过程的安全推进。
对于数据结构的使用者来说，关键收获是：
- 泛型集合的首次使用有加载成本——预处理 / 预热可以提升启动性能
- IL2CPP AOT 需要显式注册泛型类型——反射创建的泛型实例化需要额外处理
- 类型加载错误（TypeLoadException）可能不按预期抛出——因为异常可能发生在 JIT 编译阶段而非你的 try-catch 代码块内
下一篇：JIT 编译管线：RyuJIT 的完整阶段