.NET应用生产环境内存持续攀升，疑AWS环境导致垃圾回收异常

一、系统层面内存占用差异 #

• EC2实例页缓存积累：生产环境持续处理请求会产生大量磁盘/网络IO，系统会将频繁访问的数据缓存到内存（页缓存），这部分内存会被CloudWatch统计到总内存占用中。而测试环境闲置时，系统会主动释放闲置的页缓存，导致内存回落。你可以通过free -m命令在实例上区分应用内存和系统缓存内存。
• 容器/实例的长期运行积累：生产环境实例/容器可能连续运行数天甚至更久，系统内核、CloudWatch Agent、日志收集进程等可能会积累少量内存占用；而测试环境实例可能因为闲置被重启过（比如Auto Scaling缩容后扩容），或运行时间短，没有这类积累。

二、AWS服务集成的资源残留 #

• AWS SDK客户端的连接池与缓存：如果应用使用了AWS SDK（如S3、DynamoDB、Secrets Manager），生产环境持续请求会让客户端维护更多连接池线程、请求缓存或临时对象。这些资源在高负载下不会被GC回收，而测试环境闲置时，客户端的超时机制会清理闲置连接和过期缓存，释放内存。
• 负载均衡的长连接持有：生产环境ALB/NLB可能保持大量长连接（如HTTP/2连接），应用中对应的Socket、请求上下文对象会被持续持有，GC无法回收。测试环境闲置时，连接超时关闭，这些对象才会被清理。

三、.NET GC行为的环境差异 #

生产环境持续有请求时，.NET GC为避免服务停顿，会优先执行增量回收，不会立即清理大对象堆（LOH）或长期存活对象，导致内存呈现持续攀升的假象。而测试环境闲置时，GC有机会执行全量垃圾回收，彻底释放积压的内存。这种情况不是内存泄漏，只是GC在高负载下的自适应策略。

排查建议 #

• 确认CloudWatch指标维度：检查是统计应用进程的私有内存还是实例/容器的总内存，排除系统缓存的干扰。
• 抓取内存快照：在生产环境低峰期和测试环境闲置后分别用dotnet-dump抓取内存快照，对比对象类型和数量，定位是否有特定对象积累。
• 模拟生产闲置：在生产低峰期暂停流量（或切换到备用实例），观察内存是否回落，验证是否是GC回收时机的问题。
• 检查AWS SDK配置：调整SDK客户端的连接池大小、缓存过期时间，看是否能缓解内存攀升。

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