ASP.NET Core应用内存泄漏咨询：两个相似方法表现差异

我来帮你拆解这个场景里的关键细节，以及排查潜在问题的具体方向：

已知场景梳理 #

• 你的类 MyClass 是通过 services.AddScoped<MyClass>() 注册到DI容器的，生命周期为请求级（Scoped）
• 类中包含两个仅参数不同、均返回null的相似方法（暂称Method-1和待排查方法）
• 应用启动无请求时内存稳定在90MB
• Method-1在每分钟150次调用频率下无内存泄漏现象

核心排查方向 #

1. 聚焦方法参数的差异

因为两个方法核心逻辑一致，唯一变量是参数，所以优先检查：

• 参数类型：如果待排查方法的参数是引用类型，是否在方法内部被意外存入了静态集合、单例对象的缓存等长生命周期存储中？这会导致参数对象无法被GC回收
• 参数来源：如果参数来自外部（比如请求上下文、其他服务实例），是否在方法处理后被某个长生命周期对象（如Singleton服务）引用？
• 参数大小：如果参数是大对象（如大字符串、字节数组），即使方法返回null，执行过程中创建的临时大对象可能晋升到老年代，GC回收不及时会导致内存持续上涨

2. 验证Scoped服务的生命周期正确性

虽然你用了AddScoped，但要确认：

• MyClass的实例是否真的在请求结束后被容器释放？可以在MyClass的析构函数中添加日志，验证每个实例是否在请求完成后被回收
• 是否有长生命周期服务（如Singleton）直接或间接引用了MyClass的实例？这种情况会导致Scoped实例无法被GC回收，进而引发泄漏

3. 检查方法内部的隐性副作用

即使方法返回null，也可能存在隐藏的内存泄漏点：

• 是否注册了事件回调、创建了定时器，但未在方法结束时取消/释放？
• 是否使用了静态变量存储临时数据？比如在方法内部给静态字段赋值，导致对象被静态引用持有
• 是否与外部资源（如数据库连接、文件句柄）建立了关联，但未正确释放？

4. 用诊断工具做精准分析

借助内存诊断工具定位问题：

• 捕获调用待排查方法前后的内存快照，对比对象分布，找出增长最快的对象类型
• 查看对象的引用链，确认哪些对象持有了本该被回收的实例（比如MyClass本身、参数对象）
• 追踪GC的回收频率和代际分布，检查是否有对象频繁晋升到老年代无法被及时回收

内容的提问来源于stack exchange，提问作者Gautam T Goudar