LOH是.NET中分配≥85KB对象的独立堆区域，不压缩且仅在Full GC时回收，易导致碎片化；常见触发场景包括大数组、字符串拼接、MemoryStream.ToArray()等，应优先用ArrayPool、StringBuilder、Span等优化分配策略。
LOH 是什么：不是“大对象”，而是“大内存块”
C# 的大对象堆（Large Object Heap，LOH）是 .NET 运行时单独管理的一块托管堆区域，专门用于分配单个对象大小 ≥ 85,000 字节（85 KB） 的实例。注意：不是“大对象类型”，而是“单次分配的字节数”——比如一个 byte[] 长度为 85000，哪怕只是临时数组，也会进 LOH；而一个包含上百个字段的类实例，只要总大小不到 85 KB，仍走普通堆（Gen 0/1/2）。
LOH 的关键特性是：不随常规 GC 周期压缩（.NET Core 3.0+ 默认仍不压缩，除非显式开启），且只在 full GC（Gen 2）时回收。这意味着频繁分配/释放大数组或大字符串，容易造成 LOH 碎片化，进而触发更频繁的 full GC，拖慢整体性能。
哪些操作最容易误入 LOH
常见但容易被忽视的 LOH 入口点：
-
new byte[85000]、new char[42500]（char是 2 字节，42500 × 2 = 85000） -
string.Concat或string.Join拼接大量内容，结果字符串长度超阈值 -
MemoryStream.ToArray()返回的大字节数组 -
ArrayPool<t>.Shared.Rent(n)</t>中n >= 85000时，某些运行时版本会退化为直接 new（取决于池实现和 .NET 版本） - 序列化大型 DTO（如 JSON.NET 反序列化出的深层嵌套对象，其内部缓存可能触发大数组分配）
特别注意：List<t></t> 自动扩容时若新容量导致底层 T[] 大小 ≥ 85 KB，也会跳进 LOH——例如 List<byte></byte> Add 到约 85000 项后扩容，就危险了。
避免 LOH 的四条实操路径
- 用
ArrayPool<byte>.Shared.Rent()</byte> 替代 new byte[n]，尤其对临时缓冲区；记得 Return()，且确保租用大小合理（避开 85 KB 边界附近反复试探）
- 对字符串拼接，优先用
StringBuilder，并预先 Capacity 设定上限；避免 string + string 链式拼接生成中间大串
- 处理流式数据时，用
Span<byte></byte> / ReadOnlySpan<byte></byte> + stackalloc（小固定尺寸）、或分块读取（stream.Read(buffer, 0, 4096)），避免一次性 stream.ReadToEnd()
- 在 .NET 5+ 中可启用 LOH 压缩（需配置
DOTNET_gcServer=1 + DOTNET_gcConcurrent=1 并设置 System.Runtime.GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce），但这只是兜底手段，不能替代分配策略优化
检查是否真进了 LOH：别靠猜
ArrayPool<byte>.Shared.Rent()</byte> 替代 new byte[n]，尤其对临时缓冲区；记得 Return()，且确保租用大小合理（避开 85 KB 边界附近反复试探）StringBuilder，并预先 Capacity 设定上限；避免 string + string 链式拼接生成中间大串Span<byte></byte> / ReadOnlySpan<byte></byte> + stackalloc（小固定尺寸）、或分块读取（stream.Read(buffer, 0, 4096)），避免一次性 stream.ReadToEnd()
DOTNET_gcServer=1 + DOTNET_gcConcurrent=1 并设置 System.Runtime.GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce），但这只是兜底手段，不能替代分配策略优化最直接方式是用 dotnet-dump 或 Visual Studio 的内存快照（Debug → Windows → Show Diagnostic Tools → Memory Usage → Take Snapshot），筛选对象类型并看“Size”列；也可在代码中粗略估算：
var arr = new byte[85000]; Console.WriteLine(GC.GetGeneration(arr)); // 返回 2 表示大概率在 LOH（Gen 2 对象不一定都在 LOH，但 LOH 对象一定在 Gen 2）
更准的方法是用 dotnet-gcdump collect -p <pid></pid> 后分析，搜索 “LargeObject” 类型或查看“Heap Size by Generation”图表中 Gen 2 的占比突增点。
真正难处理的不是“怎么避开 85 KB”，而是那些隐式触发的场景——比如 ORM 加载 1000 条记录，每条含一个 100 KB 的 JSON 字段，集合本身没超，但每个字段都进了 LOH。这种必须从数据结构设计层切。
