深入理解 .NET 运行时：CLR（Common Language Runtime）的完整架构、内存安全与托管代码世界

深入理解 .NET 运行时CLRCommon Language Runtime的完整架构、内存安全与托管代码世界【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime本文基于 .NET 仓库中 Book of the RuntimeBOTR的第一篇 《Introduction to the Common Language Runtime (CLR)》系统梳理 CLR 作为“完整编程语言平台”的设计动机、三大基本特征垃圾回收、内存与类型安全、高级语言支持以及托管/非托管两个世界的边界并结合当前仓库的 CoreCLR 源码GC 实现、类型系统、线程池、AOT 编译对这些设计做实现层面的印证。读完本文你能建立对 .NET 运行时的一万英尺视图知道每个子系统为何存在、它们之间如何相互制约并能按图索骥深入 BOTR 各章节文档。一、CLR 是什么一个罕见的“完整”编程语言平台对 CLR 最凝练的定义是The Common Language Runtime (CLR) is a complete, high level virtual machine designed to support a broad variety of programming languages and interoperation among them.这个定义之所以重要是因为它把庞大复杂的 CLR 按功能分组提供了自顶向下的理解框架。要理解“完整”意味着什么先看一个对照事实任何程序都对其运行环境有大量依赖。C 语言本身并不规定可执行文件格式每个 C 编译器都绑定到特定硬件架构如 X86与特定操作系统Windows、Linux、macOS程序员生产的是“Windows X86 可执行文件”而非“C 可执行文件”。这种复用底层标准的做法有利有弊利借力成熟的硬件与操作系统标准弊抽象被锁定在现有标准的层次上。没有任何常见操作系统有“垃圾回收堆”的概念因此无法用现有标准描述一个利用 GC 的接口比如自由地传递字符串而不必担心谁来释放它。典型的可执行文件格式也只够“运行”一个程序不够让编译器把另一个二进制“绑定”进来——C 程序依赖标准库Windows 上是 msvcrt.dll但没有配套的接口描述文件如 stdio.h库就不可用。CLR 用一份完整的、由 ECMA 标准化的规范解决上述问题覆盖程序的完整生命周期从构造、绑定到部署、执行。具体而言CLR 规定了一个GC 感知的虚拟机及其指令集——公共中间语言CIL/Common Intermediate Language用于描述程序执行的原语操作使 CLR 不依赖特定 CPU一套丰富的元数据表示描述类型、字段、方法等程序声明使其他可执行文件的编译器拥有从“外部”调用所需的信息一种精确规定比特布局的文件格式使“CLR EXE”成为不绑定特定操作系统与硬件的概念已加载程序的生命周期语义一个 CLR EXE 如何引用另一个 CLR EXE以及运行时在运行时如何查找被引用的文件一个类库利用 CLR 提供的特性GC、异常、泛型来暴露基础功能整数、字符串、数组、列表、字典和操作系统服务文件、网络、用户交互。为什么“完整抽象”如此稀有定义并实现上述细节是一项巨大工程所以绝大多数“相对完整”的抽象都是为单一语言构建的Java 运行时、Perl 解释器、早期 Visual Basic 运行时都提供了类似的完整抽象边界。CLR 与它们的关键区别在于多语言性早期单语言运行时即便语言内部体验很好与其他语言互操作也极其困难因为语言只能借助操作系统提供的原语与“外来”语言通信而 OS 抽象层次太低没有 GC 堆概念不得不使用不必要的复杂技巧CLR 通过提供一个共享的运行时让各语言可以用高级构造如 GC 收集的结构体相互通信极大降低了互操作负担。还有一个资源杠杆效应运行时被许多语言共享就有更多资源投入把它做好。为某语言构建好的调试器、剖析器代价高昂通常只有最重要的一两种语言才配得上全套工具但基于 CLR 实现的语言可以直接复用这套基础设施单个语言的负担被显著摊薄。更关键的是任何基于 CLR 的语言立即可用 CLR 之上全部类库——这批经过调试与长期支持的庞大功能体系正是 CLR 成功的重要原因之一。二、CLR 的核心目标让编程变得简单理解了“CLR 是什么”还要退回一步理解它要解决的问题。在非常高的层次上CLR 只有一个目标The goal of the CLR is to make programming easy.这句话有两重价值。演化的指导原则只有简单的事物才能“容易”。因此给运行时增加用户可见的复杂性应当始终持怀疑态度。比单一特性的成本/收益比更重要的是它的“新增暴露复杂度 ÷ 全场景加权收益”比值。理想情况下这个比值为负新特性通过解除限制或泛化特例而降低复杂度更常见的做法是把暴露的复杂度的最小化、并把该特性受益的场景最大化来压低它。易用性才是成功的根本CLR 的成功不是因为它比手写本地代码更快或更小写得好的本地代码常常获胜也不是因为任何一个具体特性GC、平台无关、面向对象、版本支持——而是因为所有这些特性叠加起来让编程显著更容易。其中一些重要但常被忽视的易用性特性包括更简单的语言C# 与 Visual Basic 比 C 显著简单类库对简洁的执着例如只有一种字符串类型且不可变这极大简化了任何使用字符串的 API类库命名的强一致性要求 API 使用完整单词与一致的命名约定强大的工具链支持Visual Studio 让构建 CLR 应用变得简单IntelliSense 让找到正确的类型与方法变得容易。有意思的是这些最重要的易用性特性往往也是最“无聊”的一致的命名约定哪个环境都能做但在大型类库中真正落实代价高昂经常与兼容性目标冲突重命名一个方法在一个超大规模代码库中成本巨大。正是在这类时刻需要回到运行时第一目标来校准优先级。三、CLR 特性分类框架运行时的特性很多原文档将其分为三类这个分类也是理解整个运行时架构的骨架基本特性Fundamental features——对其它特性设计有广泛影响垃圾回收GC内存安全与类型安全对编程语言的高级支持次级特性Secondary features——由基本特性使能、但并非每个有用程序都需要基于 AppDomain 的程序隔离程序安全与沙箱其它特性Other features——所有运行时环境都需要、但不依赖 CLR 基本特性而是“完整编程环境”愿望的产物版本管理调试/剖析互操作下面按此框架逐一展开并对照当前仓库的源码。四、垃圾回收GC 感知的虚拟机在所有 CLR 特性中垃圾收集者GC值得特别关注。GC 是自动内存回收的通俗说法在 GC 系统中用户程序不再调用特殊操作符删除内存运行时自动跟踪 GC 堆上所有内存引用周期性遍历这些引用找出程序仍可达的内存其余内存都是“垃圾”可被新分配复用。GC 的用户价值有两层显而易见的大部分显式 delete 操作不再必要更微妙的GC 简化接口设计——不必在接口上仔细规定哪一方负责删除跨接口传递的对象。CLR 接口直接返回字符串而不是传递“缓冲 长度”也就不必处理缓冲区太小这类复杂性。可以说 GC 让运行时中所有接口都比没有它更简单GC 消灭一整类常见错误——对象生命周期管理极易出错删除过早内存损坏或删除过晚不可达内存泄漏。典型程序使用数以百万计的对象出错概率很高且一旦对象被很多其它对象引用排错极其困难。让这类错误从可能性上消失省去了大量痛苦。但 GC 之所以值得“特别关注”不是因为它对用户有用而是它对运行时自身提出了一个看似简单、实则影响深远的要求垃圾回收要求所有指向 GC 堆的引用都必须被跟踪。多线程放大了追踪义务理论上这一要求只在 GC 真正发生时才需要满足——不必时刻知道所有 GC 引用的位置。但另一个 CLR 特性让这种“缓解”不能完全成立CLR 支持单进程内多并发执行线程。任一时刻其它线程都可能发起一次触发 GC 的分配并发线程间的操作顺序是非确定的无法预知某个线程在另一线程触发 GC 分配时正在执行什么。因此 GC 可能“随时”发生。CLR 不需要对其它线程的 GC 请求立即响应有一点回旋余地不需要在执行点的每一处都跟踪 GC 引用但必须保证在足够多的位置跟踪从而保证对“由其它线程分配引发的 GC 需求”的及时响应。其结论是CLR 需要几乎时刻跟踪所有指向 GC 堆的引用。由于 GC 引用可能驻留在机器寄存器、局部变量、静态变量或其它字段中追踪面相当大。其中机器寄存器与局部变量最棘手因为它们与用户代码的实际执行息息相关。这意味着操纵 GC 引用的机器码本身就有一条额外要求必须跟踪它使用的全部 GC 引用——这给编译器带来额外的发射开销。源码印证CoreCLR 的 GC 实现当前仓库中 CoreCLR 的 GC 位于 src/coreclr/gc/目录结构印证了上述机制的工程规模mark_phase.cpp标记阶段、sweep.cpp清扫阶段、gcscan.cpp引用扫描、dynamic_heap_count.cpp与dynamic_tuning.cpp动态调优、card_table.cpp卡表、finalization.cpp终结器等。其中gcscan.cpp对应的正是“遍历引用找出仍可达内存”的机制而编译器必须发射引用追踪信息的前提直接体现在 JIT 生成的代码与 GC 之间的协作上。关于 GC 的更完整设计说明见 Garbage Collector design document它是 BOTR 目录中紧随本文的一章。五、托管代码的概念The Concept of Managed Code会做额外簿记、能在“几乎所有时刻”报告其活跃 GC 引用的代码称为托管代码managed code——因为它被 CLR“托管”。不做这件事的代码称为非托管代码unmanaged code。因此 CLR 出现之前的所有代码都是非托管代码特别是所有操作系统代码。栈展开问题The stack unwinding problem托管代码需要操作系统服务因此必然存在托管代码调用非托管代码的时刻反过来由于操作系统最初启动了托管代码也存在非托管代码调入托管代码的时刻。所以在任意位置停下来检查一个托管程序的调用栈栈帧必然是托管帧与非托管帧的混合。非托管栈帧对程序运行之外没有任何要求特别是不要求它可以在运行时被“展开”unwind以找到调用者。也就是说如果程序恰好停在某个非托管方法内一般情况下无法找到它的调用者。调试器能这样做只是因为有符号信息PDB 文件中的额外信息——而且这些信息并不保证可用这正是调试器中有时拿不到良好栈回溯的原因。对托管代码来说这非常棘手任何无法展开的栈其中都可能包含含 GC 引用、必须上报的托管帧。注较新的平台 ABI应用二进制接口定义了一些编码该信息的约定但通常并不严格要求所有代码都遵循原文脚注 1。托管代码的额外要求是不仅要跟踪自己执行期间使用的全部 GC 引用还必须能展开到调用者。此外每当发生托管↔非托管的切换托管代码必须做额外簿记弥补非托管代码不会展开自身栈帧的事实。本质上托管代码把栈中属于托管帧的片段“链接”了起来非托管帧在缺少额外信息时仍可能无法展开但始终可以找到对应于托管代码的栈块并枚举这些块中的托管帧。托管代码的“世界”The World of Managed Code结果是每次进入/离开托管代码的切换点都需要特殊簿记。托管代码事实上生活在一个自己的“世界”里——除非 CLR 知情否则执行无法进入或离开它。两个世界在任何时刻都真实地区分开代码要么在托管世界要么在非托管世界。而且由于托管代码的执行是以 CLR 格式CIL规定的由 CLR 负责转换到本地硬件上运行CLR 对执行的确切行为拥有多得多的控制权CLR 可以改变“从对象取字段”或“调用函数”的含义——事实上它确实这样做了以支持 MarshalByReference 对象看起来像普通本地对象实际可能存在于另一台机器上。简言之CLR 的托管世界拥有大量执行钩子execution hooks用于支撑各种强大特性。托管代码还有另一个不那么直观的后果在非托管世界中不允许存在 GC 指针因为无法跟踪且托管→非托管切换有簿记成本。这意味着虽然你可以从托管代码调用任意非托管函数但这样做常常体验不佳非托管方法的参数与返回类型不使用 GC 对象它们创建和使用的任何“对象”或“对象句柄”都需要显式释放。更糟的是这些 API 无法利用 CLR 的异常、继承等机制用户体验与托管世界设计出来的接口相比明显“错位”。包装Wrapping一次成功的“整容”结果是非托管接口在暴露给托管开发者之前几乎总是先被包装。例如访问文件时你使用的不是 Win32 的CreateFile而是包装了它的托管System.IO.File类。非托管功能直接暴露给用户的例子极其罕见。这种包装看起来像“坏味道”多了一层似乎没做多少事的代码实际上价值很高。直接暴露非托管接口始终可行是团队选择去包装。为什么因为运行时的总目标是让编程变简单而非托管函数通常并不够“简单”——多数非托管接口不是为易用性设计而是为完备性调优。看看CreateFile或CreateProcess的参数列表很难称之为“容易”。幸运的是这些功能进入托管世界后得到“整容”这通常是很“低科技”的工作重命名、简化、组织功能但价值深远。CLR 的重要产物之一 Framework Design Guidelines800 页文档就详细规定了创建新托管类库的最佳实践当前仓库中也有其摘要文档。因此托管代码与非托管代码有两个重要差异二者对托管代码的成功都至关重要高科技High Tech代码生活在一个独立世界里CLR 以极细粒度细到单条指令控制程序执行的多数方面并检测执行何时进入/离开托管代码由此支撑大量有用特性低科技Low Tech托管→非托管切换的成本、以及非托管代码不能使用 GC 对象这两点促使人们把多数非托管代码包装在托管外观之下使接口得以“整容”符合一套统一的命名与设计准则产生非托管世界本可以有却从未有的一致性与可发现性。源码印证非托管互操作的边界在当前仓库中托管代码调用非托管代码的边界机制有清晰的代码体现例如 src/coreclr/vm/arraynative.h 中定义的Array_Ctor(MethodTable* pArrayMT, UINT32 dwNumArgs, INT32* pArgList, QCall::ObjectHandleOnStack retArray, QCallExceptionStatus* qcallError)——这是一个由托管侧通过 QCall快速调用机制进入本地实现的入口参数使用ObjectHandleOnStack这类显式句柄抽象正对应原文所述“非托管世界不持有裸 GC 指针、需要句柄与簿记”的原则。六、内存安全与类型安全GC 是内存安全的必要条件GC 使能的、不那么显眼但影响深远的特性之一是内存安全。其不变式非常简单一个程序是内存安全的当且仅当它只访问已被分配且未释放的内存——即不存在指向随机位置更精确地说过早释放的内存的“野指针”。悬挂指针永远是 bug且排错常常很困难。一个 GC 是提供内存安全保证所必需的。GC 如何帮助内存安全很好理解它排除了用户过早释放内存从而访问未正确分配的内存的可能性。不那么明显的是如果你想保证内存安全即让程序员在原理上无法写出内存不安全的程序实践上就绕不开 GC。原因是非平凡程序需要堆式动态内存分配对象生命周期在本质上是任意程序控制的不同于栈分配或静态分配那种高度受限的分配协议。在这种不受约束的环境中判断某条显式 delete 语句是否正确在程序分析层面不可预测——你实际上只能在运行时检查而这正是 GC 做的事检查内存是否仍活跃。因此对于需要堆式内存分配的程序想保证内存安全就必须有 GC。GC 是必要但不充分的GC 并非充分条件它不会阻止程序越界索引数组或访问对象末尾之外的字段通过基址偏移计算字段地址即可做到。但如果同时堵住这些口子就真的可以让程序员不可能写出内存不安全的程序。CIL 中确实存在可以读写任意内存从而破坏内存安全的操作符但 CIL 同时提供了内存安全的操作符并且 CLR 强烈鼓励在绝大多数编程中使用它们字段访问操作符LDFLD、STFLD、LDFLDA按名字读取、写入字段和取字段地址数组访问操作符LDELEM、STELEM、LDELEMA按下标读取、写入数组元素和取元素地址。所有数组都携带记录其长度的标签便于每次访问前做自动边界检查。在用户代码中用这些操作符替代底层不安全的内存访问操作符并避免其它不安全 CIL 操作符例如允许跳转到任意、可能危险位置的操作符理论上可以构造出一个仅内存安全的系统。但 CLR 没有止步于此它强制一个更强的不变式类型安全type safety。类型安全概念上每个内存分配都关联一个类型所有作用于内存位置的操作符也都概念性地打上了“对其有效的类型”标签。类型安全要求打上某类型标签的内存只能执行该类型允许的操作。这不仅保证内存安全无悬挂指针还为每个类型提供附加保证。最重要的类型特定保证之一是可见性属性尤其是字段的被强制。如果一个字段声明为private只有本类型的方法可访问那么所有类型安全代码都必须尊重这一隐私。例如某类型声明一个表示表中条目数的count字段假设count与表字段都是私有的且只有同时更新二者的代码会更新它们那么跨所有类型安全代码就存在强保证count与表中实际条目数始终同步。程序员在推理程序时无时无刻不在使用类型安全这个概念——是否自知与否CLR 把类型安全从“语言/编译器约定”提升为可以在运行时严格强制的东西。源码印证每个对象首字段指向类型原文指出的运行时要求之一——“GC 堆上的每个对象的第一个字段都指向代表其类型的运行时数据结构”——在当前仓库的类型系统中可以直接验证src/coreclr/vm/classcompat.h 中出现MethodTable* m_pMethodTable成员而MethodTable正是 CoreCLR 中对象类型信息的运行时表示vtable 指针、GC 布局信息、继承层次等都挂在MethodTable上。CLR 的托管对象布局以MethodTable指针开头这使“基类指针→派生类指针”的向上转换可静态判定、向下转换必须在运行时对照继承层次检查与原文描述一致。可验证代码静态验证 少量运行时检查概念上强制类型安全需要检查程序的每一个操作确认其操作的内存类型与操作兼容。全部在运行时做会非常慢因此 CLR 采用CIL 验证在代码运行前对 CIL 做静态分析确认大多数操作确实是类型安全的只有静态分析做不完整时才需要运行时检查。实践中所需的运行时检查非常少包括把基类指针转换为派生类指针反方向可以静态检查数组边界检查与内存安全部分相同把指针数组的某个元素赋值为新的指针值。这个检查之所以必要是因为 CLR 数组的转换规则较为宽松。这些检查反过来对运行时提出三条要求GC 堆上所有内存必须打上类型标签使 cast 操作符可实现。类型信息必须在运行时可用且足够丰富以判断 cast 是否有效例如运行时必须知道继承层次。事实上GC 堆上每个对象的第一个字段就指向代表其类型的运行时数据结构所有数组必须携带其大小供边界检查数组必须携带完整的元素类型信息。幸运的是最昂贵的要求给每个堆对象打标签本来就是 GC 所必需的GC 需要知道每个对象的哪些字段是需扫描的引用因此提供类型安全的额外成本很低。代价是编程灵活性的损失CLR 虽有通用内存访问操作符但代码要可验证就只能以极受限的方式使用它们——所有指针算术都无法通过验证。因此许多经典 C/C 写法不能用于可验证代码必须改用数组。这个约束其实不算苛刻数组相当强大而收益少得多的“难缠” bug是实实在在的。CLR 强烈鼓励使用可验证的类型安全代码即便存在需要不可验证编程的时刻主要发生在与非托管代码打交道时CLR 也允许但最佳实践是尽量把不安全代码限制在小范围——典型程序只有一小部分代码需要 unsafe其余都可以是类型安全的。七、高级语言特性GC 支持对运行时影响深远——它要求所有代码都支持额外簿记。类型安全的诉求同样影响深远要求程序描述CIL处于高级层次字段与方法都携带详细类型信息。类型安全还迫使 CIL 支持其它类型安全的高级编程构造而这些构造的类型安全表达又需要运行时支持。其中两个最重要的特性服务于面向对象程序设计的两个基本要素继承与虚调用分派。面向对象编程继承在机械上相对简单若类型derived的字段是base字段的超集且derived布局字段时让base的字段在前那么任何期望指向base实例指针的代码得到指向derived实例的指针都能“直接工作”。这就是derived继承自base的含义——derived可在任何base可用的地方使用。代码因此成为多态的同一段代码可用于许多不同类型。因为运行时必须知道哪些类型强制转换是合法的它必须把继承的表示方式形式化以便验证类型安全。虚调用分派是继承多态的推广基类声明的方法可被派生类重写使用base类型变量的代码可以期望对虚方法的调用会基于对象运行时实际类型分派到正确的重写版本。这样的运行时分派逻辑用原始 CIL 指令也能实现但有两个严重劣势它不是类型安全的分派表中的错误是灾难性错误每个面向对象语言很可能以略微不同的方式实现自己的虚分派逻辑结果是语言间互操作受损一种语言无法从另一种语言实现的基类型继承。因此 CLR 直接支持基本的面向对象特性并尽可能使继承模型“语言中立”——不同语言仍可共享同一继承层次。可惜并非总能做到多重继承有很多实现方式CLR 选择不支持带字段的类型的多重继承但支持从一类特殊类型接口多重继承接口被约束为不能携带字段。注意运行时支持这些面向对象的概念但不要求使用它们——没有继承概念的语言如函数式语言只是不使用这些机制。值类型与装箱面向对象中一个深刻而微妙的方面是对象标识object identity即使所有字段值完全相同由不同分配调用创建的对象仍可被区分。对象标识与“对象按引用指针而非按值访问”紧密相关两个变量持有同一对象指针指向同一内存时更新一个会影响另一个。可惜对象标识并非对所有类型都是好的语义匹配程序员通常不认为整数是对象。数字1在两个不同地方被分配时程序员通常希望认为这两者相等绝不希望更新其中一个会影响另一个。事实上有一大类语言函数式语言干脆避开对象标识与引用语义。可以有“纯粹”的对象系统Smalltalk-80 连整数都是对象但需要相当的实现“体操”才能恢复高效实现Perl、Java、JavaScript 等语言采取务实立场整数等按值处理其它按引用处理。CLR 也选择了混合模型但与其它语言不同它允许用户定义值类型。值类型的关键特征值类型的每个局部变量、字段或数组元素都持有数据的一份独立拷贝一个变量、字段或数组元素赋值给另一个时值被拷贝相等性只由变量中的数据定义与位置无关每个值类型都有一个对应的引用类型只有一个隐含的无名字段即其装箱值boxed value。装箱后的值类型可以参与继承并拥有对象标识尽管强烈不推荐使用装箱值类型的对象标识。值类型非常贴近 C/C 的 struct或 C class概念。与 C 一样你可以拥有指向值类型的指针但指针类型与 struct 类型本身是不同的类型。异常CLR 直接支持的另一个高级编程构造是异常允许程序员在失败发生的点“抛出”一个任意对象。对象被抛出后运行时在调用栈中搜索声明了可以捕获该异常的 catch 子句找到后执行从该点继续。异常的价值在于避免一个极常见的错误不检查被调用方法是否失败。既然异常帮助避免程序员错误从而让编程更容易CLR 支持它也就不足为奇。顺带一提异常避免了一类常见错误不检查失败但没有阻止另一类错误失败发生后把数据结构恢复到一致状态。这意味着捕获异常后一般很难知道继续执行是否会引起由最初失败导致的额外错误——这是 CLR 未来可能继续增值的领域。即便按现状实现异常也是巨大的进步。参数化类型泛型在 CLR 2.0 之前唯一的参数化类型是数组其它所有容器哈希表、列表、队列等都只操作通用的Object类型。无法创建ListElemT或DictionaryKeyT, ValueT确实有负面的性能影响值类型进入集合时需要装箱取出元素时需要显式 cast但这不是给 CLR 添加参数化类型的首要原因。主要原因是参数化类型让编程更容易。道理微妙想象如果类库中所有类型都被替换成通用的Object会得到什么样的类库——这与 JavaScript 等动态类型语言中的世界颇为相似。在那样的世界里程序员写出“错误但类型安全”的程序的方式多得多这个参数到底应该是列表字符串整数还是都可以从方法签名上已经看不出来了。更糟的是当方法返回Object时还有什么方法能接受它作参数典型框架有数百个方法如果全部接受Object参数判断哪个Object实例对该方法执行的操作有效将非常困难。简言之强类型帮助程序员更清楚地表达意图并让工具如编译器强制执行其意图带来巨大的生产力提升。这些好处不会因为类型被放进List或Dictionary而消失参数化类型显然有价值。真正的问题是参数化类型是应当“在生成 CIL 前被编译掉”的语言特性还是应有运行时的一等支持两种实现都可行。CLR 团队选择一等支持原因是否则各语言会各自实现互操作将非常繁琐此外参数化类型表达程序员意图的最大价值恰好在类库的接口上——如果 CLR 不正式支持参数化类型类库就无法使用它将失去一项重要的易用性特性。程序即数据反射 APICLR 的基本面——GC、类型安全、高级语言特性——迫使程序规范CIL保持相当高的层次。一旦这份数据在运行时存在C 或 C 程序并不如此把它暴露给最终程序员的价值就显而易见了于是有了System.Reflection接口“反射”之意程序可以审视/反思自身。这组接口让你几乎可以探查程序的所有方面它有哪些类型、继承关系、存在哪些方法与字段。损失的信息少到可以为托管代码写出非常好的“反编译器”如 ILSpy 等工具——对知识产权保护者而言这令人咋舌可通过一种称为混淆obfuscation的、有意销毁信息的操作来缓解但这件事本身正是托管代码运行时信息丰富度的见证。除了检查还可以对程序执行操作如调用方法、设置字段甚至最强大的能力在运行时从头生成代码System.Reflection.Emit。运行时类库本身就利用该能力例如System.Text.RegularExpressions用它创建字符串匹配的特化代码对象序列化存文件、跨网络发送也依赖它生成代码。这类能力在以前根本不可行你得写一个编译器如今却触手可及。不过反射的能力应当谨慎使用它通常显著慢于静态编译的等价物更重要的是自指系统天生更难理解。因此 Reflection 与 Reflection.Emit 这类强大特性只应在价值明确且重大时使用。当前仓库中 src/libraries/System.Reflection.Emit/src 即为该子系统的源码System.Text.RegularExpressions同样位于 src/libraries/System.Text.RegularExpressions可直接印证上述运行时自举用法。八、其它特性互操作、AOT 与线程第三组特性与 CLR 的基本架构GC、类型安全、高级规范无关但填补了完整运行时系统的重要需求。与非托管代码互操作托管代码必须能使用非托管代码实现的功能。互操作有两个主要“风味”直接调用非托管函数——即Platform InvokeP/InvokeCOMComponent Object Model——非托管代码的面向对象互操作模型比临时性的方法调用更有结构。COM 与 CLR 都拥有对象模型和一系列约定错误处理方式、对象生命周期等因此 CLR 若对 COM 提供特殊支持互操作能做得更好。预先编译Ahead of Time Compilation在 CLR 模型中托管代码以 CIL 而非本地代码分发到本地代码的转换发生在运行时。作为一种优化由 CIL 生成的本地代码可以用crossgen工具保存到文件中类似 .NET Framework 的 NGEN 工具避免运行时的大量编译时间。由于类库规模庞大这一点非常重要。从源码结构看当前仓库中该机制已演进为crossgen2ReadyToRundocs/design/coreclr/botr/clr-abi.md 中提到 “crossgen2 emits these stubs into the R2R image so the runtime can transition between execution modes without generating code dynamically”docs/design/coreclr/botr/guide-for-porting.md 也讨论了将 Ready To Run 编译器crossgen/crossgen2引入构建的流程完整的 R2R 格式与流程分别见 readytorun-overview.md 与 readytorun-format.md。原文所述“crossgen 保存本地码以避免运行时编译”的优化目标在今天的 .NET 中由 R2R 映像全面承接。线程CLR 从一开始就充分预期了托管代码多线程程序的需求。CLR 类库从一开始就包含System.Threading.Thread类它是操作系统线程的 1:1 包装。但由于只是 OS 线程的包装创建System.Threading.Thread相对昂贵启动需要毫秒级。这对许多场景没问题但有一种编程风格创建非常小的工作项仅耗时几十毫秒甚至更少服务器代码每个任务只是服务一个网页或利用多处理器的代码如多核排序算法。为支持这种场景CLR 引入了ThreadPool概念允许排队 WorkItem由 CLR 负责创建执行工作所需的线程。从实现角度看ThreadPool 的关键创新是它负责确保以最优数量的线程来分派工作。CLR 使用一套反馈系统监测吞吐率与线程数并调整线程数以最大化吞吐。这很好因为程序员可以主要按“暴露并行性”即创建工作项来思考而不必纠结于更微妙的问题——确定合适的并行度它取决于工作负载与程序运行的硬件。从源码结构看当前仓库中线程池的实现位于 src/libraries/System.Threading.ThreadPool/src托管侧封装包括AbandonedMutexException.cs、AsyncLocal.cs等而线程池的核心调度反馈环位于 CoreCLR 虚拟机层线程的完整设计说明见 BOTR Threading 章节。九、总结与延伸资源CLR 做的事情很多——仅仅描述其部分特性、尚未触及内部细节就用去了数页。本文的框架可归纳为运行时是支持编程语言的完整框架运行时的目标是让编程变简单运行时的基本特性是垃圾回收、内存与类型安全、高级语言特性支持。沿着这个框架继续深入的入口均为当前仓库内文档路径相对仓库根目录Book of the Runtime 总目录BOTR 全部章节的导航面向希望深入理解或修改 .NET 运行时的读者Garbage Collection DesignGC 的完整设计文档对应本文第四节“所有引用必须被跟踪”的展开Threading线程与线程池的运行时实现细节ReadyToRun Overviewcrossgen2/NGEN 式预先编译的 R2R 映像机制总览CLR ABI托管/非托管边界的现代 ABI 约定.NET Standards 文档对应原文档引用的 ECMA 标准化脉络与 .NET 标准说明Framework Design Guidelines 摘要对应原文档引用的“800 页设计准则”在当前仓库中的摘要指导托管类库的命名与设计一致性源码入口GC 实现 src/coreclr/gc/gcscan.cpp、mark_phase.cpp、sweep.cpp等、类型系统 src/coreclr/vm/MethodTable相关头文件、线程池 src/libraries/System.Threading.ThreadPool/src、运行时代码生成 src/libraries/System.Reflection.Emit/src。需要说明的适用前提本文所依据的原始文档由 Vance Morrison 于 2007 年撰写文中部分历史背景如 AppDomain 隔离、MarshalByReference、NGEN/crossgen 命名反映的是 .NET Framework 时代的设计当前仓库.NET 运行时中AppDomain 等概念已被裁剪或弱化crossgen 已由 crossgen2/ReadyToRun 取代AOT 编译则进一步发展为 NativeAOT 与 Mono AOT 管线。阅读时以“基本架构不变、具体机制演进”为视角即可。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考