.NET Core应用第2代垃圾回收代出现异常对象堆积问题

可能的原因 #

• 服务生命周期配置错误：如果大量泛型服务被注册成Singleton，或者手动通过ServiceProvider创建实例时没正确释放依赖，会导致反射相关的类型元数据被长期持有。比如反复调用serviceProvider.GetService<GenericService<T>>()生成新泛型实例，这些实例的类型信息会被ServiceProvider缓存，没法被GC回收。
• EF Core 反射缓存泄漏：EF Core处理查询、实体映射时依赖反射生成元数据，要是存在大量动态查询（比如循环里拼接FromSqlRaw动态SQL，或者频繁手动new DbContext），会让这些反射辅助对象没法被回收。哪怕升级到.NET7，代码里重复生成相同泛型查询逻辑的话，还是会触发堆积。
• 序列化逻辑未复用缓存：不管是Newtonsoft.Json还是System.Text.Json，处理泛型序列化都会缓存反射信息。要是每次序列化都新建JsonSerializerSettings或JsonSerializerOptions，不复用配置，会导致大量RuntimeTypeHelper这类对象留存。
• 自定义反射逻辑滥用：项目里如果有频繁调用Type.GetProperties()、MethodInfo.Invoke()这类反射API，又没缓存结果，每次调用都会生成新的GenericFieldInfo、RuntimeMethodHandler实例，而这些实例被ServiceProvider的单例或作用域对象引用，没法被GC回收。

排查验证步骤 #

• 检查服务注册代码：过一遍所有AddSingleton/AddScoped/AddTransient的注册逻辑，确认泛型服务的生命周期是否合理。比如不需要全局单例的泛型服务，却被注册成Singleton，会永久持有关联的反射元数据。
• 审计DbContext使用方式：确保DbContext是通过依赖注入获取（比如Scoped生命周期），别手动new DbContext。同时检查有没有在循环里动态构建LINQ查询，且没复用表达式树的情况。
• 检查序列化代码：确认序列化时复用了JsonSerializerOptions或JsonSerializerSettings，别每次都新建配置。另外排查是否有大量动态泛型类型的序列化操作，且没利用序列化器缓存。
• 深挖dotMemory引用链：虽然部分堆栈模糊，但可以用dotMemory的「路径到根」功能，找到这些反射对象被ServiceProvider留存的具体路径——比如是某个单例服务持有了元数据，还是ServiceProvider内部缓存没清理。

是否正常？后续优化方向 #

这种线性增长的反射元数据堆积绝对不是正常现象，长期必然导致内存耗尽。要是暂时没找到根源，可以先从这些方向缓解内存压力：

• 手动缓存反射结果：对频繁用的反射操作（比如获取类型属性、方法），把PropertyInfo、MethodInfo实例缓存起来，别重复调用反射API生成新对象。
• 及时释放服务作用域：别长期持有IServiceScope实例，用完就调用Dispose()释放作用域内的服务，减少不必要的对象引用。
• 启用.NET反射优化：在.NET7+环境下，设置DOTNET_EnableReflectionAOTOptimizations环境变量，启用反射的AOT优化，减少运行时生成的反射辅助对象数量。
• 加内存监控：在K8s里配置Prometheus+Grafana监控内存变化，结合本地dotMemory的测试数据，验证优化措施的效果。

内容的提问来源于stack exchange，提问作者alpha-mouse