内存泄漏排查关键看“该释放时不释放”的持续增长趋势，首选windows性能监视器（perfmon）监控private bytes、handle count等计数器，采样间隔15–60秒、时长超30分钟，结合操作周期识别反常增长。
发现程序运行时的内存泄漏，关键不是看“瞬间占用高”，而是观察“该释放时不释放”的持续增长趋势。Windows 自带的性能监视器（PerfMon）是最直接、无需安装第三方工具的排查手段，适合大多数用户快速验证和定位。
盯住几个核心计数器
打开 PerfMon（Win + R → 输入 perfmon → 回车），添加以下计数器，重点关注你怀疑的应用进程（如 chrome.exe、yourapp.exe）：
- Process → Private Bytes：进程独占的内存总量。这是判断用户模式泄漏最可靠的指标——若它随时间单调上升，且在空闲或操作完成后不回落，基本可确认泄漏。
- Process → Working Set：当前驻留在物理内存中的大小。辅助参考，但易受系统缓存影响，不能单独作为依据。
- Process → Handle Count：句柄数。持续上涨常伴随内存泄漏，说明资源（文件、窗口、事件等）未关闭。
- Process → Thread Count：线程数。异常增长可能意味着线程创建后未正确退出或回收。
- Memory → Pool Paged Bytes / Pool Nonpaged Bytes：区分泄漏层级。前者明显涨→倾向用户模式；后者单边涨→需怀疑驱动或内核组件。
设置合理监控方式
短时间刷新（比如每5秒）容易误判波动，真正有效的观察需要捕捉缓慢积累过程：
- 采样间隔建议设为 15–60 秒，总监控时长至少 30 分钟以上，尤其覆盖应用启动、执行典型操作、再回到空闲状态的全过程。
- 使用“数据收集器集”功能（左侧树 → 数据收集器集 → 新建）把数据保存为 CSV 文件，方便后续用 Excel 绘图分析趋势。
- 避免同时运行其他大型程序，减少干扰，让曲线变化更真实反映目标进程行为。
识别泄漏的典型表现
不是所有内存增长都是问题，要抓住“反常性”：
- 执行相同操作（如打开/关闭一个文档、刷新一次列表）后，Private Bytes 每次都比前一次更高，且不回落到接近初始值。
- 应用已最小化或进入后台空闲超过5分钟，Private Bytes 和 Handle Count 仍在缓慢爬升。
- Working Set 随 Private Bytes 上涨而扩大，但系统可用内存却明显减少，任务管理器显示“已提交”持续增加。
- 对比多个时间段的快照，发现某类对象（如字符串、字典、控件实例）数量只增不减，尤其在 .NET 应用中可通过 .NET CLR Memory → # Bytes in all Heaps 验证。
确认后下一步怎么做
PerfMon 能告诉你“有没有泄漏”和“大概是谁”，但不能直接指出哪行代码出了问题：
- 若锁定是某个用户态进程（如桌面软件、服务），可用 UMDH 工具配合调试符号抓取堆分配调用栈。
- 若怀疑是 .NET 应用，配合 dotMemory 或 Visual Studio 内存使用工具拍快照比对，查看对象保留路径。
- 若 Pool Nonpaged Bytes 异常增长，需用 PoolMon 定位具体驱动标签，再结合驱动签名排查。
