Linux下C++多线程程序CPU占用100%怎么找原因-C++-PHP中文网

top -h 看不到多线程是因为程序实际未运行多个线程，可能因未调用 join()/detach() 导致线程未启动或异常退出；perf 显示 __lll_lock_wait 说明锁竞争严重；perf 热点在 libc 或 kernel 表明瓶颈在内存分配、系统调用或上下文切换；us 高但无明显热点则提示缓存或内存带宽瓶颈。

linux下c++多线程程序cpu占用100%怎么找原因

top -H 看不到线程？先确认进程是否真在跑多线程

很多 C++ 程序看似开了多个 std::thread，但实际只有一条线程在忙——比如主线程里写了个死循环，其余线程根本没启动或已退出。直接执行 top -H -p <pid></pid> 却只看到一个高占用 TID，大概率是这个原因。

验证方法：ps -L -p <pid> -o pid,tid,pcpu,comm</pid>。如果输出行数远少于你代码里 std::thread 的构造次数，说明线程没起来，或者启动后立刻异常退出（比如未捕获异常、std::thread 对象析构时未 join() 或 detach() 导致程序终止）。

检查线程构造后是否调用 join() 或 detach()；否则线程对象销毁会触发 std::terminate
加日志：在线程函数入口打点，确认是否真正进入执行
用 gdb -p <pid></pid> 后执行 info threads，看内核实际调度的线程数是否匹配预期

perf top 显示 __lll_lock_wait？锁竞争正在吃 CPU

当 perf top -p <pid></pid> 显示大量样本落在 __lll_lock_wait 或 pthread_mutex_lock，说明线程不是在干活，而是在等锁——典型锁竞争。此时 CPU 100% 是假象：线程频繁尝试获取锁失败，不断自旋/系统调用，消耗 CPU 却不推进业务逻辑。

这种场景下，top -H 会看到多个线程 TID 都有较高 %CPU，但它们的栈顶几乎全是锁函数，而不是你的业务函数。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

优先检查是否用了 std::mutex 在高频路径上（如每帧、每请求都 lock/unlock）
确认锁粒度：是不是整个大循环或大函数被一把锁包住，而非按数据分区细粒度加锁
避免在锁内做耗时操作（如 IO、网络调用、复杂计算）
考虑改用无锁结构（std::atomic、环形缓冲区）或读写锁（std::shared_mutex）

perf record -g 采样后 report 里全是 libc.so.6 或 kernel？别急着优化代码

如果 perf report -i perf.data 显示热点集中在 libc.so.6（如 memcpy、malloc、strlen）或 [kernel]（如 finish_task_switch、_raw_spin_lock），说明瓶颈不在你的业务逻辑，而在内存分配、系统调用或调度开销。

尤其注意：malloc 高占比往往意味着频繁小对象分配；memcpy 高占比可能是缓存不友好访问或冗余拷贝；finish_task_switch 高说明上下文切换太频繁——这通常由过多线程 + 锁争抢共同导致。