GetProcessHandleCount是最轻量、最可靠的实时句柄计数方式，返回当前进程内核对象句柄总数（含文件、事件、互斥体等），无需权限，仅需传入GetCurrentProcess()句柄，适合5–10秒周期采样观察异常增长趋势。
Windows平台下用GetProcessHandleCount快速检查句柄数是否异常增长
直接调用GetProcessHandleCount是最轻量、最可靠的实时句柄计数方式。它返回当前进程打开的内核对象句柄总数（包括文件、事件、互斥体、线程等），不需管理员权限，也不依赖调试器。
常见误判点：很多人拿这个值和“系统限制”（如默认 16384）对比，但实际瓶颈往往出现在更早阶段——比如句柄表碎片、特定类型对象泄漏（如WaitForMultipleObjects未关闭的EVENT）、或子线程继承了不该继承的句柄。
- 调用前确保传入的是当前进程句柄：
GetCurrentProcess()，不是INVALID_HANDLE_VALUE或硬编码数值 - 建议每 5–10 秒采样一次，在稳定状态下观察趋势，单次数值意义不大
- 注意该函数不区分句柄类型，无法定位泄漏源，仅作“有无异常”的第一道判断
用Process Hacker或Handle.exe定位具体泄漏对象
当GetProcessHandleCount持续上涨，就得查具体是哪类句柄在涨。微软官方Handle.exe（Sysinternals套件）和开源工具Process Hacker能按类型、名称、堆栈（需PDB）列出所有句柄。
实操关键点：
立即学习“C++免费学习笔记（深入）”；
- 运行时加
-p <pid>参数指定进程，避免扫描整个系统；例如：handle.exe -p 1234 - 重点关注
Event、Section、Key、File这几类高频泄漏对象，尤其是名称含Local\或Global\的命名对象 - 若看到大量重复名称（如
Local\MyWorkerThreadEvent_001递增），基本可锁定创建逻辑未配对CloseHandle -
Process Hacker支持右键“Stack Trace”，但需程序运行时加载了对应模块的PDB，否则显示为???
C++代码中主动记录句柄生命周期（预防性手段）
靠事后排查总比不上从源头控制。在封装CreateEvent、CreateMutex、CreateFile等API时，加一层RAII包装，并启用全局计数器。
示例思路：
class ScopedHandle {
HANDLE h_;
public:
ScopedHandle(HANDLE h) : h_(h) {
if (h != INVALID_HANDLE_VALUE) {
InterlockedIncrement(&g_total_handles);
}
}
~ScopedHandle() {
if (h_ != INVALID_HANDLE_VALUE) {
CloseHandle(h_);
InterlockedDecrement(&g_total_handles);
}
}
// ... move ctor, release(), etc.
};
- 全局计数器
g_total_handles用volatile LONG或std::atomic<int>，避免多线程竞争导致统计失真 - 不要只记录总数，建议按类型分桶（
g_event_count、g_mutex_count），方便快速归因 - 上线前关闭此统计（宏开关），避免性能损耗；开发/测试环境默认开启
为什么QueryPerformanceCounter不适合监控句柄泄漏
有人试图用高精度计时器测GetProcessHandleCount耗时来反推句柄数量，这是无效路径。该API本身常驻缓存，耗时稳定在几十纳秒级，与句柄数无关；而真正慢的操作（如遍历句柄表）只发生在Handle.exe这类工具内部。
更隐蔽的问题：
- 某些驱动或AV软件会hook句柄操作，导致
GetProcessHandleCount返回值滞后或不准（罕见但存在） - 句柄泄漏可能伴随内存泄漏，但两者无必然因果——一个
CreateEvent泄漏只占约 0x30 字节内核结构，却可能导致线程永久阻塞 - 32位进程在接近65535句柄时可能触发
ERROR_TOO_MANY_OPEN_FILES，但64位进程通常先遇到内存或句柄表碎片问题
真正难定位的，永远是那些没名字、没日志、只在特定IO路径下才创建的句柄——比如异步I/O完成端口绑定的FILE句柄，或COM初始化时悄悄打开的注册表键。
