.NET 6容器应用Gen2内存无限增长致OutOfMemoryException问题排查

AI 小北

2026-8-8

.NET 6容器应用Gen2内存持续增长导致OOM问题

问题背景

部署在AWS ECR Linux容器中的.NET 6应用，仅负责PostgreSQL数据库的读写操作，近期日均崩溃一次，抛出System.OutOfMemoryException异常。通过App Dynamics监控可见：

按GC逻辑，Gen2内存未被回收意味着对象仍被认为是可达状态，但该应用是仅执行LINQ查询并返回结果的无状态服务，为何出现这种情况？

内存使用情况截图

DbContext生命周期配置错误：如果依赖注入中把DbContext注册为Singleton而非Scoped，会导致单个DbContext实例长期存在，其跟踪的大量实体对象无法被GC回收，持续堆积在Gen2
EF Core实体跟踪未禁用：默认情况下EF Core会跟踪所有查询返回的实体，若批量查询大量数据且未使用AsNoTracking()，这些被跟踪的实体会被DbContext持有，长期积累占用Gen2内存
静态集合/缓存未清理：代码中若存在静态集合（如static List<T>、static Dictionary<K,V>），查询后将实体对象添加进去但未做清理，这些对象会被根引用锁定，无法被GC回收
第三方库资源泄漏：PostgreSQL驱动（Npgsql）或其他依赖库存在未正确释放资源的bug，导致内存无法回收
Linux容器GC适配问题：.NET在Linux容器环境下默认GC行为可能未优化，比如未启用服务器GC，导致Gen2内存回收不及时
长期存活的中等对象堆积：大量略小于85KB的对象被长期引用，会被晋升到Gen2，若这些对象无法被释放，就会导致Gen2内存持续增长

修正DbContext生命周期：确保使用AddDbContext时指定ServiceLifetime.Scoped，每个请求对应一个DbContext实例，请求结束后及时释放
禁用不必要的实体跟踪：对不需要修改的查询添加AsNoTracking()或AsNoTrackingWithIdentityResolution()，减少EF Core的内存占用
排查静态资源：检查代码中的静态变量/集合，确认是否存在未清理的对象引用，必要时改用弱引用或定时清理机制
捕获内存转储分析：使用dotnet-dump工具在内存增长到一定程度时捕获转储，通过dotnet-dump analyze命令分析Gen2中的对象类型及引用链，定位根引用

优化GC配置：在appsettings.json中启用服务器GC并调整内存阈值：

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true,
      "System.GC.HeapHardLimitPercent": 75
    }
  }
}

内容的提问来源于stack exchange，提问作者jeff.eynon