在CentOS运维中遇到进程假死或CPU飙升时，pstack是最直接、最轻量的调用栈分析工具。它本质上是gdb的一个非交互批处理脚本，通过attach到目标进程并打印每条线程的函数调用栈，让你快速定位死锁、阻塞或资源竞争的代码位置。实际操作就是一行命令：pstack [进程PID]，输出结果会列出所有线程的堆栈帧，你只需要从最底层的系统调用往上看，找到阻塞点所在的函数即可。下面我从安装、使用、分析技巧到实战案例，把这套方法讲透。
一、pstack是什么，为什么选它而不是其他工具
pstack的原理非常简单：它内部调用gdb -batch -ex 'thread apply all bt'命令，对目标进程的每个线程做一次backtrace，然后把结果格式化输出到标准输出或文件。它不需要你手动进入gdb交互界面，不需要重启进程，不需要额外编译带调试符号的版本（虽然有符号信息会更好），对生产环境的侵入性极低。相比strace只能看系统调用、ltrace只能看库调用，pstack给你的是完整的用户态函数调用链，这在排查死锁时是不可替代的。
二、CentOS上安装pstack及前置依赖
CentOS 7/8/9默认不一定自带pstack，你需要确认gdb已经安装。执行以下命令检查和安装：
# 检查gdb是否存在 which gdb # 如果没有，yum或dnf安装 yum install -y gdb # 验证pstack是否可用（gdb安装后通常自带） pstack --version
注意，pstack脚本通常位于/usr/bin/pstack，它是gdb包的一部分。如果你的系统是最小化安装，gdb可能缺失，务必先装好gdb。另外，如果你的程序编译时没有带-g调试信息，pstack输出的函数名会显示为十六进制地址，这时候你需要用addr2line或objdump配合二进制文件来反解析。
三、pstack基本用法和输出解读
最基本的用法就是指定进程ID：
pstack 12345
输出格式大致如下：
Thread 1 (process 12345): #0 0x00007f3a2c1d2f4d in poll () from /lib64/libc.so.6 #1 0x0000000000402a1b in event_base_loop () #2 0x0000000000401f56 in main () ... Thread 2 (process 12345): #0 0x00007f3a2c2b8e7d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000403c88 in worker_thread_func () #2 0x00007f3a2c2b26ba in start_thread () from /lib64/libpthread.so.0 #3 0x00007f3a2c1d841d in clone () from /lib64/libc.so.6
解读要点：#0是最底层的栈帧（当前正在执行的函数），数字越大越靠近调用链顶部。看到pthread_cond_wait说明这个线程在等条件变量，如果多个线程都卡在这里，大概率是死锁或资源饥饿。看到poll/epoll_wait说明在等I/O事件。看到futex或sem_wait说明在等锁或信号量。
四、如何用pstack定位死锁的具体方法
死锁的本质是多个线程互相持有对方需要的锁，形成环形等待。用pstack排查的核心思路是：找到所有线程的调用栈，看它们分别卡在哪个锁函数上，然后交叉比对。
第一步，获取进程所有线程的调用栈并保存：
pstack <PID> > /tmp/stack_dump_$(date +%s).txt
第二步，如果进程有多个线程（用ps -T -p PID或top -H查看），pstack会自动列出每个线程。你需要逐一查看每个线程卡在哪里。典型的死锁场景：线程A卡在pthread_mutex_lock等待mutex_X，而线程B卡在pthread_mutex_lock等待mutex_Y，同时线程A持有mutex_Y、线程B持有mutex_X。
第三步，结合代码定位。如果你的程序有调试符号，pstack会直接显示函数名和源码行号。如果没有，你需要用以下方式反解析：
# 用addr2line解析单个地址 addr2line -e /path/to/binary 0x0000000000403c88 # 或者用gdb批量解析 gdb -batch -ex 'info line *0x0000000000403c88' /path/to/binary
第四步，如果pstack输出太长，可以用grep过滤关键信息：
pstack <PID> | grep -E "mutex_lock|cond_wait|futex|sem_wait"
这一步能快速把所有线程的阻塞点筛选出来，节省大量阅读时间。
五、pstack的进阶技巧和注意事项
技巧一：对核心转储文件分析。如果进程已经崩溃生成了core文件，可以用pstack分析core：
pstack <PID> /path/to/core
技巧二：持续监控。如果你想观察进程调用栈随时间的变化，可以写个简单的循环脚本：
#!/bin/bash
PID=$1
INTERVAL=5
while true; do
echo "=== $(date) ===" >> /tmp/pstack_monitor.log
pstack $PID >> /tmp/pstack_monitor.log
sleep $INTERVAL
done
技巧三：权限问题。pstack需要ptrace权限，默认情况下普通用户只能attach自己的进程。如果要分析其他用户的进程，需要以root运行，或者设置/proc/sys/kernel/yama/ptrace_scope为0（CentOS 7上是1，CentOS 8/9上是1，改为0允许跨用户ptrace）。
注意事项：pstack会短暂暂停目标进程（attach和detach的瞬间），在高并发场景下可能造成微秒级的延迟，但通常不影响业务。如果进程对延迟极其敏感，建议先在测试环境验证。另外，pstack只能看到用户态栈，如果死锁发生在内核态（比如内核锁竞争），需要配合/proc/PID/stack或perf、SystemTap等工具。
六、实战案例：一个多线程程序的死锁排查
假设你在CentOS上运行一个C++多线程服务，突然发现进程CPU占用正常但请求全部超时。用top -H看到有4个线程都处于D状态（不可中断睡眠）。执行：
ps -ef | grep myservice pstack <PID>
输出显示：
Thread 1: #0 pthread_mutex_lock Thread 2: #0 pthread_mutex_lock Thread 3: #0 pthread_mutex_lock Thread 4: #0 pthread_mutex_lock
四个线程全部卡在mutex_lock上。进一步用addr2line解析地址，发现线程1和线程2卡在同一个锁函数db_connection_pool::get_conn()，线程3和线程4卡在另一个锁函数config_manager::reload()。查看代码发现：get_conn()内部先拿db_lock再拿config_lock，而reload()先拿config_lock再拿db_lock，经典的ABBA死锁。修复方案就是统一加锁顺序，或者用std::lock一次性获取两把锁。
七、pstack与其他工具的配合使用
pstack不是万能的，它适合快速定位，但要深入分析还需要配合其他工具。比如用pstack找到阻塞函数后，用perf record -p PID -g记录采样数据，可以看到哪个函数消耗CPU最多。用ltrace -p PID可以看动态库调用。用strace -p PID可以看系统调用。三者结合，从用户态函数到内核态系统调用形成完整链路。对于Java进程，可以用jstack替代pstack；对于Python进程，可以用py-spy或faulthandler。
总结一下，pstack在CentOS运维中是排查进程假死和死锁的第一选择工具。它轻量、快速、侵入性小，一行命令就能拿到所有线程的调用栈。关键是你要会解读输出、会用addr2line反解析地址、会用grep过滤关键信息。把这些基本功练扎实，遇到生产环境的进程问题就能在几分钟内定位到代码层面，而不是盲目重启或者猜原因。
