Windows需用NtQuerySystemInformation(SystemExtendedHandleInformation)获取系统句柄总数，需SeDebugPrivilege权限且字段版本差异大；Linux直接读/proc/sys/fs/file-nr首字段即可得fd总数，无需root权限。
Windows平台用NtQuerySystemInformation获取句柄总数
Windows内核并不直接暴露“全局句柄数”给用户态API，GetProcessHandleCount只返回**当前进程**的句柄数，不是系统级统计。真正能拿到全系统句柄总数的，是未公开但稳定可用的NT内核接口NtQuerySystemInformation，配合SystemHandleInformation（即0x10）类别。
实际使用时需注意：该调用需要SeDebugPrivilege权限，普通用户态进程默认没有；返回结构体SYSTEM_HANDLE_INFORMATION在不同Windows版本中字段偏移不一致（Win10 22H2起引入SYSTEM_HANDLE_INFORMATION_EX），直接硬编码解析极易崩溃。
实操建议：
- 调用前必须通过
OpenProcessToken+AdjustTokenPrivileges启用SE_DEBUG_NAME权限 - 优先尝试
SystemExtendedHandleInformation（0x40），它返回带长度头的SYSTEM_HANDLE_INFORMATION_EX，字段更稳定 - 不要假设
NumberOfHandles字段永远在结构体开头——应先调用一次获取所需缓冲区大小，再分配内存重试 - 返回的句柄条目是按对象地址排序的，不含进程/线程名，仅含
UniqueProcessId、HandleValue、ObjectTypeIndex等基础字段
Linux下用/proc/sys/fs/file-nr实时读取打开文件总数
Linux没有“句柄”概念，但file descriptor是其等价资源。系统级总数由内核维护在/proc/sys/fs/file-nr，它是一行三个数字：已分配FD数 未使用FD数 最大允许FD数。第一项就是当前所有进程打开的fd总数（含重复打开同一文件的多个fd）。
立即学习“C++免费学习笔记（深入）”；
这个值比遍历/proc/[pid]/fd/快两个数量级，且无需root权限——因为它是只读内核接口。
实操建议：
- 用
std::ifstream或fopen读取/proc/sys/fs/file-nr，解析首字段即可，例如"98765 0 1048576"→ 当前系统共打开98765个fd - 不要混淆
/proc/sys/fs/file-max（系统上限）和file-nr第一列（当前使用量） - 该数值包含所有进程的fd，也包括内核内部使用的（如socket、eventfd等），但不包括已
close()但尚未被回收的fd（处于TIME_WAIT等状态的socket仍计入） - 若需精确到进程粒度，必须走
/proc/[pid]/fd/目录计数，但性能差、需遍历全部PID，且可能因权限缺失跳过某些进程
C++跨平台封装要注意的兼容性断点
没有真正的跨平台句柄总数API。Windows依赖NTDLL私有函数，Linux依赖procfs伪文件系统，macOS则只能靠sysctl查kern.maxfiles和kern.num_files（后者仅表示内核文件结构体用量，不等于fd总数）。
这意味着任何“跨平台资源监控库”若声称提供统一句柄总数接口，背后必然是条件编译+平台特化实现，无法避免。
实操建议：
- 在CMake中用
if(WIN32)/if(APPLE)/if(UNIX AND NOT APPLE)分发不同源文件，不要试图用宏抽象成一个函数 - Windows侧务必链接
ntdll.lib并用GetProcAddress动态加载NtQuerySystemInformation，避免静态链接导致UWP或沙箱环境崩溃 - Linux侧不要依赖
libprocps等第三方库去读/proc——直接read系统调用或std::ifstream更轻量、无依赖 - macOS上
sysctlbyname("kern.num_files", ...)返回的是vnode/file结构体分配数，不是fd数，两者不等价；真要统计fd得用lsof -n | wc -l这类外部命令（不推荐用于高频监控）
高频轮询句柄总数的性能与精度陷阱
每秒多次调用句柄总数接口看似无害，实则暗藏问题：Windows的NtQuerySystemInformation(SystemExtendedHandleInformation)在句柄数超10万时单次调用可能耗时数毫秒；Linux的/proc/sys/fs/file-nr虽快，但内核更新该值本身有延迟（通常100ms级），并非严格实时。
更关键的是：句柄总数本身是个弱一致性指标——它不反映泄漏，只反映瞬时快照。一个进程疯狂open/close，总数不变，但可能已触发ulimit限制或内存碎片。
实操建议：
- 监控频率建议控制在5–30秒一次，除非你明确在做故障复现分析
- 不要把“总数上升”直接等同于“句柄泄漏”——需结合单进程句柄增长趋势、
lsof或handle.exe定位具体对象类型（如Event、Section、Key） - Windows下若发现总数异常高（>50万），优先检查是否有进程未正确关闭
FindFirstFile返回的INVALID_HANDLE_VALUE，这类句柄不会出现在SystemHandleInformation中，但会计入总数 - Linux下注意
file-nr第二列（未使用fd）长期为0，说明内核fd slab已满，新open()可能失败，此时总数未必高，但系统已临界
句柄总数只是系统资源水位的一个粗粒度信号，真正定位问题还得回到进程自身句柄生命周期管理——接口能读到的，永远不如代码里close()的位置重要。
