最准确方式是调用NtQuerySystemInformation获取系统句柄表快照并统计条目数，推荐使用SystemHandleInformationEx（Win10 1809+），需启用SE_DEBUG_PRIVILEGE权限、正确处理缓冲区长度与结构对齐；若仅监控本进程，GetProcessHandleCount更轻量安全。
Windows平台下用NtQuerySystemInformation获取句柄总数
Windows内核并未向用户态直接暴露“当前全局句柄数”这个单一数值，但可通过 NtQuerySystemInformation 查询系统句柄表快照，再统计条目数——这是最接近真实值、且被Process Explorer等工具采用的方式。
关键点在于：必须使用 SystemHandleInformation（旧版）或更稳定的 SystemHandleInformationEx（Win10 1809+），前者在部分64位系统上会因结构对齐问题导致读取崩溃；后者返回带进程ID的扩展结构，更安全。
- 需要
#include <winternl.h>并手动声明函数原型（NtQuerySystemInformation未导出在ntdll.lib中） - 调用前需启用
SE_DEBUG_PRIVILEGE权限，否则返回STATUS_ACCESS_DENIED - 返回缓冲区大小不确定，需先用0长度调用获取所需尺寸，再分配内存重试
- 句柄条目结构随系统版本变化，务必检查
NumberOfHandles字段而非盲目循环遍历缓冲区
绕过权限限制：用GetProcessHandleCount替代全局统计
若仅需评估本进程资源压力，GetProcessHandleCount 是轻量、无需特权的替代方案。它返回当前进程的句柄数（含文件、事件、互斥体等所有类型），精度足够用于泄漏检测或阈值告警。
注意它不等于 GetCurrentProcess() 的句柄表长度——Windows内部做了缓存与聚合，但数值稳定、开销极低（单次系统调用）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 返回值为
DWORD，值为0不表示无句柄（可能刚释放完） - 无法区分句柄类型，不能替代详细分析，但适合高频采样（如每秒轮询）
- 在沙箱或受限AppContainer进程中仍可正常调用
避免踩坑：NtQuerySystemInformation返回STATUS_INFO_LENGTH_MISMATCH的典型原因
这个错误几乎总是因为缓冲区长度预估不准或结构体对齐错误，而不是权限问题。
- 第一次调用传入
nullptr和0获取所需长度时，必须检查返回状态码是否为STATUS_INFO_LENGTH_MISMATCH，而非直接判断是否成功 - 分配缓冲区后，要确保按
SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX（推荐）对齐，而非简单malloc(size)—— 某些Windows版本要求8字节对齐 - 32位程序在64位系统上调用时，若未定义
_WIN32_WINNT≥ 0x0601，头文件可能误用旧结构体，导致读取越界 - 不要假设返回的句柄数组是连续的——
NumberOfHandles是有效条目数，不是缓冲区总长度
实际监控建议：组合使用 + 采样节制
全局句柄统计代价高（每次调用需遍历全系统句柄表），不适合高频轮询。生产环境应分层处理：
- 主线程每5–10秒调用一次
GetProcessHandleCount做趋势判断 - 当发现本进程句柄数异常上升（如1分钟内增长超500），再触发一次
NtQuerySystemInformation全局快照，定位是自身泄漏还是被其他进程拖累 - 记录句柄类型分布时，必须解析
ObjectTypeNumber并查表（如1=Event, 2=Section, 7=Mutex），不能硬编码字符串匹配 - 避免在DLL_PROCESS_ATTACH中初始化句柄监控——此时系统尚未完成加载，可能触发死锁或权限异常
真正难的不是拿到数字，而是区分这数字到底反映的是你的代码问题、第三方库行为，还是系统临时资源抖动。多一层上下文比多一次调用更有价值。
