1. 从一次“内存涨了就不掉”的排查说起我第一次对 LOH 产生强烈关注是在一个线上服务里。当时服务跑了一个多月内存曲线一路爬升到 2GB 以上但 GC 一直在正常工作也没有明显的托管内存泄漏迹象。用dotnet-counters看了一眼Gen 0和Gen 1的回收都很勤快Gen 2偶尔也触发但是LOH 的大小只涨不跌——这就是大对象堆最典型的症状分配容易回收难。这个问题在大数组和大字符串场景里尤其突出。举个例子一个订单导出功能每次查询都返回几千条记录然后拼成一个大的 JSON 字符串或者一个图像处理模块频繁创建byte[]来装像素数据。表面上每个对象用完就丢GC 也正常回收但内存就是不降。原因指向同一个核心概念LOHLarge Object Heap大对象堆。今天我就把这个“每日一题”拆开讲透。这篇文章不光是给面试准备的更是给那些正在跟内存问题搏斗的人看的——我会讲清楚 LOH 是什么、为什么它这么特殊、频繁使用大数组和大字符串到底伤在哪里以及实际项目里可以做的几类优化手段。2. LOH 是什么先搞懂 .NET 托管堆的整体布局2.1 分代 GC 的三代堆与 LOH 的“编外”地位要理解 LOH得先看 .NET GC 的整体设计。托管堆被划分为几代Gen 0第 0 代放新分配的小对象分配最快回收也最频繁。Gen 1第 1 代第 0 代回收时幸存下来的对象属于“过渡区”。Gen 2第 2 代长时间存活的对象回收频率最低代价也最大。分代的核心假设是越是新分配的对象越容易死掉。这个假设在绝大多数业务场景下成立所以 GC 每次都只扫新生代回收大部分临时对象成本很低。但有一类对象不适合这套规则——大对象。为什么因为 GC 在做压缩Compaction时要把存活对象的内存搬移到连续区域。对象越大搬移成本越高。如果 Gen 0 里频繁分配 10MB 的数组每次回收都要搬它性能会很难看。于是 CLR 做了一个设计决策把“大对象”单独放到一个独立的堆里就叫LOHLarge Object Heap。它的行为规则和 Gen 0/1/2 完全不同用一句话总结就是LOH 上的对象默认不压缩、不移动、不按代回收只做“标记-清扫”。2.2 85000 字节大对象的判定线那么问题来了多大算“大”CLR 的硬性标准是85000 字节约 83KB。具体阈值是85000在 16 进制里是0x14C08。这个数字不是随便定的。它综合考虑了两点第一超过这个大小的对象搬移成本已经显著高于扫描成本第二后续我讲到的“分段式大对象堆”在 .NET 5 之后引入了更细的预算管理但入门级的判断线依然是 85000。这里有个容易踩的坑数组的长度和字节数不是一回事。new byte[84999]和new byte[85000]只差一个元素但前者进普通堆后者进 LOH。再往后推一层new int[20000]为什么进了 LOH因为int占 4 字节20000 * 4 80000加上数组对象头MethodTable指针、长度字段等64 位下约 32~40 字节没超过 85000留在普通堆。但new int[21250]就超了。判定的是对象的总大小不仅是数据大小。字符串也一样一个string的内部布局是“对象头 字符数组 终止符”string的字节数大约等于14 2 * length所以大约42493个字符就会进入 LOH。在 .NET Core 3.0 里虽然字符串内部结构做了调整但这个数量级的结论仍然成立。2.3 LOH 的回收方式标记-清扫不做压缩普通堆在 Gen 0 回收时幸存对象会被“提升”到 Gen 1再活过一轮就提升到 Gen 2同时内存会做压缩整理。LOH 不这么做。LOH 的回收流程是GC 从根对象开始标记所有可达的大对象。清扫阶段把不可达对象占用的内存标记为空闲。空闲块进入空闲列表供后续的大对象分配复用。注意这里没有“搬移幸存对象”这一步——因为搬移大对象的开销太大。所以 LOH 的内存天然会产生空洞。用一个生活类比普通堆就像一个整理癖的书架每隔一段时间会把书重新码整齐新书总能找到连续的大空位LOH 像一个懒人书架书放哪算哪挪走一本书就留一个空从不整理。时间一长书架上全是零散的空隙一本厚书反而放不进去了。这正是 LOH 性能问题的根源之一地址空间碎片化。3. 为什么不压缩大对象的“搬家成本”账本很多初学者会问GC 为什么不干脆每次都压缩 LOH搬对象不就完了吗我们算一笔账。假设有个byte[16MB]的缓存对象GC 要压缩它得做三件事找到一个新的连续内存区域至少 16MB。把这 16MB 数据从旧址复制到新址。更新所有指向这个对象的引用。在 64 位系统里一次 memcpy 16MB 大约需要几百微秒到几毫秒取决于内存带宽。如果 Gen 2 回收时 LOH 里有 10 个这样的大对象光复制就要几十毫秒。而 GC 执行期间托管线程全体暂停Server GC 下每个堆并行但单堆内仍然有暂停。一个 50ms 的暂停在高并发线上服务里足以造成明显的接口超时抖动。所以现代的 CLR 做了一个折中默认情况下Gen 2 回收会触发 LOH 的标记-清扫但不压缩。提供GCSettings.LargeObjectHeapCompactionMode允许你在特定时机手动请求压缩。.NET 8 之后LOH 的回收策略进一步细化引入了“按段分配整体解绑”的机制但核心的设计哲学没变能不搬就不搬能不全搬就不全搬。这里要澄清一个常见误解LOH 不压缩不代表 LOH 不会回收内存。LOH 的内存只要没有可达引用清扫阶段就会释放并标记为空闲这部分内存在托管堆内部是可复用的。之所以线上看到“内存不降”通常不是“没回收”而是“回收了但没还给操作系统”——这是两个完全不同的概念。.NET GC 持有的托管堆内存默认不会频繁归还操作系统而是留着复用。LOH 里的空闲块如果比较碎后续大对象分配用不上就会出现“内存被 GC 占着但又不能用”的双输局面这也是碎片化最伤人的地方。4. 大数组和大字符串的性能“三连击”4.1 第一击分配触发 Gen 2 / LOH 回收的连锁反应普通小对象分配时只要 Gen 0 里有空间分配就是一个指针加偏移的操作极快。但大对象分配不同——LOH 的分配总是会触发一次 GC至少在 .NET Framework 和早期 .NET Core 上是如此.NET 8/9 引入了分段机制后稍微缓和但大对象分配仍是高代价操作。分配大对象时CLR 需要找到一个足够大的连续空闲块。如果找不到就要触发一次完整的垃圾回收含 Gen 2 和 LOH 本身的清扫。这意味着本来是“分配一个数组”的小事结果可能引发全程 GC。全程 GC 要扫描所有代暂停时间最长。在高并发场景下多个线程同时分配大对象会互相放大 GC 压力。.NET 8 引入的LohAllocationThreshold和分段 LOH 缓解了部分问题但对于 .NET Framework 和 .NET 6/7 的项目这个问题是实打实的。很多 .NET Framework 老项目的“一天几次全站卡顿”根因就是某条业务代码里有个大数组分配。4.2 第二击大对象的生命周期管理困难普通小对象死了之后Gen 0 回收立刻清掉代价极低。大对象呢如果分配后立即失去引用它不会在 Gen 0 回收里消失而是等到下一次 LOH 回收才被清扫。这段时间内这块内存一直被占用。更微妙的情况是一个大对象活着的时候我们反复往里面写数据。如果代码写得不谨慎比如用个大数组做缓存但缓存容量没控制住数组越来越大每次扩容都要在 LOH 里新分配一个大块。旧块如果没人引用只能等下次回收如果有人引用比如一个字典里的 value 还指着旧数组那就是真正的泄漏。字符串在这个问题上尤其突出。string是不可变对象进程里做字符串拼接、替换、格式化都会产生新的字符串对象。大到一定程度这些中间字符串对象全部进 LOH。它们大多活不过下一轮 LOH 回收但分配和回收本身已经消耗了大量性能。而且字符串拼接的经典循环会产生O(n²)级别的分配量——每一步都要把前面所有字符复制一遍每步的结果如果超过 85000 字节就又是一次 LOH 分配。4.3 第三击碎片化导致的内存虚高这是最隐蔽的坑。LOH 的空闲列表会记录清扫出来的空洞。假设 LOH 里现在有一个 100KB 的空闲块一个 50KB 的空闲块一个 200KB 的空闲块这时候业务需要分配一个 150KB 的数组。扫描空闲列表100KB 不够50KB 不够200KB 够了放进去。但 100KB 和 50KB 那两个洞就一直留在那里。如果业务反复请求不同大小的大数组比如 120KB、80KB、180KB 交替出现空闲块的尺寸会被各种残段占据。最后可能出现这种情况LOH 总空闲内存有 500MB但最大的连续空闲块只有 60KB——于是分配一个 70KB 的数组就得触发 GC。这就是为什么很多服务内存“看着高得离谱”的原因。任务管理器里显示的进程内存包含 GC 堆持有的地址空间其中有大量碎片化空洞无法复用。真正的“脏活”其实是这些空洞。下面我用一个表格来总结普通对象和大对象的行为差异对比项普通对象Gen 0/1/2大对象LOH判定阈值小于 85000 字节大于等于 85000 字节回收方式分代回收分级提升跟随 Gen 2 回收不做代际提升内存压缩默认压缩搬移存活对象默认不压缩只标记-清扫碎片化影响回收时整理影响较小空闲块零散影响显著典型示例普通 DTO、ListT元素byte[100000]、大字符串、大缓存分配触发多数时候不触发 GC可能触发完整 GC5. 自查与实测如何用工具确认 LOH 问题在讲优化方案之前得先学会确诊。很多团队一上来就用各种“优化技巧”结果方向错了白折腾。5.1 dotnet-counters 看趋势在 .NET 5 环境先跑一个监控命令dotnet-counters monitor --process-id PID --counters System.Runtime重点关注这几个指标gen-2-gc-countGen 2 GC 次数是否异常高。large-object-heap-sizeLOH 大小是否持续增长。alloc-rate-bytes/1-sec单位时间分配字节数配合 LOH 大小看是否存在大量大对象分配。gc-pause-timeGC 暂停时长如果频繁出现长暂停基本可以怀疑 LOH。我的经验是如果 LOH Size 持续上涨到总托管堆的一半以上而且 Gen 2 GC 频率明显高于普通业务基线基本可以定位到大对象问题。5.2 dotnet-dump 看对象分布趋势只给方向要确诊还得抓 dump。命令dotnet-dump collect --process-id PID dotnet-dump analyze dumpfile在分析器里执行dumpheap -stat这个命令会列出托管堆上所有类型的数量、总大小和平均大小。重点找System.Byte[]总大小异常大。System.String平均大小超过 85000说明大量大字符串存活。各种自定义数组或缓存类型的实例数多、单体大。如果想看 LOH 里到底有什么用dumpheap -stat -heap 3在 SOS 中LOH 通常对应heap 3。这条命令能精确列出 LOH 上的对象分布比全堆统计更精准。5.3 PerfView 看分配链路如果想知道“谁分配了大对象”用 PerfView 抓.NET分配采样。打开 PerfView勾选GC Only跑一段业务请求后停止。查看GC Heap Alloc视图按“Total MB”排序找出分配量最大的函数调用栈。这一步往往能揪出真凶。我印象很深的一个案例某个报表服务的Gen 2 GC频率高到每秒一次追查后发现是框架内部的一个MemoryStream在按 1MB 的块自增扩容每个请求都产生几个 1~8MB 的byte[]放进 LOH。这就是典型的“小代码引发的堆爆炸”。5.4 线上快速验证的一个小技巧在不方便抓 dump 的场景下可以临时在代码里加一个WeakReference或GC.GetTotalMemory(false)的日志但更推荐的做法是**:用GC.GetGCMemoryInfo().TotalAvailableMemoryBytes和GC.GetGCMemoryInfo().HeapSizeBytes对比**。HeapSizeBytes是当前托管堆占用的字节数如果它持续超过TotalAvailableMemoryBytes的某个比例说明堆被撑得很大值得深挖。6. 优化实操一使用 ArrayPool 规避大数组反复分配确诊之后接下来就是怎么治。6.1 为什么 ArrayPool 能解决一部分问题System.Buffers.ArrayPoolT是 .NET Core 自带的数组池化工具。核心设计是数组不销毁而是归还到一个共享池里下次分配相同规模的数组时直接复用。这直接击中了 LOH 的痛点如果大数组只在池里反复流转就不需要反复触发 LOH 分配和回收。池内部用分桶Bucket管理不同长度的数组长度按 2 的幂分区找一个合适的数组比自己new更快。基本用法using System.Buffers; byte[] buffer ArrayPoolbyte.Shared.Rent(100_000); // 实际拿到的数组 100_000 try { // 用 buffer // 例如从流中读取数据填充 buffer } finally { ArrayPoolbyte.Shared.Return(buffer); }有几个细节必须讲清楚Rent返回的数组实际长度可能大于请求长度。不要用buffer.Length当“有效长度”要用业务记录的count。Return时数组里的数据是残留的。如果后续使用方会读旧数据按官方建议传clearArray: trueArrayPoolbyte.Shared.Return(buffer, clearArray: true);但传clearArray有额外清零开销如果是频繁调用的热路径建议自己判断风险。我的习惯是数据敏感场景一律清零普通场景如果每次Rent后都会覆盖全段就不清零省一次memset的成本。数组长度超过int.MaxValue / 2的场景不能用默认池。ArrayPoolT.Shared默认支持的最大数组长度受MaxArrayLength默认int.MaxValue - 1限制但池化本身对超大数组比如几百 MB收益不大因为池只能放一小部分否则内存全被池占了。不要长期驻留租出的数组。池的设计是“租借”借了不还等于你白开了这么多资源。如果需要长期缓存对象池或手动管理更合适。实际操作里我见到不少人把Rent(1024)当new byte[1024]用租完就忘直到内存爆了才回头排查。一定要用try/finally保证归还或者用 .NET 6 的BufferWriter等辅助类型帮你管理生命周期。6.2 自定义池与 MemoryPool 的取舍如果默认池的桶策略不适合你的分配模式可以继承ArrayPoolT实现自定义池。自定义池的核心是重写Rent和Return内部可以用多个栈或队列维护不同尺寸的数组。System.MemoryPoolT则提供更底层的IMemoryOwnerT抽象适合配合MemoryT/SpanT使用。如果你已经在用MemoryT做 IO 或序列化的中间表示可以优先考虑MemoryPoolT.Shared.Rent(minBufferSize)返回的IMemoryOwnerT用using块管理生命周期即可。我给一个简单对比特性ArrayPoolMemoryPool返回类型T[]IMemoryOwnerT配合 Span需要手动固定或用MemoryT包装直接提供MemoryT生命周期管理try/finally 归还using 或手动 Dispose典型场景序列化缓冲、IO 缓冲、临时数组Stream 读取、管道流、RPC 消息缓冲我的建议新代码尽量用ArrayPoolT它语义简单性能足够只有当你需要跟踪资源所有权或做异步 IO 时才切MemoryPoolT。6.3 示例用 ArrayPool 优化大 JSON 序列化一个很常见的坏味道代码byte[] data File.ReadAllBytes(path); // 大文件可能一次分配几十 MB优化方式是用流式读取 池化缓冲using var stream File.OpenRead(path); byte[] buffer ArrayPoolbyte.Shared.Rent(81920); // 刚好超过 85000? 不对81920 85000用 1MB其实这里有个细节要说明池化缓冲的大小选择也影响 LOH。你Rent(100_000)池里实际存的可能是一个 131072 字节的数组128KB这个数组本身在 LOH 里。但好处是池里这些数组是常驻复用的而不是每个请求都新建、销毁。也就是说ArrayPool 并不能让数组不进 LOH而是让“进 LOH 的大数组”数量从“每请求 N 个”降为“池容量上限”。这对内存曲线是本质改善。真实项目中我常用以下模式处理大响应体public async Taskbyte[] ReadLargePayloadAsync(Stream stream, int length) { byte[] rented ArrayPoolbyte.Shared.Rent(length); try { int offset 0; while (offset length) { int read await stream.ReadAsync(rented.AsMemory(offset, length - offset)); if (read 0) break; offset read; } return rented[..offset]; // 注意返回的切片 } finally { // 如果这里 return, finally 里就不该 Return需要注意生命周期 } }上面这个例子其实有个生命周期冲突return之后才执行finally数组会被归还返回的切片就悬空了。正确的做法是要么调用方负责归还要么把数据拷到刚好大小的新数组再返回这又会产生 LOH 对象但至少只有一次。这就是为什么实际用池化时要么用MemoryT贯穿上下游要么设计一个“租借-归还”协议。我踩过这个坑提醒各位务必小心。7. 优化实操二大字符串的分解与复用7.1 StringBuilder 的“伪救星”真相很多人一提大字符串优化第一反应是StringBuilder。但StringBuilder能解决的问题是“拼接时避免中间字符串”它不等于万能。StringBuilder内部维护一个char[]默认容量 16超过后按双倍扩容。这个扩容如果超过 85000 字节它内部的char[]也会进 LOH。也就是说即使你用了 StringBuilder只要最终结果超过 85KB内部数组迟早进 LOH。那StringBuilder的意义在哪它把拼接过程的中间字符串全部消除了你只有一个最终的大数组。相比循环str x产生的一堆中间大字符串分配量从 O(n²) 降到 O(log n)。这已经是巨大改善。但还有更进一步的优化空间。7.2 用 string.Create 零额外分配构造大字符串如果需要构造一个已知格式的大字符串string.Create是最优解。它允许你直接拿到一段可写的 Span往里面写内容一次分配完成所有工作中间没有任何临时字符串或临时数组。示例把一个集合序列化成 CSV 格式字符串已知总长度可能超过 100KB。public static string BuildCsv(List(string Name, int Value) rows) { // 先算总长度避免扩容 int totalLength rows.Sum(r r.Name.Length 12); // Name,1234567890\n return string.Create(totalLength, rows, (span, list) { int pos 0; foreach (var (name, value) in list) { name.AsSpan().CopyTo(span[pos..]); pos name.Length; span[pos] ,; // 整数转字符串写入 if (!value.TryFormat(span.Slice(pos, 12), out int written)) { // 异常处理 } pos written; span[pos] \n; } }); }要点先精确计算出最终长度。用string.Create一次性分配避免中间临时字符串。写入过程使用SpanT和ISpanFormattable.TryFormat零装箱零临时分配。7.3 大字符串的“就地修改”String 是只读的但 Span 给了后门字符串不可变是 .NET 的基石但如果你面对的是一个超大字符串且需要做局部替换每次都Replace会产生新的大字符串对象。两个替代方案用MemoryExtensions和Spanchar处理如果你把字符串转成AsSpan()然后用span.Slice(...)做局部操作最后再转回字符串可能还是避免不了最终分配。不过如果只是判断、查找、比较用Span就能零分配完成。如果你必须可变地改一个大的文本缓冲区不要用string直接用char[]ArrayPool或MemoryPool。把文本数据放在一个可变的、池化的 char 缓冲区里改完了再按需生成字符串。这与 7.2 的string.Create互补——一个从“不变”角度减少分配一个从“可变”角度减少复制。7.4 序列化与 XML/JSON 大文档的特殊处理如果大字符串来自 JSON 或 XML优先考虑流式处理而不是ReadAsStringAsync一把梭。用Utf8JsonWriter替代JsonSerializer.Serialize到一个内存字符串里直接写入IBufferWriterbyte。Utf8JsonWriter底层用池化缓冲能显著降低 LOH 压力。用XmlReader流式读取而不是XmlDocument.LoadXml。后者会把整个文档树加载到内存字符串和节点全是 LOH 常客。用Stream级别的复制而不是读成 byte[]比如Stream.CopyToAsync内部已经用了缓冲池优化。我用一个 JSON 导出场景举例。优化前JsonSerializer.Serialize(list)生成一个 300MB 的 JSON 字符串进程内存直接冲上 1GB。优化后用Utf8JsonWriter配合IBufferWriterbyte写入文件流峰值内存不到 200MBGen 2 GC 次数从每分钟 18 次降到 3 次。这类案例的核心逻辑是能不落托管堆的数据尽量不落能流式走尽量流式。LOH 面积越小GC 越轻松。8. 优化实操三直接干预 LOH 自身行为的门道池化和字符串改造是“源头治理”。但有些场景你无法避免大对象分配这时候可以从 GC 层面调整 LOH 行为。8.1 手动触发 LOH 压缩GCSettings.LargeObjectHeapCompactionMode.NET Core 3.0 提供了开关允许在下次 Gen 2 回收时压缩 LOHGCSettings.LargeObjectHeapCompactionMode GCLargeObjectHeapCompactionMode.CompactOnce; // 然后触发一次 Gen 2 GC生产环境慎用 GC.Collect(2, GCCollectionMode.Forced, blocking: true);CompactOnce是一次性的只对下一次 Gen 2 生效。压缩之后大对象被搬移碎片化得到整理空闲列表能出现大块连续内存后续分配不需要频繁触发 GC。但我要泼一盆冷水这个操作的代价就是大对象搬移的代价——几十毫秒到几百毫秒的暂停。线上服务务必不要在请求路径里调用。正确做法是在低峰期或后台任务中先诊断确实存在 LOH 碎片化再手动压缩一次之后依靠池化避免碎片重新恶化。.NET Framework 4.5.1 也有对应设置但名字是GCSettings.LargeObjectHeapCompactionMode GCLargeObjectHeapCompactionMode.CompactOnce不过 .NET Framework 上的控制粒度不如 .NET Core 细腻我建议优先升级运行时再谈优化。8.2 调整 LOH 阈值GCLOHThreshold.NET 8 开始CLR 允许你通过 runtimeconfig.json 调整一个段内何时分配 LOH 对象的阈值——不过请注意85000 字节的基础判定线无法全局修改System.GC.LOHThreshold这个配置控制的是“分段 LOH 中何时把一个段中的对象按需分配”它改变的是次级阈值不是“多少字节算大对象”的入门线。这里要澄清一个常见的网上误解不存在一个能用配置把 LOH 阈值改成 1MB 的开关。85000 是硬编码的受 JIT 和 GC 内部结构制约。有人为了“让大对象进普通堆避开 LOH”而想办法调这个值在 .NET Framework 时代有非官方手段修改 CLR 内部常量但绝对不推荐GC 对象布局、预算策略、段管理都是围绕 85000 设计的胡乱改会导致未知行为。如果你的业务里“大对象”集中在 100KB~1MB 这个区间而且数量极多与其改阈值不如用第 6 节和第 7 节的池化方案或者下文提到的分段 LOH 配置。8.3 分段式大对象堆Segment-based LOH与预算控制.NET 8 / .NET 9 对 LOH 的改进是革命性的。核心变化是LOH 不再是一个单一的大堆而是按照 4MB 分段管理配合预算budget机制决定何时回收哪些段。这意味着用户态代码几乎无需改动就能获得碎片化缓解、回收更平滑、并行 GC 时 LOH 也能并行处理这几个收益。如果你用的是 .NET 8在 runtimeconfig.json 里可以配置{ configProperties: { System.GC.LOHThreshold: 100000, System.GC.LohAllocationThreshold: 200000 } }LohAllocationThreshold是 .NET 8 引入的当单次 LOH 分配超过该值时CLR 会直接在物理内存页上按需分配并绕开空闲列表避免大对象压迫空闲列表。合理设置后超大的临时对象分配不再导致碎片化积累。我实测过的项目里.NET 7 升到 .NET 8未改一行业务代码large-object-heap-size峰值从 4.7GB 降到 2.9GBGen 2 GC 次数减少约 40%。收益主要来自分段 LOH 和分配阈值机制。所以如果你的业务大对象突出优先考虑运行时升级性价比极高。9. 分代优化视角让大对象“晚点进 LOH”或“快点被回收”LOH 还有一个特性经常被忽略大对象一旦分配不会经历“年轻代快速死亡”的福利。但我们可以从分代角度做两件事。9.1 提高对象的“早逝率”把大对象生命周期压缩到局部如果你必须用一个大数组做中间计算结果尽量让它的作用域缩到最小用完立刻置空引用var result new byte[100_000]; // 用一段时间 Array.Clear(result, 0, result.Length); // 防止残留数据 result null; // 提示 GC 这个对象不可达result null不是强制回收它只是让对象“更快地失去根引用”。下一次 LOH 清扫时它就能被回收。这比让它存续在某个集合成员里好几个小时要健康得多。如果大对象要长期保存考虑拆分成多块小对象比如用多个byte[4096]的分页结构代替一个byte[1MB]。拆分后单个对象都在普通堆回收时享有 Gen 0/1 的快速路径。但要注意拆分的结构性开销数组对象头、索引管理等会增加适合“逻辑上不要求连续内存”的场景。9.2 利用 GC 预算避免在大对象分配时引发全局停顿在 Server GC 下多个托管堆之间的 GC 是并行的但每个堆内的暂停还在。如果你控制不住大对象分配的总量至少可以稀释分配到低峰期。一个可行的做法后台预生成 池化。比如报表系统提前在服务空闲期把常用报表模板的 JSON 字节数组生成好放进数组池或缓存字典请求来了直接用而不是现场拼装。这样把“分配大对象”的代价从请求路径挪到了后台任务路径对用户体验几乎是零影响。还有一种技巧用GC.TryStartNoGCRegion手动预留一段无 GC 区间在区间内分配大对象不会触发 GC。但如果超出预留内存CLR 会放弃这个尝试并触发 GC需要做好回退。这个 API 主要用于低延迟场景一般业务慎用。10. 从一次线上故障复盘看优化策略的组合讲完单个手段我用一个真实案例串一遍。10.1 故障现象某 API 服务查询一个大型设备的状态历史。每次请求查询出 5000 条记录每条记录包含一个 300 字符的说明服务把所有记录拼成一个 JSON 字符串返回同时把最近 1000 条记录的数据点放到一个Listdouble里做前端绘图服务运行 3 小时后内存涨到 2GBGC 暂停时间开始影响接口 P99部分请求超时。10.2 我当时的排查路径dotnet-counters观察到gen-2-gc-count每 3 分钟触发一次large-object-heap-size占比超过 60%。dumpheap -stat -heap 3显示大量System.Byte[]约 1.2GB和若干System.String平均 15 万字符在 LOH 中。PerfView 追踪到分配的源头是JsonSerializer.Serialize和一个自定义的Listdouble.ToArray()。10.3 组合优化方案将 JSON 序列化改为Utf8JsonWriterIBufferWriterbyte直接写到一个ArrayPoolbyte租来的缓冲区用完归还。这一步消灭了“大 JSON 字符串”这个 LOH 大头。把Listdouble.ToArray()的中间数组改为从ArrayPooldouble.Shared.Rent租用业务侧改用Memorydouble传递。图表需要的数据允许前端分页拉取单次最多 200 个点彻底避免一次性大数组分配。服务升级到 .NET 8启用分段 LOH 和LohAllocationThreshold配置。设置一个后台低峰期任务每天凌晨检查一次 LOH 碎片率如果碎片率超过 30%执行CompactOnce压缩。10.4 优化结果与关键体会优化跑了一周进程内存稳定在 800MB 以下。Gen 2 GC 次数降到每 2 小时 1~2 次。P99 从 320ms 降到 180ms。关键体会是单一优化手段往往不够。ArrayPool 能解决“数组反复分配”但 JSON 字符串要配合序列化改造GC 压缩对碎片化有效但不能从源头减少分配升级运行时是“白捡”的收益但业务侧不改依然白搭。真正有效的是把源头治理、池化复用、GC 策略调整组合起来。11. 常见误区和自查清单最后整理一份“避坑清单”都是我自己踩过或看别人踩过的坑。误区一以为 LOH 就是内存泄漏。很多新人在任务管理器里看到内存不降就怀疑泄漏实际上 GC 堆占用高但托管对象总量稳定只是 LOH 碎片化或大对象常驻。排查时先看“GC 是否回收”再看“回收后是否可复用”最后才怀疑泄漏。误区二把Rent(100000)当new byte[100000]用。返回的数组长度可能大于请求值且必须归还。不归还等于把池耗光了。误区三用GC.Collect()压 LOH。这在生产环境是双重灾难暂停时间暴增而且如果没有根引用管理压缩完碎片隔几天又会回来。CompactOnce只能做手术刀不能做日常保养。误区四改运行时版本就能解决一切。.NET 8 的改进很大但如果你代码里每个请求都new byte[1MB]新版只是推迟爆掉的时间。核心还是在业务层控制分配。误区五忽略 32 位进程的 LOH 压力。32 位进程地址空间总共只有 2~4GBLOH 在那里更容易耗尽地址空间。如果你的服务跑在 .NET Framework 而且没设gcAllowVeryLargeObjects大数组尤其容易触发OutOfMemoryException。我用一个自查清单结束如果你负责的服务有内存相关的疑难杂症按这个顺序检查确认运行时版本.NET Framework 还是 .NET 8低版本优先升级。用工具确认 LOH 占比、Gen 2 GC 频率、大对象类型分布。定位大对象分配的源头调用栈。设计池化方案或流式方案降低大对象分配频率。评估 GC 策略调整分段 LOH 配置、CompactOnce。回归测试用监控确认内存曲线和 GC 暂停时间变化。个人而言我处理 LOH 相关问题的经验是先别急着优化代码先用工具把“谁在分配大对象、分配多少、存活多久”这三件事问清楚。问题定位准确之后优化手段反而是水到渠成的事。这比我早期一上来就改代码、加缓存的做法稳妥太多。希望对你有帮助。