CPU持续100%但strace无高频系统调用，说明是用户态忙循环或密集计算；需用top -H、ps、/proc/PID/stat确认线程级负载，pstack/gstack抓堆栈定位热点函数，perf record生成火焰图精确定位到源码行，并排查编译优化、自旋锁、JIT等环境因素。
当 top 显示 CPU 使用率持续 100%，但用 strace -p PID 跟踪却看不到高频、耗时的系统调用（比如没有大量 read/write/epoll_wait），说明问题大概率不在 I/O 等待或外设交互上，而是进程本身在用户态疯狂循环或密集计算——也就是“纯 CPU 型热点”，strace 对它基本“视而不见”，因为它不触发系统调用。
确认是否真为用户态忙循环
先排除干扰项，确保观察的是真实负载：
- 运行
top -H -p <PID>，看是单个线程还是多个线程占满 CPU；若只有一个线程长期 99%+，重点盯它 - 执行
ps -mo pid,tid,%cpu,comm -p <PID>，核对线程 ID（TID）和 CPU 占比，记下高占用线程的 TID - 用
cat /proc/<PID>/stat查第 14 字段（utime）和第 15 字段（stime），连续采样几秒，看 utime 是否飞速增长——大幅增长说明确实是用户态代码在狂跑
用 pstack 或 gstack 抓线程堆栈快照
strace 看不到的忙循环，在函数调用栈里往往一目了然。只要进程还在运行，就能快速抓取当前执行位置：
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 对高 CPU 线程 TID 执行：
pstack <TID>（或gstack <TID>），输出类似：#0 0x00007f8a1234abcd in some_heavy_loop () from /app/lib.so<br>#1 0x00007f8a1234cdef in process_frame () from /app/lib.so
- 多执行几次（间隔 0.5 秒），如果总停在同一个函数或循环体内（如
for(;;)、while(flag)），基本锁定热点函数 - 注意：若堆栈显示大量
__nanosleep或pthread_cond_wait，反而是正常等待，不是忙循环——此时应查锁或信号量逻辑
用 perf record 定位精确到行的热点代码
当堆栈只显示函数名，但不确定是函数哪一行在“空转”时，perf 是更准的探针：
- 采集 10 秒样本：
perf record -g -p <PID> sleep 10 - 生成火焰图：
perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > cpu-flame.svg - 打开 SVG 文件，宽度最宽的函数块就是实际消耗最多 CPU 的位置；点击可下钻到具体源码行（需带 debug 符号编译）
- 常见线索：某行
memcpy循环调用、JSON 解析反复 parse、正则表达式回溯爆炸、未加限流的重试逻辑等
检查编译与运行时环境特征
有些“无系统调用的 100%”其实是环境导致的伪忙循环：
- 确认是否启用了
-O2或更高优化等级：某些边界条件下的死循环可能被编译器优化成紧凑跳转，pstack看起来像卡在一行不动 - 检查是否误用了自旋锁（
pthread_spin_lock）且未配超时，尤其在单核虚拟机中极易表现为 100% 用户态且无系统调用 - 查看
/proc/<PID>/maps，确认热点函数所在模块是否为 JIT 编译产物（如 Java/Python/C#）；这类场景需配合对应语言的 profiler（如jstack+async-profiler）
