Linux进程CPU打满但strace无高频系统调用，说明热点在用户态；需用top -H、pstack/gstack定位线程及卡点，perf record结合火焰图下钻至源码行，注意编译优化与运行时环境干扰。
Linux进程CPU打满，但strace看不到高频系统调用，说明热点在用户态——比如死循环、密集计算或低效算法。这类问题不会卡在read/write/epoll_wait等系统调用上，所以strace“失明”，必须换工具深入函数内部。
先锁定高占用线程
用top -H -p PID查看该进程所有线程，按P排序，记下%CPU最高的TID（十进制）。再执行：
- ps -mo pid,tid,%cpu,comm -p PID ——交叉验证TID和占用率
- cat /proc/PID/stat ——连续采样几秒，看第14字段（utime）是否猛增；若大幅增长，确认是用户态代码在跑飞
抓堆栈看执行位置
pstack或gstack能直接暴露线程当前卡在哪一行代码：
- gstack PID | grep -A10 "tid [TID]"（TID填你记下的十进制数）
- 多执行2–3次（间隔0.5秒），如果总停在同一个函数内（如while(1)、for(;;)、memcpy循环体），基本就是源头
- 若堆栈里频繁出现__nanosleep或pthread_cond_wait，说明线程在等待，不是忙循环，应查锁或条件变量逻辑
用perf定位到具体行号
堆栈只告诉你函数名？perf可以下钻到源码行（需编译时带-g）：
- perf record -g -p PID sleep 10 ——采集10秒调用链样本
- perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > cpu.svg
- 打开SVG，最宽的函数块就是真实热点；点击可展开看到具体.c或.cpp文件及行号
- 常见真凶：正则回溯爆炸、JSON反复解析、未加break的switch fallthrough、无退出条件的for循环
别忽略编译与环境线索
有些“卡死”是优化器制造的假象：
- 确认是否用了-O2或更高优化等级：某些边界失效的循环可能被编译成紧凑跳转，pstack看起来像卡在一行不动
- 检查是否启用了-funroll-loops或-ffast-math等激进选项，它们可能放大数值计算开销
- 运行时确认是否误设了LD_PRELOAD或自定义malloc，某些内存分配器在高并发下会引发隐式自旋
