Linux下获取当前进程线程总数最可靠方式是读取/proc/self/status的Threads:行，该字段由内核实时维护，格式为“Threads: N”，提取冒号后整数即可，精度高、开销小、无需权限。
Linux 下用 /proc/self/status 读取线程数最可靠
Linux 内核会把当前进程的线程总数实时写在 /proc/self/status 的 Threads: 行里，这是用户态能拿到的最轻量、最准确的统计方式。不依赖 glibc 版本，也不需要遍历 /proc/self/task/ 目录——后者在高并发场景下可能因目录项过多而变慢或失败。
实操建议：
- 用
std::ifstream打开/proc/self/status，逐行读取直到匹配到以"Threads:"开头的行 - 注意该行格式固定为
Threads: 12（冒号后有空格+数字），用std::stoi提取时跳过空白即可 - 不要用
system("ps -T -p $$ | wc -l")类方案：启动新进程开销大，且ps输出格式可能随版本变化，不可靠
Windows 下必须调用 GetProcessId + EnumProcesses 吗？
不是。Windows 没有直接暴露“当前进程线程数”的 API，但可以绕过全局枚举——用 GetCurrentProcess() 获取伪句柄，再调用 GetProcessTimes() 或 GetProcessInformation() 都拿不到线程计数。真正可行的是 GetProcessHandleCount()，但它统计的是句柄数，不是线程数。
唯一稳定路径是 EnumThreadsWithCallback()（Windows 10 1809+）或传统 CreateToolhelp32Snapshot(..., TH32CS_SNAPTHREAD)：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
TH32CS_SNAPTHREAD快照包含系统所有线程，需用threadEntry.th32OwnerProcessID == GetCurrentProcessId()过滤 - 注意
THREADENTRY32结构体必须初始化dwSize字段，否则Thread32First返回失败 - 不要在多线程环境里反复调用快照接口：它会短暂挂起目标进程，频繁调用可能引发性能抖动
跨平台封装时为什么不能用 std::thread::hardware_concurrency()
std::thread::hardware_concurrency() 返回的是逻辑 CPU 核心数（即 sysconf(_SC_NPROCESSORS_ONLN) 或 Windows 的 GetSystemInfo().dwNumberOfProcessors），和当前活跃线程数完全无关。它既不反映线程创建数量，也不含任何运行时状态信息。
常见误用场景：
- 想监控线程泄漏，却用它做 baseline 对比 → 实际值可能远大于或小于该返回值
- 在日志里打印 “max threads:
hardware_concurrency()” 误导运维认为这是上限 → 系统可创建线程数受/proc/sys/kernel/threads-max和内存限制 - 某些旧版 libstdc++ 返回 0，导致逻辑分支异常，必须加判空
注意 getrusage(RUSAGE_SELF, &ru) 的 ru.ru_nthreads 字段
这个字段看似理想，但实际几乎不可用：glibc 从 2.26 开始就废弃了对它的更新，内核也从未在 struct rusage 中填充该字段。POSIX 标准本身未定义 ru_nthreads，Linux man page 明确标注 “not implemented”。尝试读取只会得到 0 或随机值。
验证方法很简单：
- 写个死循环创建
std::thread，每秒调用一次getrusage - 观察
ru.ru_nthreads是否变化 → 实测始终为 0（x86_64, kernel 6.5+, glibc 2.39） - 改用
/proc/self/status对比，立刻看到数值同步增长
真正在意线程数的场景，Linux 就认 /proc/self/status，Windows 就走 TH32CS_SNAPTHREAD，别被名字带偏。系统接口的语义比函数名重要得多。
