.Net Core应用内存泄漏：Overhead|Unused内存占比过高如何解决？

Overhead|Unused分类的含义 #

Overhead|Unused是.NET内存分析工具中对GC已向操作系统申请、但未分配给任何存活托管对象的内存空间的归类。

这类内存本质是GC为了降低频繁向OS申请/释放内存的开销，预先保留的内存段里的空闲部分。如果内存出现严重碎片化，大量零散的空闲空间因为尺寸太小无法容纳新对象，就会导致这部分内存占比极高——操作系统看到进程占用了大量内存，但.NET实际使用的存活对象内存远小于这个数值，最终就会触发内存耗尽抛出OOM。

排查与解决方法 #

第一步：确认核心诱因 #

使用dotnet-dump工具分析导出的转储文件，执行如下命令：

dotnet-dump analyze <转储文件路径>
# 进入分析控制台后执行
dumpheap -type Free

统计输出的空闲块总大小：如果空闲块占总GC堆大小的30%以上，且平均空闲块大小远小于你业务中常用的对象尺寸，即可确认是GC堆碎片化导致的问题。

第二步：排查碎片化根因 #

常见触发该问题的原因有三类：

• 大对象堆（LOH）碎片化：.NET中尺寸大于85000字节的对象会被分配到LOH，默认场景下LOH不会被GC压缩。如果你的数据转换、批处理环节频繁生成大数组、大字符串等超过85KB的对象，销毁后就会留下大量无法被利用的零散空闲块。
• 固定对象占比过高：代码中使用fixed关键字、调用非托管接口、或者部分第三方IO库会固定内存块的地址，固定的对象会阻碍GC的内存压缩过程，加剧碎片化程度。
• 对象生命周期设计缺陷：部分批处理对象被长生命周期的引用意外持有，虽然你看不到内存队列堆积，但对象无法被GC回收，也会间接导致空闲内存块无法合并复用。

第三步：对应修复方案 #

• 针对LOH碎片化：
  .NET Core 3.0及以上版本可以直接开启LOH动态压缩，在项目文件中添加如下配置：

  <PropertyGroup>
    <RuntimeHostConfigurationOption Include="System.GC.LOHCompactionThreshold" Value="90" />
  </PropertyGroup>
  

  也可以在程序启动时设置环境变量DOTNET_GC_LOH_COMPACTION_THRESHOLD=90，数值代表LOH碎片化率达到对应百分比时自动触发压缩。代码层面可以通过ArrayPool<T>复用大数组、拆分过大的缓冲区，从根源减少大对象的生成。
• 针对固定对象过多：
  检查非托管调用的内存释放逻辑，尽量缩短fixed块的生效时长，优先使用.NET官方提供的IO类库避免不必要的内存固定操作。
• 针对GC模式适配：
  长时间运行的后端服务建议开启服务器GC模式，在项目文件中添加配置：

  <PropertyGroup>
    <ServerGarbageCollection>true</ServerGarbageCollection>
  </PropertyGroup>
  

  服务器GC的内存段尺寸更大，内存分配策略更适合高吞吐的长时间运行场景，能大幅降低碎片化概率。

第四步：效果验证 #

修复完成后用dotnet-counters工具监控进程运行状态：

dotnet-counters monitor --process-id <进程ID>

重点观察GC Heap Size、LOH Size、GC Fragmentation三个指标，长时间运行后指标稳定没有持续上涨趋势，即说明修复生效。

内容的提问来源于stack exchange，提问作者user3740951