Windows 下最可靠方式是调用未公开的 NtQuerySystemInformation（SystemHandleInformation 类型），需手动加载 ntdll.dll、提升 SeDebugPrivilege 权限、循环分配缓冲区并按指针大小适配结构体；Linux 下直接读 /proc/sys/fs/file-nr 首列即可，无需权限且实时准确。
Windows 下用 NtQuerySystemInformation 查句柄总数最可靠
直接调用 Win32 API 没有现成函数返回“全系统句柄总数”，GetProcessHandleCount 只能查本进程，而任务管理器里显示的“句柄数”实际来自内核对象计数器——得走 NT 内部接口。NtQuerySystemInformation 是唯一稳定获取该值的方式，但要注意它不是公开导出函数，需手动从 ntdll.dll 加载。
常见错误是试图用 EnumProcesses + 逐个开句柄再累加，这既慢又不准（权限不足时跳过进程，且无法统计内核线程/设备对象等非进程句柄）。
- 必须用
SystemHandleInformation类型（值为 16），不能错用SystemHandleInformationEx（Win11+ 才支持，旧系统会失败） - 缓冲区要足够大：首次调用会返回所需大小，需循环重试分配；硬写 64KB 容易在高负载机器上截断
- 返回结构体
SYSTEM_HANDLE_INFORMATION在不同 Windows 版本中字段偏移不一致，务必用sizeof(void*) == 8判断是否为 64 位布局 - 调用前建议提升进程令牌权限：
SeDebugPrivilege，否则可能漏掉系统进程句柄（如svchost的某些句柄会不可见）
Linux 下读 /proc/sys/fs/file-nr 是最快路径
Linux 不叫“句柄”而叫“文件描述符”，但监控目标一致。全系统已分配的 fd 总数就藏在 /proc/sys/fs/file-nr 第一个数字里，无需 root 权限，也不依赖任何库。
注意别误读 /proc/sys/fs/file-max（这是上限值），也别去遍历 /proc/[pid]/fd/ 目录求和（太慢，且会漏掉未打开 fd 的进程、或被 ptrace 阻塞的进程）。
立即学习“C++免费学习笔记（深入）”；
-
/proc/sys/fs/file-nr输出三列：已分配 fd 数｜未使用 fd 数｜file-max 上限 - 第一列就是你要的实时总数，用
std::ifstream读取后按空格分割即可，不用解析整行 - 该文件是内核实时更新的 procfs 接口，无缓存、无延迟，比
lsof | wc -l快两个数量级 - 如果程序运行在容器中，该值反映的是宿主机全局状态，不是容器 cgroup 限制值；如需容器内视角，应读
/sys/fs/cgroup/pids/.../pids.current配合 fd 计算，但那是另一套逻辑
C++ 跨平台封装要注意的陷阱
想写一个 get_total_handles() 函数同时支持 Windows/Linux？别用宏开关拼接两套逻辑——编译期分支会导致链接时符号缺失（比如 Linux 编译却链接了 ntdll.lib）。更稳妥的是运行时检测 OS，或拆成独立源文件 + 条件编译单元。
- Windows 版本必须用
decltype(&NtQuerySystemInformation)声明函数指针类型，不能直接 typedef，否则 x64/x86 调用约定不匹配会 crash - Linux 版本不要用
popen("cat /proc/...")，fork 开子进程有性能开销，且信号处理不当会导致父进程卡住 - 返回值统一用
int64_t：Windows 句柄数可能超 2^31（尤其服务器长期运行），Linux 的 file-nr 也可能达千万级 - 不要缓存结果：该值每秒可变化数百次，监控场景下必须每次调用都真实读取
为什么 PerfMon 或 Process Explorer 显示值和你算的不一样
工具之间数值差异几乎必然存在，不是代码写错了。根本原因是采样时机和统计口径不同：PerfMon 的 Objects\Handles 计数器是内核对象管理器的快照，含所有对象头（包括未被进程引用的临时对象）；而 NtQuerySystemInformation 返回的是当前有效句柄表项数，不含已标记删除但尚未释放的对象。
- Process Explorer 默认只显示“用户模式可见句柄”，过滤掉了内核驱动创建的 DeviceObject、SymbolicLink 等句柄
- 如果你在服务进程中调用，且该服务以
LocalSystem身份运行，可能看到更多句柄（比如注册表 hive 句柄），普通用户进程则看不到 - 某些安全软件会 hook 句柄操作，在
NtDuplicateObject或NtClose时插入额外引用，导致计数虚高
真正在意精确性时，优先信 NtQuerySystemInformation 或 /proc/sys/fs/file-nr 的原始输出，其他工具仅作趋势参考。监控报警阈值建议留 10% 余量，避免因统计抖动误触发。
