Linux下获取当前进程线程总数最可靠方式是读取/proc/self/status的Threads:行，提取冒号后整数，该值由内核实时维护、包含主线程、无需权限且开销极小。
Linux下用/proc/pid/status解析线程数最可靠
直接读取 /proc/self/status 是获取当前进程线程数的最快方式，比调用系统API更轻量且无竞态。关键字段是 Threads: 行，它反映内核维护的实时线程计数。
- 用
std::ifstream打开/proc/self/status，逐行扫描以Threads:开头的行，提取后跟的整数 - 注意：该值包含主线程，所以“活跃线程总数”就是这个数字，不是额外加1
- 不要用
get_nprocs_conf()或sysconf(_SC_NPROCESSORS_ONLN)—— 那是CPU核心数，和线程数无关 - 在容器中运行时（如Docker），
/proc仍有效，但看到的是容器视角的线程视图，不是宿主机全局
Windows需用EnumProcesses + EnumProcessThreads组合查询
Windows没有单点接口返回“当前系统总线程数”，必须枚举所有进程再累加其线程数。这本身就会引入采样延迟和权限问题。
- 先调用
EnumProcesses()获取所有DWORD pid列表 - 对每个 pid 调用
OpenProcess(PROCESS_QUERY_INFORMATION, ...)，失败则跳过（常见于保护进程） - 对每个可打开进程调用
EnumProcessThreads()，返回线程句柄数组长度即为其线程数 - 累计时注意：
EnumProcessThreads在 Windows 10 1809+ 返回的是线程 ID 数组，长度就是线程数；旧系统需用GetProcessImageFileName辅助过滤无效项 - 该操作需要
SeDebugPrivilege权限，否则大量进程无法打开，统计严重偏低
跨平台统计无法替代瓶颈分析
线程总数只是毛指标，高线程数不等于瓶颈，低线程数也不代表无压力。真正卡顿往往来自锁争用、I/O阻塞或调度延迟，而非数量本身。
- Linux下用
pidstat -t -p <pid></pid>查看各线程CPU/等待时间分布，比总数更有价值 - Windows可用
perfmon监控Thread\% Processor Time和Thread\Wait Reason，识别睡眠型线程（如Executive或Unknown等待态） - C++程序内部做瓶颈定位，优先打点
std::this_thread::get_id()+clock_gettime(CLOCK_MONOTONIC, ...)测单线程耗时，而不是依赖全局线程数 - 避免把
std::thread::hardware_concurrency()当作“应有线程数”——它只是逻辑核心数提示，与实际负载无关
std::thread 构造失败时线程数统计会失真
当 std::thread 构造抛出 std::system_error（常见错误码 resource_unavailable_try_again），说明内核已拒绝创建新线程，此时你看到的“活跃线程数”其实是上限被触达后的静态快照，不是真实负载反映。
立即学习“C++免费学习笔记（深入）”；
- 这种失败通常对应
/proc/sys/kernel/threads-max或 cgroup 的pids.max被耗尽，而非内存不足 - 检查是否漏掉
join()或detach()导致线程对象析构时资源未释放，引发泄漏式增长 - 用
cat /proc/<pid>/status | grep -i threads</pid>对比程序内统计值，若持续差1–2个，大概率是 RAII 管理疏漏 - 不要在循环里无节制
new std::thread(...)—— 即使没抛异常，也会快速填满线程栈空间（默认 8MB/线程）
