GetProcessHandleCount仅获取当前进程句柄引用总数，非唯一句柄数；全系统句柄总数需NtQuerySystemInformation（高开销、需特权）或PDH累加各进程Handle Count（跨版本稳妥）；Linux无全局句柄概念，用/proc/sys/fs/file-nr第一列或遍历/proc/[pid]/fd近似。
Windows平台用 GetProcessHandleCount 获取当前进程句柄数
这个函数最直接，但只返回**当前进程**的句柄总数（不是全系统），且仅限 Windows。它不依赖 WMI 或性能计数器，开销极低，适合高频采样。
调用前需注意：GetProcessHandleCount 返回的是当前进程内核对象句柄的引用计数总和（含重复引用），不是唯一句柄个数。例如一个文件句柄被 dup() 两次，会算作 3 次引用。
- 必须传入当前进程的有效句柄，推荐用
GetCurrentProcess() - 返回值为
BOOL，结果通过输出参数lpHandleCount返回（类型PDWORD） - 在 Windows Server 2003+ 和 Vista+ 上可用；XP SP3 也支持，但部分精简版可能阉割
DWORD count = 0;
if (GetProcessHandleCount(GetCurrentProcess(), &count)) {
printf("Current process handle count: %lu\n", count);
}
获取全系统句柄总数得靠 NtQuerySystemInformation + SystemHandleInformation
这是唯一能拿到整个系统所有进程句柄总数的原生方式，但代价高：需启用 SE_DEBUG_PRIVILEGE 权限、手动解析非文档化结构、触发内核态调用，且结果是快照而非实时流式数据。
关键风险点：
立即学习“C++免费学习笔记（深入）”；
-
SYSTEM_HANDLE_INFORMATION结构体在不同 Windows 版本中长度和字段顺序有差异（如 Win10 1903 后加了ObjectInfoClass字段），硬编码解析必崩 - 返回缓冲区大小不确定，需先用 0 大小试探，再重分配——但两次调用间句柄可能变化，第二次仍可能失败
- 即使成功，遍历全部句柄（常达数万）耗时毫秒级，不适合 sub-100ms 监控周期
建议仅用于诊断工具或低频巡检，不要塞进性能敏感路径。
更稳妥的跨版本方案：用 Performance Data Helper (PDH) 读取 \Processor(_Total)\% Processor Time 这类指标？不对——句柄数对应的是 Process(*)\Handle Count 计数器
PDH 是 Windows 官方推荐的轻量监控接口，无需特权，兼容性好（Win2000 起）。但要注意：它暴露的是每个进程的 Handle Count 实例，**没有“全系统总和”的预定义计数器**。
所以实际做法是枚举所有进程实例，累加：
- 先用
PdhEnumObjectItems查"Process"对象支持的计数器，确认"Handle Count"存在 - 用
PdhAddCounter为每个Process实例（如"Process(Idle)","Process(System)"…）添加句柄计数器 - 注意进程名带空格或特殊字符时，PDH 内部会转义（如
"svchost#1"），不能简单按名字拼接 - 首次调用
PdhCollectQueryData后需等待至少 1 秒再取值，否则返回PDH_INVALID_DATA
累加所有实例的 Handle Count 值，就是近似系统句柄总数。误差来自极短生命周期进程（启动即退出）未被采样到。
Linux 下没有“句柄总数”概念，但可通过 /proc/sys/fs/file-nr 和 /proc/[pid]/fd/ 接近目标
Linux 的资源抽象与 Windows 不同：它用统一的文件描述符（fd）机制管理各类资源，“句柄”不是内核一级概念。因此不存在全局句柄计数 API。
常用替代指标：
-
/proc/sys/fs/file-nr：三列数字，第二列是已分配但未使用的 fd 数，第三列是系统最大限制（fs.file-max）。第一列才是当前已使用 fd 总数——但它包含所有进程、内核线程、socket 等，且统计有轻微延迟 - 逐个读
/proc/[pid]/fd/目录项并计数：精确但开销大，ls /proc/[pid]/fd | wc -l在进程多时明显拖慢 - 用
lsof -n | wc -l：方便但依赖外部命令、解析文本、权限受限（普通用户看不到其他用户进程）
真正做资源监控时，应优先关注单进程 fd 使用率（cat /proc/self/limits | grep "Max open files"）、或 /proc/sys/fs/file-nr 第一列是否逼近第三列——这才是泄漏或耗尽的真实信号。
系统级句柄/文件描述符总数不是稳定指标，Windows 的 SystemHandleInformation 易崩，Linux 的 file-nr 是采样值。真要告警，盯住单进程增长趋势或阈值突破，比纠结“此刻总数多少”有用得多。
