简介《.NET内存宝典》是一本系统讲解.NET内存管理与性能调优的技术专著比《CLR via C#》在内存机制上更为聚焦深入适合中高级.NET开发者作为进阶与案头参考书研读。书中重点讲解垃圾回收、代际模型、对象分配与生命周期、内存碎片成因并结合实际案例演示PerfView等诊断工具的使用方法帮助定位内存泄漏和性能瓶颈。同时覆盖非托管资源释放、对象池化、装箱与拆箱开销以及多线程与异步编程下的内存可见性内容系统且贴近实战对排查高内存占用与垃圾回收停顿很有帮助。资源为1个PDF电子书压缩包约24.27MB章节安排由浅入深适合离线阅读和反复查阅。已有381人学习下载无论是夯实内存知识体系还是优化服务端高并发应用的性能与可扩展性都能从中获得系统的诊断思路与优化方案。1. 为什么内存管理值得单开一本书不只是《CLR via C#》顺带讲的那一章线上服务内存三天涨了1.8GB业务量纹丝不动GC每秒触发几十次CPU却一直满负荷……这种问题本质上是 .NET 内存管理的功课没补上迟早会遇到不如一次解决。《Pro .NET Memory Management》国内常叫 .NET 内存宝典就是为这件事写的。很多人拿它和《CLR via C#》比CLR 是一张全景地图内存只是众多章节之一这本从硬件缓存、虚拟内存讲起一路深入到 GC 内部和诊断工具全程只围绕内存一件事。适合被 OOM 和 GC 抖动折磨过的后端与桌面开发者也适合面试前突击内存知识的人。读之前你最好写过一年左右 C#知道 class 和 struct 的基础差异。没写过也能看但只看理论不写代码效果会打折扣。2. 先把地基打牢寄存器机、缓存与虚拟内存如何决定托管代码性能2.1 栈、堆与寄存器机对象分配的真实路径在 CLR 里JIT 会把中间语言编译成机器码最终在 CPU 寄存器里求值。CLR 不是栈机而是寄存器机。JVM 的字节码执行模型是栈机操作数都压在操作数栈上CLR 编译过后绝大多数算术直接在寄存器里完成。这个差异直接决定值类型的去向。值类型只要不逃逸出当前方法就可以完全在栈上分配不碰托管堆一旦装箱、被全局引用或作为对象字段存在它才被挪到堆上。理解这一点就不会写出无意义的小对象堆化。下面这段代码展示了对象分配的真实路径struct Point { public int X; public int Y; } class Rectangle { public Point Location; public int Width; public int Height; } static long Demo() { var rect new Rectangle(); rect.Location new Point { X 3, Y 4 }; return rect.Location.X rect.Location.Y; }这里rect变量本身在栈帧里Rectangle对象在托管堆上Point作为Rectangle的字段嵌入在堆对象内部没有单独产生一次分配。把Point赋给object变量或转成某个接口时装箱才会把它的副本丢到堆上。在频繁调用的热路径上每多一次装箱就多一次堆分配。所以这本书开头花大篇幅讲栈与堆不是基础科普而是后续讨论 GC 压力的前提。2.2 顺序访问优于随机访问缓存局部性的差距不止一个数量级第二个基础是 CPU 缓存。从内存读一个对象大约 60 到 100 纳秒从 L1 缓存读只要 1 纳秒上下差距不止一个数量级。程序员的直觉经常低估这个差距只看算法复杂度 O(n)却不看缓存命中率。存储层级典型延迟典型容量L1 Cache约 1ns32KB 左右L2 Cache约 4ns256KB 到 1MBL3 Cache约 10ns8MB 以上主内存60 到 100ns按机器配置数组与链表的遍历就能看出差距// 顺序遍历数组预取器能按顺序把数据拉进缓存 long SumArray(int[] arr) { long acc 0; for (int i 0; i arr.Length; i) { acc arr[i]; } return acc; } // 遍历链表节点可能散布在整个堆的不同页里 long SumList(Node? head) { long acc 0; for (Node? n head; n ! null; n n.Next) { acc n.Value; } return acc; }同样数量节点链表随机跳指针会频繁打新缓存行数据量越大差距越明显。这也是为什么ListT多数时候比LinkedListT快一个是连续内存顺序访问一个是不连续内存随机访问。写代码时先想清楚节点内存分布再谈算法复杂度。2.3 操作系统与虚拟内存大页面、NUMA 和不同平台的内存布局再往下一层是操作系统。进程拿到的地址是虚拟地址操作系统分页管理通过页表翻译成物理地址。TLB 是页表的快速缓存直接决定每次内存访问的成本。默认 4KB 一页程序活动内存一大TLB 频繁失效启用大页面后一页覆盖 2MB 甚至更大TLB 条目不用增加覆盖范围翻了几十倍。Linux 上透明大页的开关常见位置是/sys/kernel/mm/transparent_hugepage/enabled# 查看当前状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 切换为 always生产环境务必先做性能对比 echo always /sys/kernel/mm/transparent_hugepage/enabled设置项有三个always对所有内存分配生效madvise只对显式声明了大页的内存生效never完全关闭。这个开关影响的是页面大小和分配对齐不是内存总量。需要注意透明大页不是免费午餐某些数据库和高并发服务在always模式下反而出现延迟抖动所以我一般先在测试环境开起来压一晚上确认稳定再上生产。NUMA 关注的是跨 CPU 访问远端内存的延迟差异。线程从自己所在的 Node 访问本地内存最快跨 Node 访问要加一次延迟。.NET Server GC 默认按 CPU 组建堆配置项里有HeapCount、NoAffinitize乱调前先看机器拓扑。常见做法是先执行lscpu看一眼 Node 拆分再决定要不要开相关配置。Windows 和 Linux 的进程内存布局不一样栈、堆、模块映射的位置都不同但开发者感知最深的是同一个现象虚拟内存大不代表物理内存忙。任务管理器里的工作集和GC.GetTotalMemory是两个口径书的工具篇章就是专门解决这种看走眼的问题。3. 没有度量就没有优化PerfView、dotnet-dump 与 perfcollect 的实操路径书里反复强调 Measure Early尽早度量用数据而不是感觉决策。常见误区是发现内存大就直接加内存或者手工调用 GC连基本计数器都没看过。工具先到哪后到哪直接决定排查效率。工具作用适合场景dotnet-counters实时看 GC 与内存计数器线上服务初步判断整体趋势PerfView / ETW追踪 GC 事件与分配详情定位 GC 频率与触发原因dotnet-dump抓进程快照做离线分析分析堆里对象分布与根引用perfcollectLinux 下抓取 GC 等核心事件容器与 Linux 环境VMMap看进程虚拟内存分布Windows 下确认虚拟内存增长3.1 先看计数器再看事件最后才看 dump不要上来就抓 dump。dump 一个运行一小时的进程再分析半天往往只看到结果看不到过程。正确顺序是先用计数器确认是持续增长还是正常波动再用事件看 GC 触发频率与原因确定有嫌疑对象再做 dump。dotnet-counters 会连接运行中的 .NET 进程读取运行库的 EventCounter 数据。命令示例dotnet-counters monitor --process-id 10086 --counters System.Runtime--process-id指定 PID我一般先在ps -ef输出里确认进程号再执行--counters System.Runtime表示订阅运行库提供的那组计数器。最常看的是这几个gc-heap-size托管堆当前大小。gen-0/1/2-gc-count各级别 GC 次数。cpu-usage进程实时 CPU。working-set物理内存占用。如果gc-heap-size曲线平稳但working-set一直上涨增长大概率来自非托管内存、文件映射或线程栈。别急着怀疑托管泄漏先看这些计数。3.2 Windows 下的 GC 事件PerfView 与 dotnet-dump 配合PerfView 是 Windows 上抓 GC 事件的首选。虽然它默认开 GUI但也可以先用命令行收集减少对目标进程的干扰PerfView.exe /nogui /GCCollectOnly collect mytrace.etl/nogui表示收集完不打开界面/GCCollectOnly只启用 GC 相关提供程序减少采集量收集结果落在mytrace.etl。注意全量 ETW 采集会暂停系统务必先在小流量窗口验证。收集完成后双击打开mytrace.etl进入 Memory Group查看 GC Stats 和 Heap Allocations。GC Stats 会列出每次 GC 的耗时、原因和代际Heap Allocations 按调用栈聚合分配量一下就能看出哪条热路径在疯抢堆内存。抓到大堆后如果需要看对象细节用 dotnet-dumpdotnet-dump collect --process-id 10086 --output web.dmp dotnet-dump analyze web.dmpcollect做一次进程快照analyze进入交互式分析会话。会话里我常用两招dumpheap -stat clrstackdumpheap -stat按类型统计托管堆对象数量和总大小能快速看到哪类对象占了大头clrstack打印当前线程的托管调用栈配合看哪个调用点正在分配。分析完输入quit退出。这套组合能回答绝大多数“到底是谁分配了这么多对象”的问题。3.3 Linux 与容器环境perfcollect 打开另一扇门生产容器里跑 PerfView 不方便Linux 常用开源工具是 perfcollect。它依赖内核的 perf 事件跑起来通常需要 root 权限sudo perfcollect install sudo perfcollect collect mytraceinstall会安装内核符号和依赖的设备采集工具首次运行需要预置包或能从源拉取collect mytrace开始追踪默认按时间窗口和内存大小生成追踪文件。收集结束后可以把得到的追踪数据导入 Trace Compass 打开或者转换后交给熟悉的分析环境。跑容器的同事最关心“采集过程会影响业务吗”——perfcollect 采集时对目标进程是只读式采样影响比 ETW 全量追踪小但内核侧符号解析仍要占用系统资源。我会先在预发容器跑一次完整采集确认没有明显延迟抖动再上生产。在拿到第一份数据之前不要下任何“内存泄漏”的结论。这是整本书诊断章节最想纠正的习惯。4. GC 不是黑匣子分代、触发点与运行时配置参数打开 System.Runtime 计数器经常看到 Gen0 一分钟几十次Gen2 半个钟不来一次。这不是异常分代回收本来就这么设计的。真正要看的是 Gen2 与gc-heap-size的配合Gen2 频繁说明跨代际存活对象多或者 LOH 出问题。先读懂这三个数字再动配置。4.1 分代与堆分区为什么 Gen0 天天忙、Gen2 难得清静.NET GC 用的是分代追踪回收。新对象进第 0 代活过一次回收后晋升到第 1 代再活过一次到第 2 代。代龄越大回收频率越低Gen0 回收非常频繁Gen2 可能几分钟甚至几小时才来一次。两个没有代际概念的区域是 LOHLarge Object Heap和 POHPinned Object Heap。LOH 的对象默认超过 85KB 就进回收后不压缩容易碎片化POH 是 .NET Core 3.0 之后引入的固定对象单独放避免固定对象把普通小对象堆的压缩过程搅乱。代码里很容易观察到这个分界byte[] small new byte[80_000]; // SOH进 Gen0 byte[] big new byte[100_000]; // LOH超过 85KB 阈值80KB的数组走小对象堆参与代际晋升100KB的数组直接进 LOH回收代价按大对象算而且默认不压缩。如果面试或面试别人把“大对象堆不压缩导致碎片”这个问题答清楚比背十个配置名有用得多。4.2 GC 模式与运行时开关Server、Concurrent、HeapHardLimitGC 有两种基本模式Workstation GC工作站和 Server GC服务器。工作站 GC 多用于桌面程序回收在触发它的线程上做服务器 GC 为每个逻辑 CPU 核心建一个托管堆与一个 GC 线程吞吐率高但线程数也多小容器里容易过度配置。与模式并列的是并发还是后台回收。旧式并发回收有暂停窗口后台 GC 在后台线程执行部分回收主线程继续跑业务。默认配置在多数服务器上是 Server 后台这些在 runtimeconfig.json 里都能改{ runtimeOptions: { configProperties: { System.GC.Server: true, System.GC.Concurrent: true, System.GC.HeapHardLimit: 1073741824, System.GC.HeapHardLimitPercent: 3, System.GC.LOHThreshold: 102400 } } }配置项作用常见取值System.GC.Server开启服务器 GCtrue / falseSystem.GC.Concurrent后台回收true / falseSystem.GC.HeapHardLimit托管堆硬上限字节数System.GC.HeapHardLimitPercent按进程内存百分比限制0 到 100System.GC.LOHThresholdLOH 阈值字节数这套配置不是越多越好。我见过把 HeapHardLimit 设太小的服务GC 被压得频繁阻塞吞吐反而掉一半。调参必须跟指标走先看默认配置下的 GC 暂停和堆增长再决定要不要限制。4.3 触发条件的三个来源分配、内存压力、显式调用GC 触发有三个主要来源。第一是分配压力比如 Gen0 满了第二是系统内存压力高第三是代码显式调用GC.Collect()。显式调用不是完全不能碰但绝大多数业务代码里轮不到你替 GC 做决定。需要它的时候是进程即将进入对延迟敏感的空闲窗口而且你确认堆里确实有大量一次性质对象否则不要碰。注意GC.Collect属于高危操作默认不要出现在业务代码里。理解触发点是为了读dotnet-counters里的gen-0/1/2-gc-count如果 Gen2 次数高得离谱优先检查 LOH 分配和进程内存压力如果 Gen0 次数极密说明热路径上存在大量临时对象该找分配热点而不是加内存。下一章的避坑记录全部来自这些场景里栽过的跟头。5. 避坑手册五个把我坑过一遍的内存陷阱避坑不是看二手经验就能学会的这里记录的五条都来自我的实际处理经历每条按现象、原因、解决三步说清方便照做。5.1 现象内存只涨不降怎么看都像泄漏现象working-set三天涨了 1.5GB抓 dump 找不到大对象托管堆大小也只是略有增加。原因非托管资源没有被释放。文件句柄、socket、Marshal.AllocHGlobal分配的内存或者某个第三方组件在后台保持着一块非托管缓存。托管堆再干净进程内存也会继续涨。解决先用dotnet-counters分开两类指标。gc-heap-size平稳、working-set上涨时用系统工具看VmRSS同时检查句柄和 GDI 对象数量长期做法是给非托管资源统一走IDisposableusing并单独记录打开后必须关闭。5.2 现象开了 Server GC 后反而更频繁卡顿现象换到多核机器后把System.GC.Server打开GC 次数没少服务延迟反而上升。原因容器 CPU 限制下Server GC 按可见逻辑核心数建堆线程切换和堆同步开销把收益吃掉了。一个小容器拿到 32 核的配置创建几十个 GC 线程光调度就够喝一壶。解决在容器里先看ProcessorCount实际暴露了几核再决定是否启用 Server GC。更常见的做法是保留默认 Workstation 后台回收或者用System.GC.HeapCount把堆数限制到容器允许的核心数。调完后用 GC 暂停指标反向验证别按“核心多就该 Server”的经验办事。5.3 现象StringBuilder 已经用了内存还是在涨现象日志拼接都改成了StringBuildergen-0-gc-count没有明显下降。原因StringBuilder.ToString()每次都会产出一个新字符串如果日志模板里还有参数插值$在编译后会生成string.Format或默认插值处理器最终仍有点临时分配。StringBuilder 只是降低了拼接次数没有消灭最终的字符串对象。解决把日志模板缓存为常量枚举值预处理成字符串再拼接高 QPS 场景给字符缓冲走对象池而不是反复new StringBuilder。这一条靠 GC 分配统计确认光看代码看不出门道。5.4 现象PerfView 一开服务立刻抖动现象只在高峰期抓 60 秒 ETW服务 P99 直接翻倍业务方开始打电话。原因全量事件追踪会让系统短暂停顿GC 本身又叠加了额外事件度量过程影响了被测系统。书中对采集手段的侵入性有过明确提醒。解决先在低峰期测一次/GCCollectOnly的暂停影响如果必须高峰采集缩小采集范围只开 GC 事件关掉 Context Switch 等重型提供程序或者退而求其次用dotnet-counters的采样模式。5.5 现象Dispose 都写了内存还没立刻下来现象代码里所有实现IDisposable的对象都套了using但GC.GetTotalMemory升高的势头没停。原因Dispose只释放非托管资源它不回收托管堆内存。托管对象要等 GC 回收终结器型的资源还要额外一轮。把“释放”和“回收”混成一个概念是刚接触内存管理最容易翻车的地方。解决区分两类资源。非托管资源用Dispose保证确定性释放托管堆大对象走池化或数组租用降低 GC 压力。验证方式不是看GetTotalMemory而是看gen-0-gc-count是否下降。6. 把书用到日常写代码前先建一个分配基线书读完了最该带走的是“先度量再优化”的肌肉记忆。6.1 一条可复现的验证路径我现在的习惯是凡是要进热路径的函数先写一段几十毫秒的基准代码用GC.GetAllocatedBytesForCurrentThread前后对比。long before GC.GetAllocatedBytesForCurrentThread(); for (int i 0; i 100_000; i) { string id string.Format(ID-{0:D6}, i); // 优化前每次循环都有临时分配 } long allocated GC.GetAllocatedBytesForCurrentThread() - before;GC.GetAllocatedBytesForCurrentThread返回当前线程累计分配量适合做相对比较配合dotnet-counters看gen-0-gc-count能确认优化是否真的减少了 GC 压力。string.Format的形式在十万次循环里会制造十万个中间字符串这就是 Gen0 压力来源。6.2 从“减少分配”到“减少 GC 压力”换成数组租用后分配量会立刻下来char[] buffer ArrayPoolchar.Shared.Rent(256); try { int len FormatId(42, buffer); string id new string(buffer, 0, len); // 只在最后产生一个字符串 } finally { ArrayPoolchar.Shared.Return(buffer); } static int FormatId(int id, char[] dst) { dst[0] I; dst[1] D; dst[2] -; dst[3] (char)(0 (id % 10)); dst[4] (char)(0 (id / 10 % 10)); dst[5] (char)(0 (id / 100 % 10)); return 6; }Rent从共享池取缓冲Return归还池内部复用避免每次循环都向堆申请新数组。改动看起来小热路径上省掉的却是大量 Gen0 分配和后续回收入口。从那以后我每次写批量处理代码都强制先跑一遍分配基线用数据说话再谈优化。多花十分钟能省掉线上加内存的尴尬。希望帮到你。本文还有配套的精品资源点击获取