W3wp.exe内存占用过高：ASP.NET WebService生产环境内存泄漏调试方法咨询

碰到ASMX服务在IIS7上内存飙到5GB的情况，确实头疼——毕竟生产环境不能随便停服务瞎调试。我之前帮团队排查过类似问题，给你整理几个实用的生产环境调试思路，尽量不影响业务：

先排除一些非代码层面的问题，快速缩小范围：

• 确认是否真的是内存泄漏：打开任务管理器或资源监视器，观察w3wp.exe的内存走势。如果连续发起服务请求后内存只升不降，手动回收应用池后内存大幅回落，那基本可以确定是泄漏；如果回收后内存还是很高，可能是IIS本身或系统层面的问题。
• 检查应用池回收配置：很多时候只是IIS应用池的回收策略没配置好！比如没设置内存阈值回收，导致内存一直累积。可以先临时给应用池加个内存回收阈值（比如设2GB），先缓解业务压力，再慢慢排查根因。

生产环境不能直接挂调试器，但可以生成内存转储文件离线分析，这是最靠谱的方法：

• 生成完整内存转储：用微软官方的procdump工具，在内存占用较高的时候执行命令：

  procdump -ma w3wp.exe
  

  -ma参数会生成包含所有内存数据的完整转储，确保后续分析能拿到足够信息。注意要在服务器上下载procdump，别用第三方工具，避免安全风险。
• 离线分析转储文件：用WinDbg或Visual Studio打开转储文件（推荐WinDbg，功能更强大）：
  1. 先加载.NET调试扩展：根据你的.NET版本，执行.loadby sos clr（.NET Framework）或.loadby sos coreclr（.NET Core）。
  2. 查看托管堆统计：执行!dumpheap -stat，看各类对象的数量和内存占用，找那些异常多的类型（比如某个自定义业务类实例有几十万条）。
  3. 追踪对象引用：找到可疑对象的地址后，执行!gcroot <对象地址>，就能看到这个对象被谁持有引用——比如静态集合、全局变量、未释放的资源等，这一步通常能直接定位泄漏点。
  4. 查看具体实例：如果需要更细节，用!dumpheap -type <可疑类型名>查看该类型的所有实例，看有没有被意外缓存、长期持有情况。

结合转储分析的结果，重点检查以下几个常见坑：

• 静态变量/静态集合：ASMX里的静态对象是全局共享的，如果用了静态List、Dictionary这类集合，又没做定期清理，很容易累积大量对象。比如有些服务把请求日志存进静态集合，忘记过期删除。
• 非托管资源未释放：数据库连接、文件流、COM组件这些非托管资源，必须用using语句包裹，或者手动调用Dispose()。尤其要注意第三方组件，有些组件内部会持有非托管资源，得确认有没有正确释放。
• 缓存滥用：不管是用ASP.NET自带的Cache还是自定义缓存，如果缓存了大对象、设置了过长的过期时间，或者缓存命中率极低却一直存着，都会导致内存飙升。
• InProc会话状态：如果启用了进程内会话（InProc），会话里存了大对象或过多数据，也会导致内存累积。可以考虑改用State Server或SQL Server会话，把会话数据移出进程内存。

• 启用.NET性能计数器：在Windows性能监视器里添加.NET CLR Memory相关计数器，比如# Bytes in All Heaps、Gen 2 Collections、Promoted Memory from Gen 0。如果Gen 2内存持续增长、GC回收次数极少，说明有大量长期存活的对象没被回收，指向泄漏。
• 关键代码加日志：在对象创建、释放的关键节点加日志，记录对象ID、创建时间、释放时间，排查是否存在创建后未释放的情况。

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