最可靠方法是读取/proc/self/status的Threads字段；Linux下直接解析该字段，Windows需枚举进程并调用GetThreadCount，跨平台不可依赖std::thread::hardware_concurrency()等静态接口。
Linux下用/proc/self/status读取当前进程线程数最可靠
直接读/proc/self/status比调用pthread_active()或std::thread::hardware_concurrency()更准确——后者返回的是硬件逻辑核数或未定义行为，不是实际活跃线程数。关键字段是Threads:行，例如：
Threads: 17注意：该数值包含主线程和所有
pthread_create()创建的线程（含std::thread），但不包括内核线程或已分离且已退出但尚未被join()的僵尸线程。
- 用
std::ifstream打开/proc/self/status，逐行读取并匹配以"Threads:"开头的行 - 避免用
system("ps -T -p $$ | wc -l")——启动子进程开销大，且结果可能多算标题行 - 在容器中运行时，
/proc仍有效，但需确保挂载了procfs（绝大多数容器默认启用）
用perf stat定位线程级资源竞争瓶颈
perf stat比top -H或htop更能暴露真实竞争点：它统计的是CPU周期、缓存未命中、分支预测失败等底层事件，而非仅看CPU占用率。对多线程程序运行perf stat -e 'cycles,instructions,cache-misses,branch-misses' -t <pid></pid>，重点关注cache-misses占比超过10%或branch-misses显著升高，往往意味着线程间存在伪共享（false sharing）或锁争用。
- 加
-t参数才能按线程（LWP）粒度统计，否则只汇总整个进程 -
cache-misses高但instructions低 → 内存带宽/延迟瓶颈，检查是否频繁访问不同线程修改的同一缓存行 - 避免用
perf record -e sched:sched_switch分析调度延迟——数据量过大，难定位具体锁点
检测互斥锁争用必须看futex系统调用耗时
Linux中std::mutex、pthread_mutex_t底层依赖futex系统调用。当多个线程反复尝试获取同一把锁，futex会从用户态快速路径退回到内核态等待，带来明显延迟。用perf trace -e 'syscalls:sys_enter_futex' -t <pid></pid>可捕获所有futex调用，并观察timeout非零或val为1（表示FUTEX_WAIT）的高频出现——这就是锁争用信号。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
futex调用本身不慢，但频繁进入FUTEX_WAIT状态说明线程在空转或阻塞等待 - 配合
perf script输出时间戳，计算相邻FUTEX_WAIT到FUTEX_WAKE的间隔，若常超100μs，基本确认存在竞争瓶颈 -
std::shared_mutex读多写少场景下，futex争用可能出现在写端，别只盯着写线程
避免误判：getrusage(RUSAGE_THREAD)不能替代线程数统计
getrusage(RUSAGE_THREAD, &ru)返回的是**单个线程**的资源使用情况（如用户态时间、页错误数），不是线程总数。试图用它遍历所有线程来累加，既不可行（无法枚举线程ID），也无意义——RUSAGE_THREAD在glibc中仅对调用线程有效，传入其他线程ID会失败并置errno = ESRCH。真正需要线程总数时，坚持走/proc/self/status；需要各线程资源分布，用perf按LWP采样更稳妥。
立即学习“C++免费学习笔记（深入）”；
-
getrusage(RUSAGE_SELF)统计整个进程，但无法拆分到线程粒度 - 某些旧内核或musl libc环境下
/proc/self/status的Threads:字段可能缺失，此时应fallback到scandir("/proc/self/task", ...)计数目录项 - 跨平台需求强时，Windows对应方案是
EnumThreads+GetThreadTimes，但Linux仍是主力场景
perf stat的cache-misses和futex等待时间一起看。很多人只扫一眼线程数就断言“线程太多”，结果发现瓶颈其实在一个慢SQL或磁盘I/O上。 
