Azure中.NET6的ASP.NET Core API的w3wp进程内存泄漏咨询

IIS是否会缓存Web请求？ #

IIS默认不会无限留存所有请求URL到内存中。它的缓存机制主要针对静态资源（如HTML、图片），或者通过输出缓存配置的动态内容，不会无差别存储数百万条完整请求URL。

请求URL被无限持有的可能原因 #

• 第三方中间件/组件：应用中引入的日志、监控、APM（应用性能管理）组件可能在处理请求时，将URL等请求信息存入全局集合或未正确释放的对象中。比如某些自定义日志库错误地将请求URL添加到静态列表且未做过期清理，会导致内存持续增长。
• IIS附加模块配置：如果启用了IIS的失败请求跟踪（Failed Request Tracing）且配置不当，或者使用了URL Rewrite等模块的日志/调试功能，可能会意外留存请求数据。部分模块在开启详细日志时，可能会在内存中暂存请求信息但未及时回收。
• ASP.NET Core诊断功能：.NET 6的Microsoft.AspNetCore.Diagnostics相关组件（如开发者异常页、请求日志中间件），如果配置了过高的日志级别或未限制日志留存，可能导致请求数据被长期持有。尤其是自定义日志提供器未正确实现资源释放逻辑时更易出现。
• 非托管内存泄漏的间接引用：原生堆中的URL字符串可能被托管代码中的静态对象、单例实例持有，导致GC无法回收。即使栈跟踪找不到，也可通过分析内存转储中的对象引用链（比如用WinDbg的!gcroot命令针对托管对象，或者!heap -s分析原生堆分配）定位持有方。
• 自定义代码中的内存泄漏：应用代码中可能存在静态字典、列表等集合，处理请求时不断添加URL或请求对象，但未设置过期策略或清理逻辑。比如某些全局请求上下文存储，错误地将每个请求的URL永久保存。

排查建议 #

1. 逐步禁用非核心组件：先关闭第三方日志、监控中间件，观察内存增长是否缓解，以此定位问题来源。
2. 检查IIS配置：禁用失败请求跟踪、URL Rewrite的调试日志，确认是否是IIS模块导致的内存占用。
3. 深入分析内存转储：针对原生堆，使用WinDbg的!heap -stat查看内存分配类型，找到存储URL的内存块所属堆；再用!heap -flt s <size>筛选对应大小的内存块，结合!dumpmem查看内容，进一步定位分配这些内存的模块（通过!address <address>查看内存所属模块）。
4. 检查应用静态资源：排查代码中的静态集合、单例对象，确认是否有持有请求URL的逻辑，添加过期清理机制（如定时清理、使用弱引用）。

内容的提问来源于stack exchange，提问作者Sam.C