Windows上查当前进程句柄总数应使用GetProcessHandleCount，它最轻量、无需权限、仅需有效进程句柄（如GetCurrentProcess）；返回DWORD类型句柄数，失败时返回0且须用GetLastError判断原因。
Windows 上怎么查当前进程的句柄总数？
Windows 内核为每个进程维护一个句柄表，GetProcessHandleCount 是最直接、开销最低的 API。它不依赖 WMI 或性能计数器，也不需要管理员权限，只要传入本进程或有 PROCESS_QUERY_INFORMATION 权限的进程句柄即可。
- 调用前必须确保句柄有效，否则返回 0（不是错误，但不可信）
- 返回值是
DWORD类型，不是有符号整数；若超 42 亿（极罕见），实际值会被截断，但绝大多数场景无需担心 - 在多线程频繁创建/关闭句柄的场景下，该值是瞬时快照，不代表稳定水位
HANDLE h = GetCurrentProcess();
DWORD count = 0;
if (GetProcessHandleCount(h, &count)) {
// count 即当前句柄数
}
为什么 GetProcessHandleCount 返回 0？常见排查点
返回 0 并不总表示失败——它可能是成功写入了 0，也可能是调用失败但没检查 GetLastError()。必须搭配 GetLastError() 判断：
如果
GetLastError() == ERROR_SUCCESS，说明调用成功，且进程确实持有 0 个句柄（理论上可能，但仅见于极简沙箱环境）-
如果
GetLastError() == ERROR_INVALID_HANDLE，大概率是传入了已关闭或无效的进程句柄立即学习“C++免费学习笔记（深入）”；
如果
GetLastError() == ERROR_ACCESS_DENIED，目标进程开启了句柄保护（如某些安全软件或以SeDebugPrivilege之外方式启动的系统服务）确保用
OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid)获取句柄，而非继承或复制来的句柄不要复用已被
CloseHandle()关闭的句柄——C++ 中没有自动失效检测，容易静默出错
想监控全系统所有进程的句柄数，该用哪个接口？
Windows 没有单次调用返回“全系统句柄总数”的 API。可行路径只有两条：
枚举所有进程（
EnumProcesses），对每个 PID 调用OpenProcess+GetProcessHandleCount：简单直接，但需遍历上百个进程，且部分系统进程（如svchost子实例、lsass）会拒绝打开，导致跳过使用性能计数器（
\Process(*)\Handle Count）通过PdhAddCounter采集：支持 wildcard，能跨进程聚合，但延迟高（默认最小采样间隔 1 秒），且计数器名称需本地化适配（英文系统是Handle Count，中文系统是句柄计数）若用于告警（如某进程句柄 > 10000），推荐第一种；若用于趋势绘图（分钟级变化），第二种更稳
避免在循环中频繁调用
OpenProcess后不CloseHandle——这本身就会泄露句柄
句柄数暴涨却查不到泄漏源头？关键检查项
句柄数持续增长，但 GetProcessHandleCount 显示稳定？注意这些隐性因素：
GDI 对象（
HBITMAP、HDC）和 USER 对象（HWND、HMENU）不计入GetProcessHandleCount返回值，它们由 GDI/USER 子系统单独计数，需用GetGuiResources分别查GR_GDIOBJECTS和GR_USEROBJECTSC 运行时文件句柄（
FILE*）底层可能复用同一个 Windows HANDLE，也可能由 CRT 自己缓存管理，不一一对应第三方库（如 OpenSSL、libcurl）内部可能持有长生命周期句柄，且未暴露关闭接口
用 Process Explorer（Sysinternals）按 “Handle” 列排序，看具体句柄类型分布，比纯数字更有诊断价值
如果看到大量
ALPC Port或Section，往往是 IPC 或内存映射未正确释放
监控句柄不是只看总数，得拆解类型、归属模块、生命周期——否则永远在数字和代码之间来回猜。
