用pstack查高CPU线程调用栈：先用top -H -p PID定位高耗CPU的十进制TID，再执行pstack PID | grep -A 10 "LWP TID"聚焦该线程栈，栈顶函数如epoll_wait通常阻塞不占CPU，若高频出现或伴随高CPU则需排查空轮询、锁竞争或死循环。
怎么用 pstack 查高 CPU 线程的调用栈
pstack 本身不区分线程优先级，它只是把进程里所有线程的当前调用栈一次性打出来。关键在于你得先知道哪个线程在吃 CPU，再从一堆输出里精准定位它。pstack 11466 输出里每段以 Thread N (Thread 0x... (LWP 11699)): 开头，其中 LWP 11699 就是线程 ID（TID），和 top -H 看到的十进制 TID 一致。
实操建议：
- 别直接人眼扫全量输出，用
pstack 11466 | grep -A 10 "LWP 11699"快速聚焦目标线程附近 10 行 - 如果想交互式浏览，
pstack 11466 | vim -进入后按/LWP 11699搜索，比 grep 更灵活 - 注意：pstack 需要进程属主或 root 权限运行；若提示
No symbol table，说明二进制被 strip 过，函数名会变成地址，无法直接读
为什么 top -H 找到的 TID 要和 pstack 里的 LWP 对上
Linux 内核中，线程本质是轻量级进程（Light Weight Process, LWP），top -H 显示的“PID”列实际就是 LWP ID，和 pstack 输出里括号中的 LWP XXX 完全对应。不是线程名、不是 pthread_t、也不是十六进制 ID —— 就是那个十进制整数。
常见误区：
立即学习“C++免费学习笔记（深入）”；
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 误把
ps -T -p PID输出的TID列当十六进制用：它也是十进制，不用转换 - 在 gdb 里用
thread 11699切换时，gdb 接受的也是十进制 TID，和 pstack 一致 - 某些监控工具显示的“线程 ID”可能是 pthread_t（地址值），不能直接用于 pstack 匹配
看到调用栈顶是 epoll_wait 或 futex 就代表没问题？
不一定。epoll_wait、poll、futex、sem_wait 这类函数出现在栈顶，只说明线程当前阻塞在系统调用上 —— 正常情况下它们不占 CPU。但如果这些函数频繁返回又立刻重入（比如空轮询），或者卡在 futex 上不动但 %CPU 很高，就可能暴露问题：比如锁竞争激烈导致线程反复抢锁失败、事件循环没做超时控制、或日志刷屏引发 vfprintf 占满 CPU。
重点关注：
- 栈顶是不是计算密集型函数（如矩阵运算、加密、正则匹配）
- 有没有明显死循环痕迹（如连续几帧都是同一函数内某行，且无系统调用）
- 是否在用户态反复调用 usleep/sleep(0)/nanosleep，这类“伪等待”实际持续占用 CPU
pstack 和 jstack 的根本区别在哪
pstack 是基于 gdb 的封装脚本，走的是 ptrace 系统调用，直接读进程内存和符号表，只要进程活着、没 strip、权限够，就能拿到原生函数名和调用链。jstack 则依赖 JVM 的调试接口（JVM TI），必须启动时加 -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics 等参数才可能生效，且只能看到 Java 方法栈，看不到 JNI 层或底层 C 函数。
所以遇到混合服务（比如用 JNI 调 C++ 库的 Java 进程），pstack 能穿透到 C++ 层，jstack 只能看到 Java 层 —— 这时候高 CPU 真正在 C++ 侧，jstack 就会漏掉关键信息。
真正难的不是执行那几条命令，而是从几十个线程的堆栈里识别出「看起来正常、实则异常」的模式：比如所有线程都停在 std::mutex::lock() 下一层的 futex，但只有一个线程在 std::mutex::unlock() 后没释放——这种细节，得对照源码和业务逻辑才能断定，pstack 只负责把现场摊开给你看。
