Linux下线程数应通过/proc/[pid]/status的Threads:字段读取，而非ps或/proc/[pid]/stat第22字段；统计系统总数需遍历/proc/[0-9]*/status累加；perf stat可分析调度与锁竞争，结合/proc/[pid]/stack和strace定位真实瓶颈。
Linux下用/proc/[pid]/status和/proc/[pid]/stat读取线程数
Linux内核把每个线程都视作一个轻量级进程（LWP），其数量直接体现在/proc/[pid]/status的Threads:字段里。你不需要自己遍历线程ID，更不用调用pthread_*系列函数——那些只对当前进程可见，无法反映系统全局状态。
实操建议：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
cat /proc/self/status | grep Threads快速验证当前进程线程数 - 要统计整个系统活跃线程总数，需遍历
/proc/[0-9]*/目录下的所有status文件，提取Threads:值并累加（注意跳过不存在或无权限的目录） - 避免用
ps -eLf | wc -l——它会重复计数（每个线程一行，但ps本身也开线程），且受ps实现细节影响，结果不稳定 -
/proc/[pid]/stat第22字段是num_threads，语义同status中的Threads:，但需按空格分割，易出错，优先选status
用perf stat定位CPU调度瓶颈和锁竞争
线程数多不等于性能差，关键看它们是否在争抢资源。单纯统计数字没意义，必须结合运行时行为分析。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对目标进程运行
perf stat -e 'sched:sched_switch,sched:sched_stat_sleep,sched:sched_stat_blocked,syscalls:sys_enter_futex' -p [pid]，重点关注sched_stat_blocked（被阻塞时间）和syscalls:sys_enter_futex（futex调用频次） - 若
sched_stat_blocked占比超过10%，说明线程频繁等待；若futex调用远高于系统调用总数，大概率存在锁粒度太粗或自旋锁滥用 - 别依赖
top的%CPU列判断——它显示的是单核利用率均值，掩盖了线程在不同CPU间抖动、缓存失效等问题 - 用
perf record -e 'sched:sched_migrate_task' -p [pid]可捕获线程跨CPU迁移事件，迁移频繁往往意味着负载不均衡或亲和性配置缺失
C++代码中获取本进程线程数的可靠方式
标准C++不提供跨平台获取线程总数的API，std::thread::hardware_concurrency()返回的是逻辑核数，不是当前活跃线程数。Linux下最稳的方式仍是读/proc/self/status。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要用
pthread_active_np()——它是glibc非标准扩展，musl libc不支持，且已标记为deprecated - 不要尝试
std::this_thread::get_id()配合容器记录——无法覆盖第三方库创建的线程，也无法感知被std::thread对象析构但尚未退出的线程 - 示例代码片段：
std::ifstream f("/proc/self/status"); std::string line; while (std::getline(f, line)) { if (line.rfind("Threads:", 0) == 0) { return std::stoi(line.substr(8)); } } - Windows下需用
EnumProcessThreads（需Psapi.h）+GetThreadCount，但返回值包含系统线程，实际业务线程数仍需过滤
线程数暴涨时的典型误判与排查路径
看到线程数飙升，第一反应不该是“加机器”或“重构”，而是确认是否真有竞争——很多场景下线程只是挂起等待I/O，并不消耗CPU。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先跑
cat /proc/[pid]/stack，看是否有大量线程卡在do_wait、ep_poll或futex_wait_queue_me，前者是正常I/O等待，后者才是锁竞争 - 检查
/proc/[pid]/fd/数量是否同步激增——若线程数和文件描述符数同比例增长，极可能是连接泄漏（如HTTP客户端未close）而非锁问题 - 用
strace -p [pid] -e trace=clone,futex,read,write观察系统调用分布，如果clone调用密集但futex极少，说明是线程创建失控，不是锁瓶颈 - 注意
ulimit -u限制：线程数超限会导致clone()失败并返回EAGAIN，应用可能静默降级或反复重试，形成恶性循环
