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：别靠猜
最直接方式是用 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。这种必须从数据结构设计层切。
