最可靠方式是用Process Explorer多次刷新观察Handle Count是否单调递增；上万且持续上涨即基本可断定句柄泄漏，再通过Handles页签按Type或Name筛选定位泄漏源。
怎么看进程的句柄数是否异常增长
Windows 进程句柄数持续上涨，是句柄泄露最直接的信号。用 TaskManager 看不准——它只刷新一次、不支持历史趋势。更可靠的是用 Process Explorer（Sysinternals 工具），打开后右键目标进程 → Properties → Handles 页签，勾选 Show kernel handles，再点 Refresh 多次观察 Handle Count 是否单调递增（尤其在反复执行某操作后）。如果稳定在几百、几千还行；上万且持续涨，基本可以断定有泄露。
怎么定位泄露的具体句柄类型和调用位置
光知道“涨了”没用，得知道“谁干的”。Process Explorer 的 Handles 页签支持按 Type（如 Event、Thread、Section）或 Name（如 \BaseNamedObjects\MyMutex）排序筛选。重点关注重复出现、数量激增的类型；若看到大量匿名 Event 或未命名 Section，大概率是代码里 CreateEvent / CreateFileMapping 后漏了 CloseHandle。配合 Stack 列（需提前开启 Enable stack walking 并加载符号），能直接看到创建该句柄的调用栈——但注意：这仅对当前句柄有效，且要求 PDB 符号可用、编译时启用了帧指针（/Oy-）或 dbghelp.dll 支持。
怎么在代码里加轻量级句柄生命周期追踪
静态工具难覆盖所有路径，动态埋点更可控。不建议重写 CreateFile 这类 API（太重），推荐用 RAII 封装关键句柄类型：
class ScopedHandle {
public:
explicit ScopedHandle(HANDLE h = INVALID_HANDLE_VALUE) : handle_(h) {}
~ScopedHandle() { if (handle_ != INVALID_HANDLE_VALUE) CloseHandle(handle_); }
ScopedHandle(const ScopedHandle&) = delete;
ScopedHandle& operator=(const ScopedHandle&) = delete;
HANDLE get() const { return handle_; }
HANDLE release() { HANDLE h = handle_; handle_ = INVALID_HANDLE_VALUE; return h; }
private:
HANDLE handle_;
};
使用时：ScopedHandle h(CreateEvent(nullptr, TRUE, FALSE, nullptr));。这样即使函数中途 return 或抛异常，也能保证关闭。注意三点：INVALID_HANDLE_VALUE 是合法值（比如 CreateFile 失败返回它），不能直接当空指针用；CloseHandle 对已关闭句柄调用是安全的，但别依赖这点来“补救”；某些句柄（如 GetCurrentProcess() 返回的伪句柄）不能关，封装前要确认语义。
立即学习“C++免费学习笔记（深入）”；
为什么用 Application Verifier 检测不到句柄泄露
Application Verifier（AppVerif）默认不检查句柄泄露——它主要抓内存破坏、堆滥用、临界区误用。要让它管句柄，必须手动启用 Heaps + Handles 选项，并且目标进程需以调试模式启动（否则句柄跟踪开销太大，会拒绝加载）。即便开了，它也只报“未关闭的句柄”，不提供创建位置；而且对第三方 DLL 创建的句柄（比如 COM 组件内部调用 CreateThread）往往静默忽略。所以 AppVerif 更适合作为辅助手段，不能替代 Process Explorer 的实时观察和代码层的 RAII 防御。
真正难的不是发现泄露，而是区分“合理增长”和“泄露”：比如日志模块每秒创建一个 FILE 句柄用于轮转，只要旧句柄被及时关闭，就不是泄露。关键看关闭时机是否与创建严格配对，以及句柄总数是否有收敛趋势。
