先抛一个大家大概率遇到过的场景服务上线几天后内存悄悄涨到 3~4GBGC 高频运行接口偶尔卡顿到让人想砸键盘。你本能地以为是内存泄漏拿出工具一看托管堆里很多大对象其实早就变成垃圾了可堆上总有一些“大坑”新对象死活填不进去。这时候只看 Gen0/Gen1 和小对象堆基本查不出原因真正要关注的是那个经常被忽略的 LOHLarge Object Heap大对象堆。这篇文章就围绕“什么是 LOH、为什么大数组和大字符串会拖垮进程、怎么系统性优化”展开。想应付 .NET 面试的人可以当复习题正在追线上卡顿但无从下手的人可以直接把后面的方案抄走。内容会比较偏实操我也会把一些平时文档里不会写的细节和踩坑记录放进来。1. LOH 到底是什么先理解 .NET 的堆分区1.1 SOH 和 LOH 是怎么划分的.NET 托管堆在逻辑上分成两大区域SOHSmall Object Heap小对象堆和 LOHLarge Object Heap大对象堆。SOH 又按对象年龄拆成 Gen0、Gen1、Gen2 三代新分配的小对象先进 Gen0经过回收存活后逐步提升到 Gen1、Gen2。LOH 的处理方式完全不同。对象的对象头、字段、数组元素等信息加在一起总大小达到或超过 85,000 字节时对象不会进入 Gen0而是直接分配到 LOH。注意这个 85,000 的单位是字节不是“85KB 87,040 字节”。很多人在面试的时候脱口而出“超过 85KB 就进 LOH”严格说是不够准确的。比如一个byte[]你new byte[82_000]看起来只有 80KB 左右但加上数组对象头和同步块索引实际对象大小可能就逼近阈值了。所以不要用“数组长度小于 85,000 就绝对安全”这种直觉去写代码。从行为上看LOH 里的对象在回收时被当作类似 Gen2 的对象处理只有发生完整 GCFull GC/阻塞式 Gen2 GC时才可能被回收。它不像 SOH 一样有代际逐渐提升的过程也没有压缩整理阶段。你可以把 LOH 理解成一个“独立于分代模型之外的盲盒区域”。1.2 SOH 和 LOH 的本质差异维度SOH小对象堆LOH大对象堆对象大小小于 85,000 字节达到或超过 85,000 字节物理区域Gen0、Gen1、Gen2 轮转独立大对象区回收后处理通常会压缩和移动存活对象不压缩、不移动地址不变GC 触发时机Gen0/Gen1/Gen2 分批或全量参与 Full GC回收门槛高典型问题碎片少但要关注提升容易碎片化、内存虚高、OOM这个差异直接决定了后续的优化方向在 SOH 中GC 可以“腾挪”空间把存活对象往一端搬把碎片合并成大的可用块在 LOH 中GC 不会移动对象所以空间碎片只能靠对象自身生命周期的一致性来规避。1.3 为什么单独设计一个“不做压缩”的堆你可能会问既然不压缩会导致碎片为什么还要这么设计原因很朴素移动大对象的成本太高。SOH 里压缩时只需要 memcopy 小对象几千几万个对象搬一遍都很快但如果 LOH 里躺着几百 MB 的大数组每次回收都把它们搬来搬去GC 暂停时间会直接暴涨代价远大于碎片的损失。所以 .NET 设计者选择了一个折中大对象单独放回收时把死亡对象清掉但存活大对象不搬。这样大部分情况下能正常工作但也把“碎片化”这个雷留给了开发者。2. 大数组和大字符串为什么会拖垮性能2.1 分配阶段大对象比你想的更“重”很多开发者以为分配一个 1MB 数组和分配一个 1KB 数组只是“内存量不同”其他都一样。实际上大对象分配有几个隐藏成本清零成本高 .NET 为了保证托管内存初始化为零值新分配的内存都要清零。大数组越大需要清写的内存页越多这一下就可能吃掉不少 CPU 和内存带宽。大块连续内存更难找LOH 需要从堆段里找到足够大的连续空间。如果碎片多分配器可能在第一次尝试失败后又触发 GC造成不必要的停顿。容易被“观察”到凡是大对象一旦分配就进入 LOH 并被当作 Gen2 对象看待。即使它只活了 1 毫秒也得等一次完整 GC 才能被回收。在频繁分配大数组的业务里出现“分配 1MB、使用 1 微秒、丢掉、等 GC”这种模式基本就是慢性自杀。比如一个接口循环处理文件每次都File.ReadAllBytes压测一上去GC 曲线直接起飞。2.2 回收阶段不压缩碎片就来了LOH 垃圾回收后不会把存活对象往一端挪只是把相邻的死亡对象合并成 free object放进空闲块链表。这意味着几个问题如果大对象分配得七零八落中间腾出来的空闲块大小不一。后续分配一个大对象时GC 需要找到一个足够大的连续空闲块。如果空闲块都被切碎哪怕堆上剩余内存总量很大新对象也放不下。我经常打一个停车场类比小车小对象找个小缝隙就能停大车大对象必须找一段连续够长的空位。停车场里看着还有很多空位其实都是小车位大车一进来就停不进去。LOH 碎片化就是这种状态。到了这个阶段服务经常表现为可用内存还有几百 MB但new byte[10MB]直接报OutOfMemoryException。这是最典型的 LOH 碎片问题。2.3 回收时机每次清 LOH 都是一次“全局行动”LOH 对象不会在 Gen0/Gen1 GC 时被回收。它要等完整 GC也就是会扫整个托管堆的那次。这意味着对象明明可以速死但被延后到“全局大扫除”才清理。完整 GC 的暂停时间明显长于局部 GC因为它要 mark 所有可达对象再 sweep 所有堆段。高频分配临时大对象会导致完整 GC 频率暴涨线程暂停次数增加延迟和吞吐一起恶化。更麻烦的是服务器 GCServer GC下多线程回收可以并行处理小对象堆但 LOH 相关操作同样需要协调。后台标记background GC能在一定程度上降低停顿但只要涉及大对象清理总会有阻塞式的操作点。所以结论很清楚大对象临时化是 LOH 性能问题的原罪。只要让大对象频繁“出生即死亡”不管你怎么调 GC 参数效果都有限。3. 优化让 LOH 从“事故现场”变成“稳定后方”3.1 池化是默认的解法ArrayPool 和 MemoryPool面对频繁分配大数组的问题最简单有效的方法是复用而不是回收后再重新分配。ArrayPoolT是 .NET 内置的数组池。它内部会维护一组数组你Rent的时候从池中拿一块用完后Return回去避免每次 new 一个大数组再等着 GC 回收。int exactSize 1_000_000; // 需要 1MB byte[] buffer ArrayPoolbyte.Shared.Rent(exactSize); try { // 注意Rent 返回的数组实际长度可能大于 exactSize // 不要用 buffer.Length 作为可写上限只使用前 exactSize 个元素 Spanbyte usable buffer.AsSpan(0, exactSize); // 用 usable 做各种操作 } finally { // 清空数据可避免池内残留敏感信息如果只是普通缓存clearArray 传 false 能省掉一次清零操作 ArrayPoolbyte.Shared.Return(buffer, clearArray: false); }类似的还有MemoryPoolT它更适合异步场景返回的是IMemoryOwnerT可以配合ReadOnlyMemoryT在管道里传递using IMemoryOwnerbyte owner MemoryPoolbyte.Shared.Rent(1_000_000); Memorybyte memory owner.Memory; // 把 memory 当作缓冲区使用池化思路的本质是让大数组的生命周期变长而不是每个请求都重新分配。池内数组反复使用垃圾堆里就不会堆积“用完即弃”的大对象。不过要提醒一句Rent返回的数组不一定刚好是你要的尺寸。如果你对长度有严格约束一定要用buffer.AsMemory(0, exactSize)或者AsSpan(0, exactSize)来切出有效范围。我曾经见过有人直接拿buffer.Length去传参结果把池里附带的多余空间也写上去了最后数据包多出一截。3.2 字符串别让大字符串频繁诞生大字符串本质上就是一个大char[]每个字符在 .NET 中占 2 字节。一个 10 万字符的字符串光char[]就有 200KB妥妥进 LOH。更麻烦的是字符串操作经常产生临时副本。常见的改善点字符串拼接避免用string string在循环里反复拼接。StringBuilder可以显著减少临时字符串的产生。如果最终结果超过 85KBStringBuilder内部的大char[]依然会进 LOH但至少不会每次都产生一个新的临时大对象。读文件避免直接File.ReadAllText把一个超大文本一次性读进来。用StreamReader.ReadLine逐行处理可以保证每一行通常还在 SOH 范围。using var reader new StreamReader(path, Encoding.UTF8, bufferSize: 4096); string line; while ((line reader.ReadLine()) ! null) { // 一行一行处理不会构造出包含整个文件的大字符串 ProcessLine(line); }Base64/编码Convert.ToBase64String会把整个字节数组一次性转成一个超长 string这又是一个 LOH 对象。如果目标是网络传输或写文件可以考虑分块编码或者使用System.Buffers.Text.Base64这类面向Spanbyte的 API直接把编码结果写进缓冲区避免生成大字符串。JSON 解析超大 JSON 尽量别一次性ReadToEnd再JsonDocument.Parse。用JsonSerializer.DeserializeAsync或者用Utf8JsonReader在ReadOnlySpanbyte上流式读取能避开大字符串和大数组的双重打击。3.3 该复用就复用该常驻就常驻有些大对象确实业务上无法避免比如一个 200MB 的模型数据、一个几十 MB 的配置文件。这时候我的建议是让它常驻进程而不是频繁重建。常驻对象没有“死亡再回收”的过程不会在 LOH 里留下碎片。你只需要注意控制生命周期和内存总量比如用ConcurrentDictionary做缓存并设置过期策略或者在启动时加载一次之后长时间引用。最怕的是“每次请求都创建一份大对象用完后引用归零”。哪怕每次都能被 GC 发现频繁的 Full GC 和碎片积累也会让服务变得很脆弱。3.4 真遇到碎片LoH 压缩配置在某些场景下大对象的创建确实无法完全避免而且碎片已经严重到影响新对象分配。此时可以考虑 LOH 压缩。GCSettings.LargeObjectHeapCompactionMode GCLargeObjectHeapCompactionMode.CompactOnce; GC.Collect(2, GCCollectionMode.Forced, blocking: true, compacting: true);CompactOnce表示在下一次阻塞式完整 GC 中对 LOH 做一次压缩整理。压缩会把存活的大对象搬到连续的内存区域把空闲块合并成大块短期内能缓解碎片问题。但压缩不是银弹压缩本身要复制大对象代价非常高暂停时间可能比普通 Full GC 还长。它只解决“已经碎片化”的问题不解决“继续频繁创建大对象”的根因。在业务请求热路径上调用GC.Collect是绝对的反模式哪怕加上了CompactOnce也一样。所以我的建议是在低峰期或后台任务里配合明确的业务窗口手动做一次压缩是可以接受的但不要试图通过定时压缩来掩盖代码层面的 LOH 分配问题。3.5 别让常用 API 在背后帮你分配大对象有些时候你的代码看起来只用了“普通功能”但底层 API 会悄悄分配大对象。比如ListT扩容时如果元素多到超过阈值内部T[]就是一个大数组再比如Array.Resize、MemoryStream内部的缓冲区扩容、Stream.ReadAllBytes、HttpClient.GetByteArrayAsync等等都可能产生大数组。你总觉得“我没 new 大数组啊”实际上框架层帮你在 LOH 上反复横跳。排查时可以带着这个意识凡是“把整份数据一次性放到内存”的 API都要怀疑它产生了 LOH 分配。能用流式处理的就用流式能指定初始容量的就指定初始容量能提前 75% 以上确定范围的就尽量别让容器多次扩容。4. 实战案例一次“卡顿到丝滑”的 LOH 排查与优化记录4.1 现象和初步判断我之前处理过一个服务接口逻辑很简单就是根据路径读取一个文件然后转成 Base64 返回。功能看起来人畜无害但压测 50 并发时CPU 占用高接口 P95 延迟超过 1 秒时不时抛 OOM。最开始大家怀疑内存泄漏但我让运维抓了几分钟dotnet-counters发现 Gen0/Gen1 GC 数量并不夸张真正异常的是 Gen2 GC 次数和 LOH Size 居高不下。这就已经把矛头指向 LOH 了。4.2 用 dotnet-counters 和 dump 定位先把进程的 GC 相关计数器打开dotnet-counters monitor -p 12345 System.Runtime在这个命令的输出里重点看这几个指标gen-2-gc-countGen2/Full GC 次数涨得快就说明有大对象在频繁分配。loh-sizeLOH 当前占用持续上涨说明大对象没被释放或碎片化严重。alloc-rate-bytes分配速率如果非常高说明存在大量临时对象。随后再用dotnet-dump做一次进程快照分析dotnet-dump collect -p 12345 -o server.dmp dotnet-dump analyze server.dmp在分析器里直接筛 85KB 以上的对象 dumpheap -stat -min 85000结果里数量最多的类型就是System.Byte[]和System.String对应代码里的File.ReadAllBytes和Convert.ToBase64String。到这里原因已经清楚了每请求都在 LOH 上创建文件大小的 byte[] 和 Base64 字符串而且用完即丢。4.3 优化后的代码形态根因清楚后方案不复杂不要一次性把整个文件读成 byte[]也不要生成完整 Base64 string改成分块读取、分块编码、直接写入响应流。using var input File.OpenRead(filePath); byte[] srcBuffer ArrayPoolbyte.Shared.Rent(1 * 1024 * 1024); byte[] dstBuffer ArrayPoolbyte.Shared.Rent(Base64.GetMaxEncodedToUtf8Length(srcBuffer.Length, 0)); try { using var output /* response stream */; while (true) { int read input.Read(srcBuffer, 0, srcBuffer.Length); if (read 0) break; // 注意分块 Base64 编码要考虑 3 字节对齐真实代码里建议按 3 的倍数块读取 // 最后一块统一处理 padding。这里只展示思路。 int consumed; int written; Base64.EncodeToUtf8(srcBuffer.AsSpan(0, read), dstBuffer, out consumed, out written); output.Write(dstBuffer, 0, written); } } finally { ArrayPoolbyte.Shared.Return(srcBuffer); ArrayPoolbyte.Shared.Return(dstBuffer); }改造后的核心变化请求处理过程中大 buffer 全部来自池用完归还输出结果直接写流不再创建大 string。整个请求生命周期内没有新的 LOH 对象产生。4.4 优化前后对比指标优化前优化后Gen2 GC 次数/min60~1000~1LOH 大小250MB还在涨16MB 左右P95 延迟1.2s80msOOM 出现频率压测几分钟必现压测一小时未出现这次优化最大的收获不是简单调了个参数而是抓到了“分配源头”。后来我在多个项目里反复验证LOH 相关问题先找大对象的创建点比先调 GC 配置有效得多。5. 常见问题与排查技巧速查下面这些问题是群里和面试里被问过很多次的我按“问题 - 原因 - 做法”整理成了一张速查表方便你直接对照。常见问题可能原因建议做法我数组长度控制在 80KB为什么 LOH 还是涨LOH 阈值是对象总大小不是数组可用长度另外其他 API 也可能分配大对象用dumpheap -stat -min 85000看看到底是哪种类型占 LOH设置了 CompactOnce 还是卡压缩只解决碎片不解决频繁分配大对象从分配源头下手池化或缓存大对象ArrayPool 里的数组不回收内存会一直涨吗池本身会持有一定量数组这是设计行为复用带来的收益远大于池内固定开销必要时可以限制池的持有量LOH 碎片怎么证明存在内存总量很大但分配大对象仍 OOM用dumpheap -stat -min和性能计数器的 loh-size 联合判断使用 Span 和 Memory 就能避免 LOH 吗Span/Memory 只是视图不分配对象底层 buffer 如果来自池才是真正受益使用ArrayPool/MemoryPool分配缓冲不要为视图额外分配大数组大数据集序列化后总是产生大对象序列化器往往默认建临时 buffer / string用流式序列化 API避免整个对象一次性落内存后台 GC 能完全解决 LOH 问题吗后台 GC 降低停顿但 LOH 清理仍伴随阻塞式操作后台 GC 是优化项不是逃避大对象管理的理由再补充一个排查技巧如果服务已经发布到生产不方便用dotnet-dump抓大文件可以在关键分配路径上临时加一个“分配即记录”的开关。比如自定义一个LargeBufferTracker把所有超过 85KB 的分配者和调用栈打出来压测一轮后直接看日志。这种方式比事后分析 dump 更快也能防止“知道是 LOH 问题但找不到在哪分配”的尴尬。还有一个行业内很少写进文档的点别把 LOH 优化放在性能优化的最后一步。很多项目到压测阶段才想起来查内存结果发现是早期 API 设计留下的“一次性大对象”坑这时候改动成本极高。在一开始设计接口时就定下“大块数据走流式、走池化”的规矩后面会省很多事。最后分享一个我个人的实际体会在做 .NET MAUI 或 WPF 这类客户端时LOH 问题更容易“一次彻底打崩”。移动端内存本来就紧如果从相册选一张几 MB 的图片再转成 byte[]再做 Base64 或缩略图每一步都可能制造一个 LOH 对象。像这种场景图片一定要走Stream不要轻易持有大 byte[] 副本遇到需要大缓冲的模块第一反应应该是ArrayPoolbyte.Shared而不是new byte[很大]。运气好能顶住运气不好就是上线一小时闪退。性能优化这件事防患于未然永远比事后修 Bug 划算。