ASP.NET Core Web API返回类实例疑似内存泄漏问题咨询

你观察到的内存缓慢上涨，90%以上属于GC正常的延迟回收行为，不属于内存泄漏。
.NET Core的GC采用分代回收策略，不会在接口请求结束、返回对象失去引用的瞬间立刻回收内存：只有当某一代的内存分配阈值被触发，或者系统发出低内存通知时，GC才会执行回收操作。且GC完成对象回收后，也不一定会立刻将内存交还给操作系统，运行时会预留一部分内存作为工作池，避免频繁向系统申请/释放内存带来的性能损耗，这也是进程内存数值看起来偏高的常见原因。

绝对不要在业务代码中主动强制触发GC。
你确实可以通过调用GC.Collect()方法触发全代垃圾回收，但这个操作会打断GC原生的调度逻辑，触发全线程暂停（STW），直接拖慢接口响应性能，属于典型的负优化：

• 如果真的存在内存泄漏，说明对象始终被有效引用持有，强制GC也无法回收这部分内存
• 如果是正常的延迟回收，强制GC完全是多余操作，运行时会在合适的时机自动完成回收

不要直接用任务管理器的进程内存数值判断是否泄漏，这个数值包含了运行时预留的未使用内存，参考价值极低：

• 先用dotnet-counters工具实时监控GC堆的实际已用内存，在停止所有请求、等待1-2分钟后，观察GC堆内存是否能回落到稳定基线。如果可以回落，就完全不存在内存泄漏问题。
• 如果GC堆内存持续上涨不回落，再通过dotnet-dump或者Visual Studio内存分析工具抓取两次不同时间点的内存快照，对比对象引用根，排查是否存在Response类实例被静态变量、单例服务、长生命周期缓存持有引用的情况。正常情况下，接口返回的Response对象在序列化完成后就会失去所有引用，进入0代回收队列，不会长期驻留堆内存。

• 如果你的Response类仅用于承载序列化输出字段，没有多态、继承类的逻辑需求，可以将普通class改为record struct值类型，从根源减少堆内存分配，降低GC的回收压力
• 不要在Response类中持有非托管资源、流对象的引用，如果必须持有这类资源，要正确实现IDisposable接口并在序列化完成后及时释放
• 对于接口返回的固定值、固定响应片段，可以用静态只读实例复用，避免每次请求都重复创建相同内容的对象
• 关闭不必要的XML/JSON序列化输出配置，避免序列化过程中产生多余的临时对象分配

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