📚 **严老师 · Day 8 教学（Phase 2 开篇）**

<!-- message_id: om_x100b686642e744a0b48824e1d69c6df --> 📚 **严老师 · Day 8 教学（Phase 2 开篇）** 主人早。Phase 1（C# 核心机制 7 个知识点）已收官。从今天起进入 **Phase 2：.NET 运行时**。 Phase 2 的目标是把你从"会用 C#"拉到"懂 CLR 在干嘛"——任何 WPF 高性能方案、任何疑难 GC 问题、任何诡异内存泄漏，都绕不开今天的主题。 ─── 📖 今日知识点：CLR 内存模型与 GC 机制 1. 是什么 CLR GC 是基于 **"分代假设"（Weak Generational Hypothesis）** 的 **追踪式 + 标记-压缩** 垃圾回收器。它把堆分成 5 个区： | 区 | 用途 | 阈值 | 压缩 | | ---------- | ---------------------- | -------- | -------- | | Gen 0 | 新分配短命对象 | 典型几 MB | ✅ | | Gen 1 | Gen0 存活晋升缓冲 | ~2×Gen0 | ✅ | | Gen 2 | 长命对象 | ~10×Gen1 | ✅ | | LOH（大对象堆） | ≥ 85,000 字节 | 无固定上限 | ❌（默认不压缩） | | POH（钉住对象堆） | < 1000 字节的 pinned 短命对象 | .NET 5+ | ✅ | 对象从 Gen0 → Gen1 → Gen2 逐代**晋升**（survive 一次 GC 提升一代）。Gen2 + LOH 一起被叫 **"全堆"（Full Heap）**。 2. 为什么 **分代假设**：程序里绝大多数对象都是短命的（典型应用 80-95% 的对象活不过 Gen0 GC）。 如果每次 GC 都扫描整个堆，开销是 O(堆大小)。分代之后： • **Gen0 GC**：只扫 Gen0（小、快、频繁），典型 < 1 ms • **Gen1 GC**：作为 Gen0 → Gen2 的缓冲 • **Gen2 GC**（Full GC）：全堆扫描，代价大但频率低 这就是 GC 的 **"用时间换空间，用频率换吞吐"** 哲学。 3. 怎么用（关键 API） // === 查询 / 监控 === int gen = GC.GetGeneration(obj); // 对象在第几代 int gen0Count = GC.CollectionCount(0); // Gen0 GC 累计次数 long bytes = GC.GetTotalMemory(forceFullCollection: true); // 估算占用 // === 关键路径禁用 GC（性能核武器）=== if (GC.TryStartNoGCRegion(totalSize: 64 * 1024)) { try { // 在这个区间内，GC 不会触发（但分配不能超 totalSize） ProcessCriticalPath(data); } finally { GC.EndNoGCRegion(); } } // === 延迟模式（控制 GC 时机）=== GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency; // WPF 默认值 // === 非托管内存提示（防止 OS 误判空闲）=== GC.AddMemoryPressure(1024 * 1024); // 告诉 GC：有 1MB 非托管内存占用 // ... 用完 ... GC.RemoveMemoryPressure(1024 * 1024); // === 池化复用（避免反复分配/GC）=== using Microsoft.Extensions.ObjectPool; var pool = ObjectPool.Create<Tick>(poolPolicy); var tick = pool.Get(); // 从池里取（无 GC 分配） // ... 使用 ... pool.Return(tick); // 还回去 4. 常见误区（资深也会踩） | 误区 | 真相 | | ------------------------- | -------------------------------------------------------------------------------------------------------------- | | "频繁 GC.Collect() 能让程序更流畅" | ❌ 几乎总是更慢。Full GC 扫全堆，还可能引发 Gen2 + LOH 压缩，把 LOH 里的大对象搬来搬去 | | "GC.Collect() 会把内存还给 OS" | ❌ 未必。GC 只回收进程内堆，是否归还 OS 取决于段（segment）空闲度。Workstation GC 几乎不还，Server GC 才频繁还 | | "Dispose() 会触发 GC" | ❌ 完全无关。Dispose 只是清理非托管资源（文件句柄、Socket、IntPtr），跟 GC 没关系 | | "Server GC 桌面应用一定更好" | ❌ 未必。Server GC 每 CPU 一个堆，分配并行；但单线程桌面程序用 Server GC 可能 Gen0 更大、内存占用翻倍 | | "LOH 会自动压缩" | ❌ 默认不压缩。.NET 4.5.1+ 可手动 GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce | | "对象池一定能降 GC" | ⚠️ 看场景。如果池化对象引用被异步回调捕获，反而延长存活代龄，对 Gen0 收菜不利 | 5. 关联知识 • **Day 1 值类型 vs 引用类型**：引用类型总在堆上（除非 stackalloc / Span<T>），这是 GC 唯一关心的对象 • **Day 7 Span / ref struct**：ref struct 禁上堆 → 永远不会进 GC，是零分配利器 • **Day 4 async/await 状态机**：状态机对象本身是引用类型，每次 await 都可能进 Gen0 ─── （接下条面试题） --- <!-- message_id: om_x100b6866426f70a0b1f7013cad488be --> 📝 今日 3 道递进面试题 Q1（基础概念 · 记忆+理解） **.NET CLR GC 的"分代假设"（Weak Generational Hypothesis）是什么？为什么 .NET 把堆分成 Gen0/Gen1/Gen2 三代，而不是只用一个大堆一次扫？** 要点： - 说出"绝大多数对象短命"这个观察 - 解释为什么分代能把"全堆扫描"退化成"小堆频繁扫 + 大堆偶尔扫" - 至少答出 Gen0 GC vs Full GC 的典型耗时差异 Q2（原理与辨析 · 深入） **LOH（大对象堆）为什么默认不压缩？.NET 5 引入的 POH（钉住对象堆，Pinned Object Heap）又解决了什么问题？请结合内存碎片与 pinned 对象的影响说明。** 要点： - LOH ≥ 85,000 字节阈值由来（避免复制大块开销 + 缓存局部性） - LOH 不压缩 → 分配用空闲链表 → **碎片化**风险（典型表现：进程占用 2GB，但新分配 100MB 失败） - POH 设计：放 < 1000 字节的 pinned 短命对象（比如 GCHandle.Alloc(obj, GCHandleType.Pinned) 的小对象），避免这些 pinned 钉子把 LOH 划成碎片 - 至少提一次 .NET 5+ 的 GC.AllocateArray<T>(length, pinned: true) API（内部用 POH） Q3（实战与深度 · 复杂场景） **场景**：你在做一个 WPF 实时行情推送终端（每秒 1 万条 tick，每条 ~200 字节），行情窗口 1000 行情 × 60 fps 更新。要求 UI 不卡顿、内存稳定、CPU 占用 < 30%。 **问题**：请给出 **5 层零 GC 架构**，并说明每一层具体用什么技术、解决什么 GC 压力。诊断手段有哪些？备选方案权衡如何？ （这一题是今天的主菜——把 Day 1/4/7 的所有武器串起来实战） 主人看一下今天内容，先思考 Q1+Q2，Q3 我会单独发出来。 --- <!-- message_id: om_x100b686643c010a0b1cf408078c526a --> 📝 Q3 详细题目 **场景细化**： ┌──────────── 网络层 ────────────┐ │ UDP Multicast 推送 1 万 tick/s │ │ 每条 ~200 字节 │ └─────────────────────────────────┘ ↓ ┌──────────── 业务层 ────────────┐ │ 解析 + 行情聚合 + 触发 UI 更新 │ └─────────────────────────────────┘ ↓ ┌──────────── UI 层 ────────────┐ │ 1000 行情 × 60 fps 更新 │ │ 滚动价格 + 闪烁变色 + 折线图 │ └─────────────────────────────────┘ 性能红线： • UI 帧时间 < 16 ms（60 fps） • 进程内存稳定（8 小时运行 ≤ 2 GB） • CPU < 30% **问题**： 请设计 **5 层零 GC 架构**，每一层用具体技术解决具体的 GC 压力： 1. **网络层**：用什么缓冲技术？对象池怎么用？ 2. **解析层**：如何避免每条 tick 都 new 一个对象？ 3. **业务层**：状态聚合怎么避免 Gen0 风暴？ 4. **调度层**：怎么节流 60 fps？用 Dispatcher 还是 CompositionTarget？ 5. **UI 层**：1000 行情怎么渲染才能不卡顿？ **诊断手段**： - 用什么工具监控 GC 行为？（至少 2 个工具 + 关键指标） - 怎么判断"GC 风暴"已经发生？ **备选方案对比**： - 对象池 vs GC.TryStartNoGCRegion 哪个更合适？ - ArrayPool<byte> vs 手动 byte[] 复用？ - 同步渲染 vs 虚拟化？ 先到这，等你三题答完（或部分答完）我就给完整复盘。