📚 课程目录第4章 NET运行时与CLR原理

第4章 .NET运行时与CLR原理：GC、JIT、程序集加载、类型系统

本章定位：深入理解CLR核心机制是区分高级与普通开发者的分水岭。面试中GC、JIT、程序集加载几乎必考，且常结合项目实战追问。

记忆口令：触发→标记→代际→压缩→LOH。回答GC问题时按此链条展开，并主动补充“Server GC配置”与“内存泄漏排查”更是加分项。

---

面试问题	请解释 .NET 垃圾回收（GC）的工作原理，包括代际、触发时机和压缩过程。
面试官考察点	是否理解 GC 核心机制（根标记、代际、压缩）；能否区分 Server GC / Workstation GC；是否关注大对象堆（LOH）问题。
回答框架	1. 触发条件（内存不足、GC.Collect、代阈值）→ 2. 根标记（栈、静态变量等 root）→ 3. 代际回收（Gen0/1/2 逐步升级）→ 4. 压缩与清理（内存整理）→ 5. LOH 特殊处理（不压缩，易产生碎片）→ 6. 补充 Server/Workstation GC 区别。
简短示例回答	GC 在分配内存不足时触发，从 GC Roots 扫描存活对象，按代际回收：Gen0 最频繁，存活对象提升至 Gen1/2。压缩阶段整理内存避免碎片。大对象堆（>85KB）不压缩，需单独关注。Server GC 为高吞吐多线程设计，Workstation GC 更省 CPU。
可能追问	如何判断 GC 压力过大？如何选择 GC 模式？如何减少 GC 停顿？
避坑提醒	❌ 只说“自动回收”太泛；❌ 忽略 LOH；❌ 混淆 Server/Workstation 使用场景。✅ 应主动说明 GC 对性能的影响及调优手段。

面试问题	解释 JIT 编译和 AOT 编译的区别，以及在 .NET 中各自的优缺点。
面试官考察点	是否理解 JIT 的即时编译流程与 Tiered JIT；是否了解 AOT（ReadyToRun / Native AOT）的应用场景；能否结合实际项目做技术选型。
回答框架	1. JIT 在运行时将 IL 编译为机器码，支持动态优化（Tiered JIT）→ 2. AOT 提前编译成二进制，启动快但失去动态优化 → 3. .NET 中的 ReadyToRun（部分 AOT）与 Native AOT（完全 AOT）对比 → 4. 适用场景：JIT 更灵活，AOT 适合云原生/冷启动敏感场景。
简短示例回答	JIT 在方法首次调用时编译，Tiered JIT 先快速编译再优化，平衡启动与性能。AOT 如 ReadyToRun 提前生成机器码，减少启动时间但失去运行时优化。Native AOT 完全无 JIT，适合 Docker 容器与函数计算。
可能追问	什么是 Tiered Compilation？如何配置？使用 AOT 交付的常见限制有哪些？
避坑提醒	❌ 只说“JIT 慢 AOT 快”过于片面；❌ 忽略 Tiered JIT 的分阶段优化；✅ 要区分 ReadyToRun 与 Native AOT 的差异，并提及反射、动态生成等限制。

面试问题	描述 .NET 中程序集的加载过程，以及 AssemblyLoadContext 的作用。
面试官考察点	是否理解默认加载上下文与自定义加载上下文；是否了解程序集版本冲突（DLL Hell）及解决方案；是否深入掌握类型统一性（singleton per load context）。
回答框架	1. 程序集加载入口（Assembly.Load / LoadFrom）→ 2. 默认加载上下文（Default ALC）与探测路径 → 3. AssemblyLoadContext 自定义隔离 → 4. 类型加载规则（依赖检查、强命名）→ 5. 插件系统与版本冲突的处理。
简短示例回答	程序集加载先查找 GAC，再搜索应用目录。默认 AssemblyLoadContext 管理主应用，自定义 ALC 可实现插件隔离，避免类型冲突。每个 ALC 有独立的类型标识，同一类型在不同 ALC 中被视为不同。
可能追问	如何调试程序集加载失败？Assembly.Load 与 Assembly.LoadFrom 的区别是什么？
避坑提醒	❌ 混淆 Load 与 LoadFrom 的文件锁定行为；❌ 忽略 ALC 导致的类型不兼容（例如无法直接转换）；✅ 应该提及 `AssemblyDependencyResolver` 以及自定义解析策略。

---

背景匹配：本案例在面试中可灵活套用于“秒杀”、“支付”、“网关”等高频低延迟场景，重点突出 CLR 内存调优与 GC 经验。

项目名称	电商秒杀订单处理服务（OrderFlow Engine）
业务背景	双十一秒杀场景下，订单创建峰值 QPS 达 10 万+，订单对象在内存中高频创建与销毁，导致 GC 频繁停顿（World Stop），影响平均响应时间（从 20ms 飙升至 500ms）。
规模指标	单机 QPS 约 3 万，4 核 8GB 内存；集群 30 节点；内存消耗 4.2GB；GC 暂停高峰达 150ms/次。
技术栈	.NET Core 3.1、ASP.NET Core、Entity Framework Core、Redis、Kafka、Serilog、Prometheus + Grafana 监控
核心难点	1. Gen2 GC 停顿导致接口超时；2. 订单对象频繁分配到 LOH（字段含大字符串）；3. 默认 Workstation GC 无法利用多核。
面试高频追问	你如何确定 GC 是瓶颈？采用哪些手段减少 GC 压力？如何配置 Server GC 并验证效果？是否用对象池？结构体 vs 类的权衡？
可迁移回答话术	“我们先用 PerfView 捕获 GC 事件，发现 Gen2 GC 次数偏高；随后将 `gcServer` 设为 true，并调整 `GCLatencyMode` 为 SustainedLowLatency；同时将订单实体的大字符串拆分为 `struct` 边值类型，并引入 `ObjectPool<OrderRequest>` 复用临时对象，最终 Gen0 GC 时间降至 2ms 以下，P99 延迟稳定在 30ms。”

面试话术迁移提示：此案例适用于所有涉及“高并发”、“内存优化”、“GC 调优”的问题。回答时先描述现象（监控指标），再给出方案（配置调整+代码优化），最后展示结果数据（延迟/吞吐量提升）。