Windows内存泄露排查指南：我是如何揪出那些”吃内存”的程序的

上周我的开发机又双叒叕卡成PPT了，16GB内存被吃得干干净净。作为一名和Windows相爱相杀多年的老司机，我决定把这些年排查内存泄露的经验总结出来。毕竟这种事每个月都要来那么几次，与其每次都重新搜索解决方案，不如自己整理一套方法论。

一、那些肉眼可见的症状

内存泄露最明显的特征就是——电脑越用越卡。但具体怎么判断是不是内存泄露呢？我通常会观察这几个迹象：

• 开机后内存占用随时间线性增长（注意是线性！不是波动）
• 即使关闭所有应用程序，可用内存也不恢复
• 任务管理器里某个进程的内存占用数字像股票牛市一样只涨不跌

有一次我的Chrome开了30个标签页内存才占用4GB，而某个后台服务进程悄咪咪就吃了8GB，这种就是典型的泄露现场。

二、任务管理器只是开始

很多人一遇到内存问题就打开任务管理器，这没错，但任务管理器显示的内存信息很有限。我习惯用以下组合拳：

# 查看详细内存信息
Get-WmiObject -Class Win32_OperatingSystem | 
Select-Object FreePhysicalMemory, TotalVisibleMemorySize

更专业的工具是RAMMap，它能显示内存的具体分配情况。有次我就靠它发现是系统缓存没释放导致的问题，重启”Windows内存压缩”服务就好了。

三、性能监视器才是大杀器

按Win+R输入perfmon打开性能监视器，添加这些计数器：

• Memory -> Available MBytes（可用内存）
• Process -> Private Bytes（各进程私有内存）
• .NET CLR Memory -> # Bytes in all Heaps（托管内存）

把这些数据记录成日志，用Excel做成趋势图，泄露源往往一目了然。我曾经用这个方法抓到一个每周增长2GB的C#服务，最后发现是某个静态集合忘了清理。

四、当常规方法都失效时

有些泄露特别隐蔽，这时候就要上Windows调试工具集了：

:: 抓取内存快照
procdump -ma 可疑进程ID

然后用WinDbg分析dump文件，查看堆分配情况。不过这个方法门槛较高，建议先尝试用VMMap这种图形化工具。

五、我的防泄露小技巧

最后分享几个实战中总结的经验：

1. 定期重启”罪魁祸首”服务（比如SQL Server）
2. 用EmptyWorkingSetAPI强制释放闲置内存
3. 给Java程序加上-XX:+HeapDumpOnOutOfMemoryError参数
4. 养成看系统日志的习惯（事件查看器里搜”内存”）

内存泄露就像慢性病，早发现早治疗。希望这篇笔记能帮你少走弯路——毕竟谁都不想半夜被报警短信吵醒，对吧？