pstack仅对R/S状态进程有效，需满足权限、gdb可用、符号完整三条件；否则报Permission denied、Cannot attach或显示??()。
pstack 能直接看堆栈，但不是万能的——它只对 R/S 状态进程有效，且必须满足权限、gdb、符号三要素，否则输出残缺或直接失败。
为什么 pstack 一执行就报 Permission denied 或 Cannot attach to process
根本原因是 pstack 底层调用 gdb attach 进程，而 Linux 内核通过 ptrace 机制限制谁可以 attach 谁。常见卡点有：
- 目标进程不是当前用户启动的，且你没用
sudo（Permission denied） - 进程状态是
D（不可中断睡眠），比如正卡在磁盘 I/O 或 NFS 挂载点上（Cannot attach to process），此时ps -o pid,comm,state -p <pid></pid>可验证 -
/proc/sys/kernel/yama/ptrace_scope值为1（Ubuntu/Debian 默认），普通用户无法 attach 非子进程；临时放开：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope - 系统没装
gdb：command not found: gdb或pstack报错提示找不到调试器，需先装：sudo apt install gdb（Debian/Ubuntu）或sudo yum install gdb（RHEL/CentOS）
pstack 输出里全是 ??() 或十六进制地址，怎么让它显示函数名和行号
这说明二进制缺少调试符号，pstack 只能回溯到汇编层级。修复方式取决于你是否控制编译过程：
- 自己编译的 C/C++ 程序：加
-g参数，例如gcc -g -O2 server.c -o server - 系统库（如 libc、libpthread）缺失符号：安装对应 debuginfo 包，例如 CentOS 上装
glibc-debuginfo，Ubuntu 上装libc6-dbg - 用
file命令确认符号是否存在：file /proc/<pid>/exe</pid>—— 若输出含stripped，说明符号已被移除，pstack无法恢复 - 注意：Go/Java/Rust 等语言的运行时栈，
pstack效果差；Go 用kill -SIGUSR1 <pid></pid>，Java 用jstack <pid></pid>
多线程程序中，怎么从 pstack 输出快速定位卡点
pstack <pid></pid> 默认打印所有线程堆栈，每组以 Thread N (LWP XXXX): 开头。关键不是“全看”，而是聚焦异常模式：
- 看哪些线程长期停在系统调用：如
epoll_wait、pthread_cond_wait、nanosleep—— 属正常等待；但若大量线程都卡在__lll_lock_wait或futex，大概率是锁竞争或死锁 - 对比多次采样：用
for i in {1..5}; do pstack <pid> >> trace.log; sleep 2; done</pid>，再用grep "#0" trace.log | sort | uniq -c | sort -nr找高频栈顶行 - 关注重复出现的源码位置：比如连续 3 次都停在
server.c:88，那行代码就是第一怀疑对象 - 别被线程数吓住：主线程标为
[stack]，子线程是[stack:tid]，但pstack不依赖 /proc/maps，它靠 gdb 解析运行时栈帧，所以只要进程活着、可 attach，就能抓
替代方案：当 pstack 失效时该用什么
不是所有场景都适合 pstack。以下情况应切换工具：
- 进程是
D状态：用cat /proc/<pid>/stack</pid>（仅限内核线程或部分支持的用户态线程），或结合iotop、vmstat 1判断 I/O 卡点 - 需要系统调用级追踪：用
strace -p <pid> -e trace=epoll_wait,read,write</pid>，比堆栈更贴近实际阻塞点 - 要深度调试逻辑：用
gdb -p <pid></pid>，然后info threads+thread apply all bt，比pstack多出寄存器、局部变量等上下文 - 容器环境或无 gdb 权限：用
gcore <pid></pid>生成 core 文件，再本地用gdb ./binary core.xxx分析，规避线上环境限制
真正难的不是执行 pstack，而是读懂它省略了什么——比如它不告诉你内存是否耗尽、文件描述符是否打满、或者某个 mutex 是否被意外销毁。堆栈只是快照，得结合 ps、/proc/<pid>/status</pid>、lsof -p <pid></pid> 一起看，才能拼出完整现场。
