直接调用GetProcessHandleCount是最轻量可靠方式，返回当前进程内核对象句柄的实际引用总数，无需权限，适合高频采样；注意仅对本进程有效，失败时返回0且需用GetLastError判断原因。
Windows 下怎么拿到当前进程的句柄总数？
直接调用 GetProcessHandleCount 是最轻量、最可靠的方式，它返回的是当前进程内核对象句柄的**实际引用数**（不是句柄表长度，也不是最大值）。这个 API 不需要额外权限，也不依赖 WMI 或性能计数器，适合高频采样。
注意：该函数只对**本进程有效**，传入其他进程句柄会失败（ERROR_INVALID_HANDLE）。若要监控其他进程，必须先用 OpenProcess 获取其句柄，并确保有 PROCESS_QUERY_INFORMATION 权限。
-
GetProcessHandleCount返回值是DWORD，不是BOOL；失败时返回 0，但需配合GetLastError()判断是否真失败 - 在 Windows Server 系统或低权限沙箱中，部分进程可能因策略限制无法查询自身句柄数（极少见，但
GetLastError()会返回ERROR_ACCESS_DENIED） - 该值每秒波动几次属正常，持续单向增长大概率存在句柄泄漏
如何跨进程获取任意 PID 的句柄总数？
必须组合使用 OpenProcess + GetProcessHandleCount。关键点在于权限和错误处理——很多教程忽略 OpenProcess 失败的真实原因。
典型错误现象：OpenProcess 返回 NULL，但 GetLastError() 是 ERROR_ACCESS_DENIED，而非 ERROR_INVALID_PARAMETER。这意味着你没拿到足够权限，而不是 PID 不存在。
- 启动监控程序时，建议以管理员身份运行，或在 manifest 中声明
requireAdministrator - 目标进程若为系统保护进程（如
svchost.exe、csrss.exe），即使管理员权限也可能被拒绝，此时应跳过并记录警告 - 不要缓存
OpenProcess返回的句柄——每次统计都应重新打开再关闭，避免句柄泄漏本身干扰监控结果
句柄数突增但没泄漏？可能是内核对象生命周期导致的误报
Windows 内核对象（如 Event、Mutex、File）的句柄引用数不等于对象数量。一个对象可被多个句柄引用，而句柄关闭后对象未必立即销毁（比如还有其他进程持有时）。
常见干扰场景：
- 线程池大量创建
WaitForMultipleObjects所需的等待句柄，短时间激增后快速回落 - 第三方 DLL（如某些杀软、录屏工具）注入后临时申请大量
Section或Key句柄 - 使用
CreateFileMapping+MapViewOfFile时，每个映射视图都会新增句柄，但底层物理内存只有一份
建议搭配 Process Explorer 的句柄视图人工抽样验证：按类型排序，看是否某类句柄（如 ALPC Port、Key）持续累积。
生产环境部署要注意的三个硬限制
高频轮询（如 100ms 一次）在多进程监控场景下容易触发系统瓶颈，不是代码写得不对，而是 Windows 内核接口本身的开销叠加所致。
-
GetProcessHandleCount单次调用约消耗 1–3μs，但若遍历 200 个进程，每秒就是 200×10 次 = 2000 次调用，CPU 时间不可忽略 - WOW64 进程（32 位）调用该函数时，在 64 位系统上会有额外上下文切换开销，实测比原生 64 位进程慢 30%～50%
- 某些安全软件会 Hook
NtQueryInformationProcess（GetProcessHandleCount底层所用），导致延迟毛刺甚至超时，建议加 50ms 超时重试逻辑，而非直接报错退出
真正难的不是读出数字，而是区分「瞬时抖动」「合理增长」和「泄漏信号」——这需要结合历史趋势、进程行为上下文、以及对象类型分布来交叉判断。没有纯自动方案能绕过这点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
