gstack 实战：Linux 进程假死、死锁与忙等的一线排查指南

凌晨一点被叫起来的时候，消息队列的消费进度已经原地不动快四十分钟了。进程还活着，端口在监听，日志也没有任何报错，业务却彻底停在那里。这是我处理线上问题时最讨厌的一类故障：表面一切正常，实际完全不干活。那晚我的第一步不是翻监控面板，也不是敲重启命令，而是找到那个 pid，执行了gstack <pid>。这篇文章想认真聊聊 gstack 这个命令——它是什么、怎么用、原理是什么、有哪些坑，以及我这两年里用它定位假死、死锁和忙等问题的完整思路。如果你也经常靠“重启大法”处理进程卡死，这篇应该能帮上忙。

1. 进程活着业务却卡死：先拍一张全线程栈快照

1.1 这类故障的信号其实都很像

“进程活着但业务卡死”的场景，在不同系统里反复出现，特征几乎没有变化：进程还在，端口还在，健康检查偶尔也能过，但请求就是不再被处理；或者处理速度从每秒几千掉到几乎为零；日志最后一条的时间永远停留在某个时刻，之后一片寂静。CPU 占用可能很低，内存也正常，磁盘 IO 也没打满，但业务就是不动了。

我见过不少同事在这种情况下会先去看监控、看中间件状态、看数据库连接池，绕一大圈回来发现所有外围组件都正常，问题还是出在进程自身。这时候真正能一击命中的手段只有两个方向：要么看当前线程到底停在哪，要么看它在频繁执行什么系统调用。前者就是线程栈快照，后者是 strace。而我的习惯是先用线程栈快照，也就是 gstack 或者等价的 pstack。

因为这种“活着但不干活”的状态，绝大多数都能归类为：线程在等锁、线程在等条件变量、线程在空转、线程在某段业务逻辑里死循环、线程阻塞在某个 IO 上。这五种情况里，四种都能直接从调用栈里看出来。所以问题的核心就变成一个动作：把当前所有线程的调用栈一次拍下来。

1.2 为什么不用 gdb 手动 attach，也不先用 strace

不少人有 gdb，但手动搞还挺麻烦。正经流程是gdb -p <pid>之后输入thread apply all bt，看完还要 detach。紧急时刻容易手忙脚乱，而且你只是想要一个结果，gdb 交互式界面反而碍事。当然你可以写gdb -q -batch -ex "thread apply all bt" -p <pid>，这其实就是 gstack 的封装逻辑，后面拆原理时细说。

strace 我一般不会在这种场景第一步就上。strace attach 到进程后，如果这个进程的系统调用非常频繁，输出会爆炸式增长，而且附加本身对目标进程的干扰相当可观。它适合在锁定“某个系统调用有问题”之后去做精细化追踪，不适合拿来做全局第一眼排查。相比之下，gstack 只需要目标进程被短暂挂起，输出是一份结构清晰的调用栈列表，信息密度高，干扰小，几秒钟就能拿到结论。

1.3 gstack 的定位：一根针，不是一把手术刀

gstack 不是调试器，不解决交互式调试问题；它也不是性能分析器，不能告诉你每个函数跑了多久。它做的事情非常单一：把当前进程中所有线程的调用栈打出来。但正是这种单一，让它成为线上应急工具箱里最顺手的东西——你不需要在故障时刻回忆一长串命令，也不用关心系统是什么语言写的（除了 JVM 进程，那个用 jstack 更好），只要给一个 pid，它就能把栈快照扔给你。

2. 三分钟跑通：安装、执行、读懂每一行栈帧

2.1 安装方式与工具确认

gstack 在多数 Linux 发行版里不是一个独立的大软件包，它通常跟着 gdb 走，或者放在 pstack 包里。以我常用的环境为例：

• RHEL/CentOS 系：yum install -y gdb或yum install -y pstack，装完用which gstack确认。很多系统上 pstack 包会同时带 pstack 和 gstack 两个文件。
• Debian/Ubuntu 系：先apt install -y gdb，装完检查which gstack；如果系统没有，再安装pstack包补充。不同版本略有差异，但都不难找到。

装完之后最优先的一步不是跑一个真实进程，而是看一眼 gstack 本体到底是什么：

cat $(which gstack)

如果你手头的 gstack 和我常见到的一样，你会发现它本质上是一个 bash 脚本，核心逻辑就只有几行。这个细节很关键，后面讲到原理时会展开。确认工具存在后，找一个测试进程，比如某个常驻服务，或者干脆自己起一个 sleep 进程试拍。

2.2 基本用法：gstack

gstack 的用法简单到你不太可能记错：

gstack 12345

其中 12345 就是目标进程的 pid，可以在top、ps -ef、或者系统里任何能看到进程信息的地方拿到。执行之后，输出会直接打到终端，每一段对应一个线程的调用栈。如果进程线程很多，输出会非常长，所以现场操作时我一般会重定向到文件再慢慢看：

gstack 12345 > /tmp/stack_$(date +%s).txt 2>&1

注意 2>&1 也要带，因为 gstack 的报错信息是通过标准错误输出的，不带的话报错会在终端里漏掉，而文件里只有成功抓到的栈。

2.3 输出解读：从栈顶到栈底

一次典型的 gstack 输出长这样：

Thread 5 (Thread 0x7f34d4bff700 (LWP 12345)): #0 0x00007f34d7f2c96d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f34d7f27e42 in _L_lock_903 () from /lib64/libpthread.so.0 #2 0x00007f34d7f293d8 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000405c22 in worker_thread (arg=0x7f34d4bf7f00) at worker.c:142 #4 0x00007f34d7f27541 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f34d7c55c7d in clone () from /lib64/libc.so.2 Thread 6 (Thread 0x7f34d4bfd700 (LWP 12346)): #0 0x00007f34d7f4d2dd in poll () from /lib64/libc.so.2 #1 0x0000000000406f10 in event_loop () at server.c:301 ...

读栈的起点是栈顶的#0。这个位置通常表示线程当前正在执行的系统调用或锁等待原语。比如第一个线程的#0是__lll_lock_wait，第二行#1是_L_lock_903，第三行#2是pthread_mutex_lock，这说明它卡在“尝试拿一把互斥锁”的路上，还没拿到。真正属于你程序业务逻辑的帧在#3往后，那才是判断“卡在哪个模块哪段代码”的关键。所以千万不要只盯着最上面一行系统库函数，要往下看到你自己的代码帧，比如这里的worker.c:142，那才是业务现场。

2.4 把 top -H 的线程号与 LWP 对上号

gstack 输出里每个线程都有一个 LWP 编号，比如上面例子里的 LWP 12345。这个编号直接对应操作系统线程 id（TID）。为什么这个对应关系重要？因为线上排查有一个高发场景：某个线程 CPU 直接打满，你想知道它到底在跑什么。

操作流程我建议这样走。先跑：

top -H -p 12345

-H会让 top 按线程维度显示，而不再只显示进程合计。这时候能看到这个进程内部每个线程的 CPU 占用，记下 CPU 最高的那个 TID，比如某个线程 TID 是 12350，然后去 gstack 输出里找 LWP 12350，对应的那一段栈就是这个高 CPU 线程正在执行的代码。这个动作在忙等问题排查中是必须的，否则全线程几十段栈放在一起，你根本不知道该看哪一段。

3. 原理拆解：它就是一个封装好的 GDB 批处理

3.1 核心逻辑用一个 bash 脚本说清楚

前面我提到 gstack 是脚本，那你直接看它的逻辑比看任何文档都直观。常见版本的 gstack 核心内容，剥掉各种检查之后大致就是这样的结构：

#!/bin/bash if [ $# -eq 0 ]; then echo "Usage: gstack <pid>" >&2 exit 1 fi if [ ! -r "/proc/$1" ]; then echo "Process $1 not found." >&2 exit 1 fi gdb -q -batch -ex "thread apply all bt" -p "$1"

对照这段脚本，gstack 做的事情就是三件：检查进程存在、调用 GDB、让 GDB 在非交互模式下把所有线程的 backtrace 打出来。-q是安静模式，去掉 GDB 启动时的版本信息和无用提示；-batch是关键，它让 GDB 执行完指定的命令后直接退出，不进入交互界面；-ex "thread apply all bt"表示“对所有线程应用 backtrace 命令”，也就是把每一个线程的调用栈都打印出来；-p "$1"指定要附加的进程。

所以你看，gstack 根本不是复杂工具，它只是把 GDB 最常用的一条批处理命令包了一层壳。理解了这一层，你以后再遇到“需要给指定线程下断点”或者“想看某个线程的局部变量”的场景，就会知道这时候 gstack 不够用，回到 GDB 手动操作才是正路。

3.2 thread apply all bt 背后发生了什么

当 gdb 收到-p <pid>时，它在内核层面做的是 ptrace 附加操作。这个操作会让目标进程的指定线程进入调试状态。接下来执行thread apply all bt，GDB 会遍历进程的所有线程，逐个读取寄存器和栈内存，从而还原出每一层的函数调用关系。栈帧怎么还原？核心是把每个线程的指令指针寄存器（PC/RIP）和栈基址寄存器（SP/RSP）拿出来，沿着栈内存不断向上回溯，通过调试信息把地址翻译成文件行号。这也是为什么你在栈里能看到worker.c:142这类行号——那是 DWARF 调试信息提供的，或者至少是符号表提供的函数名。

这个过程中目标进程会短暂停顿。线程越多、进程内存越大，GDB 需要读取的数据越多，暂停时间就越长。日常几百个线程的服务，往往一两秒就能完成；如果进程上千线程还要读全部线程栈，那就要数秒。这正是 gstack 这类工具的代价所在：用短暂停顿换取一份当前状态的完整快照。

3.3 gstack 和 pstack 的渊源

pstack 最早是 Solaris 上的原生命令，用来打印进程的调用栈。到了 Linux 世界，一直没有一个完全对等的官方工具，于是各种发行版和项目就分别推出了自己的实现。gstack 就是 GNU 阵营里基于 GDB 的实现思路；而很多发行版里的 pstack 其实也是类似脚本，只是在不同版本里可能单独提供一个更精简的二进制，内部同样走 GDB。所以在不少系统上，你执行pstack 12345和gstack 12345得到的结果几乎一模一样，因为它们本质是同一件事。

我个人的建议是：记住 gstack 这个命令就够了，因为它是基于 GDB 的，而 GDB 在所有主流 Linux 环境里都有；遇到 pstack 也能用，但别指望 pstack 在同一系统上一定存在。工具是表象，核心是“快速拿到全线程栈”的能力。

3.4 为什么 gstack 会产生“副作用”

这里要明确一点：gstack 不是一个零侵入工具。你在生产环境执行它的那一刻，目标进程会被提暂停。多数业务可以容忍一秒钟的停顿，但如果你在强实时系统、在线交易链路的中间环节上操作，就得评估这个停顿能不能接受。我见过一个案例：有人用 pstack 去拍一个几百线程、内存 20GB 以上的进程，光抓栈就花了六七秒，结果下游服务已经判定上游超时，直接把连接断掉了。工具本身没错，但使用时机和对象需要判断。这也是为什么我在后面会专门讲“什么时候不要用 gstack”。

4. 三类线上现场：条件等待、锁互持、忙等

4.1 全员停在条件变量：基本可以判定“真卡住”

有一次排查一个 C++ 服务，所有工作线程都停在栈顶的pthread_cond_wait或者futex_wait上。interrupt 线程在 event_loop 里等事件，工作线程全部在等任务队列的条件变量。这种栈形态非常典型：如果你连续拍两张都在同样位置，而且线程数没有波动，说明生产者侧没有产生新任务，或者任务循环被什么东西堵住了。顺着这个结论往上找外层业务代码，再配合日志和队列长度，通常很快能找到是任务下发链路彻底停掉了。

这种“全员等待”的栈，最关键的意义在于排除猜测。不用再去怀疑 CPU 不够、内存不足、GC 停顿，线程栈直接把答案钉在了“大家都在等”上。

4.2 锁互持死锁：两条线程互相等

锁互持死锁的栈形态同样很有辨识度。看两个线程的就够了：

Thread A: #0 __lll_lock_wait () #1 pthread_mutex_lock () #2 void do_task_a() at a.cpp:201 #3 worker_thread() at worker.cpp:88 Thread B: #0 __lll_lock_wait () #1 pthread_mutex_lock () #2 void do_task_b() at b.cpp:309 #3 worker_thread() at worker.cpp:88

如果线程 A 在 a.cpp:201 拿锁，线程 B 在 b.cpp:309 拿锁，而 A 持有的锁恰好是 B 正在等的那把，B 持有的锁又是 A 正在等的那把，这就构成了死锁环。单纯从一次快照里你未必能直接看到“谁持有哪把锁”，因为 GDB 的 bt 命令默认不打印锁的持有者。这时候我的做法是继续在 GDB 里执行thread apply all bt full，看局部变量中是否有 mutex 地址，再对比两个线程锁地址的交叉情况；或者直接看业务代码里加锁顺序是否一致。gstack 的价值在于让你第一时间知道“存在两个同时卡在锁等待的线程”，至于完整锁环，通常需要再深入一层。

4.3 单线程 CPU 打满：用连续采样抓忙等

还有一种场景是某个线程 CPU 打满，但 gstack 单拍却偶尔拍不到问题栈——因为那个线程可能在不断循环，循环体足够快，快照拍到的瞬间往往停在某个系统调用上，看起来像是“在等待”而不是“在空转”。面对这种情况，连续采样比单拍可靠得多。

我常用的一段循环采样脚本：

pid=<目标进程pid> for i in $(seq 1 30); do echo "===== sample $i at $(date '+%H:%M:%S.%N') =====" gstack "$pid" > "/tmp/stack_$(date +%s%N).txt" 2>&1 sleep 0.5 done

采样结束后，把所有样本放在一起按函数名聚合，看高 CPU 线程反复出现在哪些函数里：

grep -h "#[0-9]" /tmp/stack_*.txt \ | sed -E 's/.* in ([^ (]+).*/\1/' \ | sort | uniq -c | sort -nr | head -20

如果某个业务函数名出现的次数远远高于其他函数，那基本可以断言它就是忙等热点。这个“统计频率”的思路比单独看某一张快照要科学得多，因为线程是动态的，单张照片容易失真。

5. 踩过的坑：权限、容器、D 状态与健康检查

5.1 ptrace_scope 与普通用户的 Permission denied

gstack 最常见的失败场景就是附加权限不足。Linux 内核的 Yama 安全模块会限制 ptrace 行为，参数在/proc/sys/kernel/yama/ptrace_scope。默认值通常为 1，含义是：允许进程 attach 到它的直接子进程；再宽一点的值 0 表示完全放开；有些安全要求高的机器会设成 2 或 3，限制更严格。

如果你用普通账号执行gstack 12345，看到这类报错：

Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user.

那多半就是 Yama 在拦。解决办法按环境来：临时改成 0 再恢复：

echo 0 > /proc/sys/kernel/yama/ptrace_scope gstack 12345 echo 1 > /proc/sys/kernel/yama/ptrace_scope

或者直接用 root 执行。如果进程是别人启动的，你又没有 root，那 gstack 就是无能为力，只能联系负责人。还有一个小坑：如果目标进程已经被另一个调试器 attach 了，gstack 也会报ptrace: Operation not permitted，这种情况先排查是不是有别的 gdb 挂着。

5.2 容器内外看栈的正确姿势

容器环境的 pid 是两个不同的命名空间。你在宿主机上执行gstack 12345，12345 必须是对应宿主机视角的 pid；进入容器之后执行gstack 12345，则对应容器内 pid。这两个数字通常不一样。

我处理容器里服务卡死问题时的首选是：直接在宿主机上对宿主机 pid 拍栈。原因很简单，宿主机上大概率已经装了 gdb，而容器镜像出于精简考虑往往没有这些调试工具。从宿主机附加进程拿到的栈，内容和在容器内看到的基本一致，因为进程本身的用户态栈是同一份，只是你从哪个视角看的问题。如果这个进程开启了额外保护，比如容器运行时配置了 seccomp 策略限制 ptrace，那宿主机和容器内都可能会抓不到，这种情况先确认安全策略，不要强行绕过。

记住一个原则：gstack 需要的是 ptrace 权限，跟你在不在容器里没有必然关系，跟命名空间和内核安全策略才有关系。

5.3 D 状态进程：gstack 搞不定时的替代手段

如果进程处于 D 状态，也就是不可中断睡眠，gstack 大概率会失败或卡住。这种状态常见于线程在等待磁盘 IO、NFS 网络响应等场景。D 状态进程无法响应 ptrace 的信号，gdb 很难正常读取它的完整栈。此时我不会死磕 gstack，而是换一个更轻量的排查手段：

cat /proc/<pid>/wchan

这个文件会给出线程当前在内核里的等待点，比如某个文件系统函数、某个互斥锁等待点，信息量不大但非常直接。如果内核开了栈跟踪选项，还可以试着读/proc/<pid>/stack，但不少生产内核没开这个功能，读出来是空的。这时候看wchan再配合iostat、dmesg里的磁盘报错，往往能拼凑出完整原因。

5.4 暂停几秒的代价：小心健康检查误杀

gstack 附加会让进程暂停，而健康检查不会因为你在调试就停止探测。如果你的服务健康检查非常激进，比如每 3 秒探测一次，而 gstack 抓大进程栈需要好几秒，正好赶上探测窗口，系统就会把服务标记为故障，甚至触发自动重启或摘流量。我处理几十 GB 内存、上千线程的服务时，会先和团队确认是否可以接受几秒不可用，或者把流量摘掉再操作。这不是 gstack 的缺陷，是“任何 ptrace 调试工具共有的代价”，但新手最容易忽略。

6. 工具的边界：什么时候别碰 gstack

6.1 同类工具一句话对比

用到后面我自己会做这样的取舍判断，列个表直接看：

6.2 gstack 和 perf：一个是拍照，一个是录像

如果问题表现是“CPU 经常飙满但不确定热点在哪”，gstack 就不合适了，因为单张快照看不到函数耗时分布。正确选择是 perf：

perf record -F 99 -p <pid> -g -- sleep 10

它按 99Hz 的频率周期性采样调用栈，10 秒就能生成几千份栈样本，最后生成火焰图或perf report看热点函数占比。这才是性能分析的正确姿势。而 gstack 的定位始终是“某时某刻进程到底停在哪”，它是拍照，不是录像。把这两个工具的使用场景搞混，是很多排查陷入瓶颈的原因。

另一个变量是 Java 服务。你拿 gstack 去拍 JVM，输出里会有大量 GC 线程、JIT 编译器线程的原生栈，噪点巨大，阅读效率很低。JVM 进程的问题，直接上 jstack，Java 线程状态、锁等待、死锁检测都比 gstack 友好得多。这里不是 gstack 不行，而是用错了对象。

6.3 我的组合拳与一点实际体会

把上面的经验串成一套操作流程，我现在的习惯是这样的：碰到“进程活着但业务不动”，先top -H -p <pid>看线程层 CPU，然后立刻gstack拍栈；如果怀疑忙等或者偶发卡顿，用循环脚本连续拍 30 张再按函数聚合；如果 gstack 失败，转/proc/<pid>/wchan和系统日志；如果是 Java 进程，直接 jstack，不绕弯子。

最后分享一个对我帮助很大的细节：拍栈不要只拍一张，我会连续拍三张，间隔约半秒。如果三张里某个线程的栈几乎一模一样，那说明它确实卡死了；如果每次拍到的位置都在变，说明线程还在推进，问题大概率不在线程栈本身，而是外部条件没满足。这个“三次快照”的习惯，帮我避免过好几次误判。gstack 本身很简单，但把它用在对的时机、对的进程上，才是真正值钱的部分。