系统性能监视器如何检测资源泄漏？

通过性能监视器观察特定资源计数器的长期趋势可发现资源泄漏。1. 内存泄漏表现为私有字节（Private Bytes）和工作集（Working Set）持续上升，即使应用空闲也无法回落；2. 句柄或线程泄漏可通过Handle Count和Thread Count不断增长来识别；3. 长期监控需配置数据收集器集（DCS），添加关键计数器如Private Bytes、Handle Count、Thread Count等，设置合理采样间隔（如30秒至5分钟），定义运行时长或日志大小上限，以捕获缓慢积累的泄漏趋势。建立正常基线后，任何持续偏离即为早期信号。

通过系统自带的性能监视器发现资源泄漏，核心在于观察特定资源计数器的长期趋势。当某个应用程序存在资源泄漏时，你会看到其占用的内存（私有字节、工作集）、句柄数、线程数，甚至是非分页池或分页池使用量，在长时间运行后呈现出一种不自然的、持续上升的趋势，即使应用处于空闲状态或完成了任务，这些数值也无法回落到正常水平。这就像是水龙头没拧紧，水箱里的水一直在慢慢上涨。

解决方案

要着手发现这些“水龙头”，首先得打开“性能监视器”（在运行中输入 perfmon.msc 就能找到）。我的习惯是先从一个整体视角切入，再逐步聚焦。

启动后，你会看到一个实时图表。第一步，也是最关键的一步，是添加合适的计数器。点击工具栏上的绿色加号，然后：

1. 针对内存泄漏： 展开 Process 对象，选择你怀疑有问题的进程实例（如果不知道，可以先选 ，但数据会比较杂乱），然后添加 Private Bytes 和 Working Set。Private Bytes 是该进程独占的内存，Working Set 则是它当前在物理内存中的大小。如果这两个值持续上涨，尤其是 Private Bytes，那内存泄漏的可能性就很大了。我还会加上 Memory 对象下的 Pool Nonpaged Bytes 和 Pool Paged Bytes，这能帮我看看是不是内核对象泄漏，虽然直接指向特定进程有点难，但作为系统级的参考很有价值。
2. 针对句柄或线程泄漏： 同样在 Process 对象下，添加 Handle Count 和 Thread Count。句柄是程序访问系统资源的“钥匙”，线程是执行代码的最小单元。如果这两个计数器不断增加，尤其是在应用应该释放资源后依然如此，那多半是句柄或线程没有正确关闭。
3. 长期监控： 很多泄漏并非一蹴而就，而是缓慢积累。这时，你需要配置“数据收集器集”。在性能监视器的左侧导航栏，展开 数据收集器集 -> 用户定义，右键选择 新建 -> 数据收集器集。给它起个名字，选择 手动创建。接下来，添加 性能计数器，把你刚才选择的那些关键计数器都加进去。设置好采样间隔（比如每 15 秒或 1 分钟），以及数据保存位置和停止条件。这样，你就可以让它在后台默默运行几个小时甚至几天，然后回头分析数据文件。

观察图表时，最重要的是寻找那种“单向行驶”的曲线。正常情况下，应用的资源使用会随着工作负载的增减而波动，但泄漏的特征是，即使负载降低，甚至应用空闲，某个计数器依然保持着上升的势头，或者至少无法回落到基线。这种现象，就是资源泄漏的典型信号。

如何识别进程内存泄漏的早期迹象？

我的经验是，识别内存泄漏的早期迹象，更多的是一种对“不协调”的直觉判断，然后用数据去验证它。最直观的，就是关注 Process 对象下的 Private Bytes 和 Working Set 这两个计数器。

早期迹象往往不是那种爆炸式的内存增长，那通常是严重的Bug，很容易发现。更多时候，它表现为一种缓慢而持续的爬升。比如，你有一个服务，它每隔一段时间处理一些数据。正常情况下，处理完后，Private Bytes 应该会回到一个相对稳定的水平。但如果你发现，每次处理后，它的基线都会比上次高一点，或者即使长时间没有工作，这个值也在缓慢地、不可逆转地增加，那这就是一个很强的信号。

Working Set 也是一个好指标，它反映了进程当前在物理内存中的活跃部分。如果 Working Set 持续膨胀，甚至远超其正常工作所需的范围，那也可能是内存管理不当导致的。我还会特别留意那些“瞬时峰值”之后，内存没有及时释放的情况。这就像是你在一个房间里，每次用完东西都堆在地上，久而久之，房间就满了。这种“不清理”的趋势，就是早期泄漏的典型特征。建立一个应用的“正常”内存使用基线非常重要，任何偏离这个基线的持续性增长，都值得深入探究。

性能监视器中哪些计数器最能揭示句柄或线程泄漏？

对于句柄和线程泄漏，性能监视器里有两个计数器是我的首选，也是最直接的证据：Process 对象下的 Handle Count 和 Thread Count。

Handle Count 衡量的是一个进程当前打开的系统对象（文件、注册表键、事件、互斥体等）的总数。如果你的应用程序在执行某个操作时，需要打开一些文件或创建一些事件，但却没有正确关闭它们，那么 Handle Count 就会持续增加。我见过一些应用，在长时间运行后，句柄数能飙升到几十万甚至上百万，这通常会导致系统资源耗尽，最终表现为系统响应缓慢，甚至无法打开新的文件或创建新的进程。这种泄漏往往比内存泄漏更隐蔽，因为它可能不会立即导致内存耗尽，而是逐渐蚕食操作系统的核心资源。

Thread Count 则表示一个进程中当前活跃的线程数量。应用程序可能会创建线程来执行并发任务。如果这些线程在完成任务后没有被正确终止或回收，那么 Thread Count 就会不断累积。过多的线程会增加操作系统的调度开销，消耗大量的内核内存（每个线程都有自己的栈和内核对象），最终导致系统性能下降，甚至崩溃。在分析这类问题时，我通常会观察一个应用在不同工作负载下的线程数变化。如果它在空闲时段，线程数依然居高不下，或者持续增长，那无疑是线程泄漏的警示。

这两个计数器，在我看来，是发现这类“隐形杀手”最有效的工具。它们直接指向了操作系统层面的资源管理问题，而不仅仅是应用自身的堆内存。

长期监控资源使用，应如何配置数据收集器集？

长期监控资源使用，特别是在寻找那些“慢性病”式的资源泄漏时，数据收集器集（Data Collector Sets, DCS）是不可或缺的。配置得当的DCS能帮你自动化收集数据，省去手动操作的麻烦，并且能捕捉到那些瞬时性能图表难以发现的趋势。

我的配置策略是这样的：

1. 明确监控目标： 在创建DCS之前，我会先想清楚我最想看什么。是某个特定应用的内存、句柄、线程，还是整个系统的池内存使用？这决定了我要添加哪些计数器。
2. 选择关键计数器： 基于上述目标，我会添加一系列计数器。比如，针对一个可能存在内存泄漏的Web服务，我会添加它的 Process 对象下的 Private Bytes、Working Set、Handle Count、Thread Count。同时，为了有个全局视角，我可能还会加上 Memory 对象下的 Available MBytes 和 Processor 对象下的 % Processor Time。
3. 设置合理的采样间隔： 采样间隔是个大学问。太短会产生海量数据，分析困难；太长又可能错过关键的瞬时变化。对于缓慢的资源泄漏，我通常会从 30 秒到 5 分钟不等。如果我怀疑是某种瞬时操作导致的泄漏，可能会缩短到 5-10 秒。这是一个需要根据实际情况调整的参数，没有绝对的“最佳”值。
4. 定义停止条件： 我通常会设置一个最长持续时间（比如 24 小时或 72 小时），或者一个最大文件大小。这样可以避免DCS无限期运行，耗尽磁盘空间。
5. 配置日志格式： 通常我会选择 二进制 格式，因为它效率高，并且在性能监视器中回放和分析非常方便。文本格式（CSV）虽然可以直接用Excel打开，但对于大量数据来说，处理起来反而更麻烦。
6. 调度任务： 如果是需要定期收集数据，或者在特定时间段内监控，我会配置DCS的启动和停止计划。比如，让它在每天凌晨 2 点启动，运行 8 小时。

配置好DCS后，它就像一个不知疲倦的侦探，默默地记录着系统的脉搏。当我需要分析时，只需打开保存的日志文件，就能看到应用程序在长时间运行下的真实表现，那些缓慢积累的泄漏，在时间轴上会变得异常清晰。这比盯着实时图表要高效得多，也更能揭示问题的本质。