1. 从一次线上卡顿说起pstack 到底能帮你看到什么线上服务跑着跑着突然响应变慢CPU 不高、内存正常、日志也没报错重启一下又好了——这种“幽灵问题”大概是每个后端和运维同学都遇到过的噩梦。我第一次碰到这类问题时排查手段基本就是看日志、看监控、加打印折腾半天往往还是抓不到现场。后来一位做系统底层的朋友甩给我一条命令pstack pid几秒钟之后一个完整的线程调用栈就打印在终端里问题瞬间现形——某个线程卡在一把锁上另一个线程在等网络 IO主线程在等这个子线程返回。那一刻我才真正意识到pstack 这类栈回溯工具的价值不在于它能“修”问题而在于它能让你在问题发生的当下看清进程内部每个线程到底在干什么。这篇内容我想系统地把 pstack 讲透。它是什么、能做什么、适合谁用我先用一句话说清楚pstack 是一个用来打印指定进程当前所有线程调用栈的命令行工具主要服务于 C/C 程序、系统服务、后台守护进程的线上问题排查尤其是死锁、卡顿、CPU 飙高、进程假死这类“看不到日志”的场景。它特别适合后端开发、运维工程师、SRE、以及任何需要跟 Linux 进程打交道的技术人员。哪怕你平时写的是 Java、Go、Python只要你的服务底层跑在 Linux 上、依赖了 native 库pstack 一样能派上用场。不过要提前说明一点pstack 本身并不是一个“独立完整”的工具它更像是一个封装脚本底层依赖的是 gdbGNU 调试器或者系统自带的栈回溯能力。不同发行版上pstack这个名字背后指向的实现可能完全不同这也是很多人第一次用 pstack 会踩坑的根本原因。所以这篇“完整指南上”我会先把原理、环境、基础用法和核心排查场景讲清楚把那些文档里不会写的坑一次性摊开。2. 先搞懂原理pstack 为什么能“看穿”一个进程2.1 pstack 的本质是一个封装脚本很多人以为 pstack 是一个编译好的二进制程序其实不是。在绝大多数 Linux 发行版上你which pstack看到的往往是一个 shell 脚本内容大致是去调用 gdb然后执行thread apply all bt这类命令。也就是说pstack 的能力上限取决于它背后调用的调试器能力。这就解释了一个常见现象为什么有的机器上 pstack 输出很完整有的机器上却报错或者输出残缺。因为不同环境下脚本调用的后端不一样。有的发行版把它指向 gdb有的指向 eu-stackelfutils 套件里的工具还有的干脆没有预装需要你自己装。理解这一点非常关键后面所有的排查技巧都建立在这个认知之上。从原理层面讲一个进程在运行时每个线程都有自己的调用栈栈里保存着函数返回地址、局部变量、参数等信息。pstack 做的事情就是通过调试接口比如 ptrace 系统调用attach 到目标进程读取每个线程的栈内存再结合可执行文件和动态库里的符号信息把一串内存地址还原成人类可读的函数调用链。这就是为什么你看到的输出是一层一层的函数名而不是一堆十六进制地址。2.2 符号信息决定输出可读性的关键这里必须重点讲一个概念符号symbol。pstack 输出的可读性几乎完全取决于目标进程有没有带符号信息。如果程序编译时加了-g选项或者动态库里保留了符号表那么 pstack 就能把地址翻译成func_a - func_b - func_c这样的函数名反之你看到的可能就是一堆??或者纯地址。我见过太多人第一次用 pstack输出全是问号然后就说“这工具没用”。其实问题不在工具而在于发布版本把符号剥掉了strip。生产环境为了减小体积、保护代码通常会 strip 掉符号这时候 pstack 的输出就会大打折扣。解决办法有两个一是保留一份带符号的二进制文件排查时用gdb手动加载符号二是编译时保留一份独立的符号文件debuginfo需要时再关联上。这个细节后面在实操部分会详细展开。2.3 pstack 与其他栈工具的定位差异市面上能看调用栈的工具不止 pstack 一个常见的有 gdb、eu-stack、perf、以及各种语言自带的诊断工具。它们各有侧重我简单做个对比方便你选型工具核心特点适用场景主要限制pstack命令简单一键打印所有线程栈快速定位卡顿、死锁依赖后端调试器符号缺失时输出差gdb功能最全可交互调试深度分析、单步调试上手门槛高attach 有停顿eu-stack轻量对进程侵入小高频采样、生产环境需要额外安装 elfutilsperf性能采样开销低CPU 热点分析偏性能剖析非栈快照从这张表能看出来pstack 的定位是“快速、直观、低门槛”。它不追求功能全面而是让你在几分钟内对进程状态有个整体判断。真正复杂的问题还是要靠 gdb 深入。所以我的建议是pstack 作为第一响应工具快速判断问题方向确认方向后再用 gdb 精确定位。3. 环境准备别急着敲命令先把地基打牢3.1 确认你的 pstack 到底指向什么前面说了pstack 是个封装脚本所以第一步不是急着用而是先搞清楚它背后是什么。执行下面这条命令which pstack file $(which pstack) cat $(which pstack)如果file显示它是 shell script那就cat出来看看它调用了谁。常见的几种情况调用gdb、调用eu-stack、或者调用一个叫pstack的二进制。搞清楚这一点后面出问题才知道往哪个方向查。如果系统里根本没有 pstack也不用慌。它本质上就是一条 gdb 命令的封装你完全可以自己定义一个别名alias pstackgdb -q -nx -batch -ex thread apply all bt -p这样用的时候直接pstack pid就行。注意这里的几个参数-q安静模式、-nx不加载初始化文件、-batch批处理模式执行完就退出、-ex执行指定命令。这套参数组合是我实测下来最稳的避免了 gdb 加载一堆配置导致的干扰。3.2 安装必要的依赖如果机器上连 gdb 都没有那就得先装。不同发行版的包管理命令不一样我列一下常见的# Debian/Ubuntu 系 apt-get install -y gdb # RHEL/CentOS 系 yum install -y gdb # 如果想用 eu-stack 方案 apt-get install -y elfutils # 或 yum install -y elfutils这里有个经验生产环境装 gdb 要谨慎。gdb 体积不小而且 attach 进程时会让目标进程短暂停顿stop the world。对于延迟敏感的服务这个停顿可能是致命的。所以如果只是偶尔排查装一个没问题如果要做高频采样建议用 eu-stack它对进程的侵入更小。3.3 权限问题为什么你 attach 不上新手最常遇到的报错就是ptrace: Operation not permitted或者Could not attach to process。这几乎都是权限问题。Linux 出于安全考虑默认限制了普通用户 attach 其他用户的进程。解决办法有几个用 root 或 sudo 执行最简单但生产环境要谨慎调整/proc/sys/kernel/yama/ptrace_scope的值0 表示允许同用户 attach给目标进程和调试工具配置相同的用户权限我个人的习惯是排查时用 sudo但排查完立刻退出不做长期提权。另外要注意有些容器环境比如某些精简的容器镜像默认禁用了 ptrace这种情况下 pstack 是没法用的需要重新配置容器的安全策略。提示attach 一个进程时目标进程会被暂停。对于高并发服务这个暂停可能导致请求超时。所以尽量在低峰期操作或者用 eu-stack 这类侵入更小的工具。4. 基础用法与输出解读把一堆栈信息读成故事4.1 最基础的几条命令pstack 的用法简单到令人发指核心就一条pstack pid执行之后它会打印出该进程所有线程的调用栈。输出格式大致是这样Thread 3 (Thread 0x7f8a1c2d3700 (LWP 12345)): #0 0x00007f8a2b3c4e5d in poll () from /lib64/libc.so.6 #1 0x0000000000412a3b in wait_for_event () #2 0x0000000000413c2d in worker_loop () #3 0x00007f8a2b5a1e25 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f8a2b2d3bad in clone () from /lib64/libc.so.6每一段以Thread开头后面跟着线程 ID 和 LWP轻量级进程号。下面的#0 #1 #2...就是调用栈#0是当前正在执行的函数越往下越是调用它的上层函数。读栈的顺序是从下往上最底下是线程入口最上面是当前卡住的位置。如果只想看某个特定线程可以先用ps -T -p pid找到线程 ID然后针对性分析。不过大多数时候直接看全部线程反而更容易发现规律——比如一堆线程都卡在同一个函数上那基本就是那里有问题。4.2 读懂栈顶问题往往就在 #0排查问题的核心技巧就是看每个线程的#0帧。#0代表线程当前正在执行的代码位置它直接告诉你这个线程此刻在干什么。常见的几种情况#0在poll、epoll_wait、select线程在等 IO通常是正常的空闲等待#0在pthread_mutex_lock、futex_wait线程在等锁如果大量线程都卡在这很可能有死锁或锁竞争#0在read、write、recv线程在做 IO 操作如果长时间卡住可能是对端慢或网络问题#0在某个业务函数里线程在跑业务逻辑如果 CPU 高这里就是热点我一般会先扫一遍所有线程的#0把状态分类统计一下。如果发现 90% 的线程都卡在等锁那问题方向就很明确了。这种“先看全局再看局部”的思路比一上来就盯着某个线程看效率高得多。4.3 一个真实的排查案例说个我印象深刻的例子。某次一个后台服务响应时间突然从 50ms 涨到 3s监控显示 CPU 和内存都正常。我上去先pstack了一把输出里发现有个线程的栈是这样的Thread 8 (LWP 23456): #0 __lll_lock_wait () #1 pthread_mutex_lock () #2 update_shared_cache () #3 handle_request () ...而另一个线程的栈是Thread 12 (LWP 23460): #0 do_slow_io () #1 refresh_cache () #2 update_shared_cache () #3 handle_request () ...看出来了吗线程 12 持有锁去做慢 IO线程 8 在等这把锁。锁的粒度太粗把 IO 操作包在了临界区里导致所有请求都被拖慢。这个问题光看日志根本发现不了因为日志里只有“请求处理中”没有锁的信息。pstack 一出手问题直接现形。后来把 IO 操作挪到锁外面响应时间立刻恢复正常。这个案例说明一个道理pstack 最大的价值是让“不可见”的线程状态变得“可见”。日志记录的是业务逻辑的输入输出而 pstack 记录的是线程在操作系统层面的真实状态两者互补缺一不可。5. 核心排查场景死锁、卡顿、CPU 飙高怎么破5.1 死锁排查找那个“环”死锁是 pstack 最经典的应用场景。死锁的本质是两个或多个线程互相等待对方持有的锁形成循环等待。用 pstack 排查死锁核心就是找这个“环”。具体做法连续执行几次pstack pid间隔几秒。如果每次输出都一样说明进程状态是“冻结”的基本可以确定是死锁或长时间阻塞。然后重点看那些卡在pthread_mutex_lock、futex_wait上的线程顺着它们的栈往上找看它们各自在等什么锁、持有什么锁。不过要提醒一句pstack 只能告诉你线程卡在哪不能直接告诉你锁被谁持有。要精确定位锁的归属还得靠 gdb 进一步分析或者结合代码审查。但 pstack 能帮你快速缩小范围——如果发现线程 A 卡在锁 X 上线程 B 卡在锁 Y 上而代码里 X 和 Y 有交叉持有的可能那死锁的嫌疑就很大了。注意排查死锁时建议至少采样 3 次间隔 5 秒以上。如果栈完全不变才是真死锁如果栈在变那可能只是慢不是死。5.2 卡顿排查区分“等 IO”和“等锁”服务卡顿但没死这种情况比死锁更常见也更难查。pstack 在这里的作用是帮你区分卡顿的类型。我通常按下面的流程走先pstack一次看所有线程的#0分布如果大量线程卡在poll/epoll_wait说明在等 IO去看下游依赖是不是慢了如果大量线程卡在futex_wait说明在等锁去看是不是有热点锁竞争如果线程都在正常跑业务函数但响应就是慢那可能是 CPU 被抢占或单次处理逻辑太重这个分类过程非常关键因为它直接决定了你下一步往哪个方向查。我见过有人一看到卡顿就去查数据库结果发现是本地锁竞争白折腾半天。先用 pstack 定性再针对性定量这是效率最高的排查路径。5.3 CPU 飙高排查找到那个“忙”线程CPU 飙高和卡顿正好相反卡顿是线程在“等”CPU 高是线程在“忙”。排查 CPU 高pstack 要配合top -H一起用。流程是这样的# 第一步找到 CPU 最高的线程 top -H -p pid # 第二步把线程 ID 转成十六进制pstack 输出里是十六进制 printf %x\n tid # 第三步pstack 看这个线程在干什么 pstack pid | grep -A 20 十六进制tid这样就能精确定位到是哪个线程在烧 CPU以及它在执行什么函数。如果发现某个线程一直在某个循环里打转那基本就是死循环或者算法效率问题。我实测下来这套组合拳对付 CPU 飙高问题命中率非常高。不过有个细节要注意pstack 采样是瞬时的可能刚好采到线程在干别的事。所以对于 CPU 高的问题建议多采几次看哪个函数反复出现那才是真正的热点。5.4 进程假死排查看主线程在等谁进程假死不响应信号、不接受请求是另一种常见故障。这时候 pstack 的重点是看主线程的栈。主线程通常负责接收请求、分发任务如果它卡住了整个进程就“假死”了。我遇到过一次主线程卡在waitpid上等一个子进程退出但那个子进程自己又卡住了导致主线程永远等下去。这种问题用 pstack 一看主线程栈就明白了。所以排查假死第一件事就是找到主线程通常是 PID 等于进程 ID 的那个线程看它的#0在哪。6. 常见问题与避坑指南那些文档不会告诉你的事6.1 输出全是问号怎么办这是最高频的问题。原因前面讲过就是符号缺失。解决办法分几种情况如果是自己编译的程序重新编译时加-g并且不要 strip如果是第三方库安装对应的 debuginfo 包比如glibc-debuginfo如果生产环境不能带符号就保留一份带符号的版本排查时用 gdb 手动symbol-file加载我个人的做法是构建流水线里同时产出两个版本一个 strip 过的用于发布一个带符号的存档用于排查。这样既不增加生产体积又保证了排查能力。这个习惯帮我省了无数次事。6.2 attach 导致服务停顿怎么破前面提过gdb attach 会暂停进程。对于延迟敏感的服务这个停顿可能造成请求超时。缓解办法有几个用 eu-stack 替代 gdb它的侵入性更小在低峰期操作或者先摘除流量再排查控制采样频率不要连续高频 attach如果服务对延迟极其敏感我建议提前在测试环境复现问题而不是直接在生产上 attach。生产环境排查优先用对进程影响小的工具。6.3 容器环境下的特殊处理容器里用 pstack 有几个坑。第一很多精简镜像没装 gdb需要自己加。第二容器默认的 ptrace 权限可能被限制需要调整安全配置。第三容器里的 PID 和宿主机不一样排查时要注意区分。我的经验是如果要在容器里排查最好用带调试工具的镜像或者临时起一个 debug 容器通过共享进程命名空间的方式去 attach。这样既不污染生产镜像又能获得完整的排查能力。6.4 常见问题速查表问题现象可能原因解决方向输出全是??符号被 strip加载 debuginfo 或带符号版本attach 报权限错误ptrace 限制用 sudo 或调整 ptrace_scope输出为空后端工具缺失检查 pstack 脚本调用了什么进程卡住不动可能死锁多次采样对比栈是否变化采样后服务超时attach 停顿改用 eu-stack 或低峰操作容器内无法使用ptrace 被禁调整容器安全策略这张表是我这些年踩坑总结出来的基本覆盖了 90% 的常见问题。遇到问题先查表能省不少时间。7. 几个让我印象深刻的实操心得先说一个关于采样时机的经验。很多人排查问题喜欢“事后”去 pstack但那时候进程状态可能已经变了。最好的时机是问题正在发生时哪怕服务已经卡了只要进程还在pstack 就能抓到现场。所以我的建议是监控告警一响第一时间上去 pstack别等重启之后再查那时候什么都晚了。再说一个关于栈对比的技巧。单次 pstack 只能看到“此刻”但多次采样的对比才能看出“趋势”。比如你每隔 3 秒采一次采 5 次如果某个线程的栈一直不变那它就是在阻塞如果栈在缓慢变化那可能只是处理慢。这个“动态对比”的思路比单看一次快照有用得多。最后分享一个关于符号管理的小技巧。我习惯在构建时把符号文件单独存一份命名带上版本号和构建时间放到一个统一的归档目录。排查时只要知道服务版本就能立刻找到对应的符号文件。这个习惯看起来麻烦但真到排查紧急问题时能帮你节省大量时间。毕竟线上问题争分夺秒谁也不想在找符号文件上浪费时间。pstack 这个工具说简单也简单一条命令的事说深也深背后涉及调试器原理、符号管理、进程状态分析一大堆东西。这篇“上篇”先把基础打牢把原理、环境、用法和常见场景讲清楚。下一篇我会继续深入聊聊怎么结合 gdb 做更精细的分析、怎么处理多线程复杂场景、以及怎么把 pstack 集成到自动化排查流程里。如果你现在就想上手建议先在自己的测试环境里跑几个进程手动 pstack 几次把输出格式和读栈顺序练熟这比看再多文档都管用。 
长河君 · 2026/10/13 18:42:39 · 阅读 1.2k pstack 完整指南：从原理到实战的 Linux 进程栈回溯排查
1. 从一次线上卡顿说起pstack 到底能帮你看到什么线上服务跑着跑着突然响应变慢CPU 不高、内存正常、日志也没报错重启一下又好了——这种“幽灵问题”大概是每个后端和运维同学都遇到过的噩梦。我第一次碰到这类问题时排查手段基本就是看日志、看监控、加打印折腾半天往往还是抓不到现场。后来一位做系统底层的朋友甩给我一条命令pstack pid几秒钟之后一个完整的线程调用栈就打印在终端里问题瞬间现形——某个线程卡在一把锁上另一个线程在等网络 IO主线程在等这个子线程返回。那一刻我才真正意识到pstack 这类栈回溯工具的价值不在于它能“修”问题而在于它能让你在问题发生的当下看清进程内部每个线程到底在干什么。这篇内容我想系统地把 pstack 讲透。它是什么、能做什么、适合谁用我先用一句话说清楚pstack 是一个用来打印指定进程当前所有线程调用栈的命令行工具主要服务于 C/C 程序、系统服务、后台守护进程的线上问题排查尤其是死锁、卡顿、CPU 飙高、进程假死这类“看不到日志”的场景。它特别适合后端开发、运维工程师、SRE、以及任何需要跟 Linux 进程打交道的技术人员。哪怕你平时写的是 Java、Go、Python只要你的服务底层跑在 Linux 上、依赖了 native 库pstack 一样能派上用场。不过要提前说明一点pstack 本身并不是一个“独立完整”的工具它更像是一个封装脚本底层依赖的是 gdbGNU 调试器或者系统自带的栈回溯能力。不同发行版上pstack这个名字背后指向的实现可能完全不同这也是很多人第一次用 pstack 会踩坑的根本原因。所以这篇“完整指南上”我会先把原理、环境、基础用法和核心排查场景讲清楚把那些文档里不会写的坑一次性摊开。2. 先搞懂原理pstack 为什么能“看穿”一个进程2.1 pstack 的本质是一个封装脚本很多人以为 pstack 是一个编译好的二进制程序其实不是。在绝大多数 Linux 发行版上你which pstack看到的往往是一个 shell 脚本内容大致是去调用 gdb然后执行thread apply all bt这类命令。也就是说pstack 的能力上限取决于它背后调用的调试器能力。这就解释了一个常见现象为什么有的机器上 pstack 输出很完整有的机器上却报错或者输出残缺。因为不同环境下脚本调用的后端不一样。有的发行版把它指向 gdb有的指向 eu-stackelfutils 套件里的工具还有的干脆没有预装需要你自己装。理解这一点非常关键后面所有的排查技巧都建立在这个认知之上。从原理层面讲一个进程在运行时每个线程都有自己的调用栈栈里保存着函数返回地址、局部变量、参数等信息。pstack 做的事情就是通过调试接口比如 ptrace 系统调用attach 到目标进程读取每个线程的栈内存再结合可执行文件和动态库里的符号信息把一串内存地址还原成人类可读的函数调用链。这就是为什么你看到的输出是一层一层的函数名而不是一堆十六进制地址。2.2 符号信息决定输出可读性的关键这里必须重点讲一个概念符号symbol。pstack 输出的可读性几乎完全取决于目标进程有没有带符号信息。如果程序编译时加了-g选项或者动态库里保留了符号表那么 pstack 就能把地址翻译成func_a - func_b - func_c这样的函数名反之你看到的可能就是一堆??或者纯地址。我见过太多人第一次用 pstack输出全是问号然后就说“这工具没用”。其实问题不在工具而在于发布版本把符号剥掉了strip。生产环境为了减小体积、保护代码通常会 strip 掉符号这时候 pstack 的输出就会大打折扣。解决办法有两个一是保留一份带符号的二进制文件排查时用gdb手动加载符号二是编译时保留一份独立的符号文件debuginfo需要时再关联上。这个细节后面在实操部分会详细展开。2.3 pstack 与其他栈工具的定位差异市面上能看调用栈的工具不止 pstack 一个常见的有 gdb、eu-stack、perf、以及各种语言自带的诊断工具。它们各有侧重我简单做个对比方便你选型工具核心特点适用场景主要限制pstack命令简单一键打印所有线程栈快速定位卡顿、死锁依赖后端调试器符号缺失时输出差gdb功能最全可交互调试深度分析、单步调试上手门槛高attach 有停顿eu-stack轻量对进程侵入小高频采样、生产环境需要额外安装 elfutilsperf性能采样开销低CPU 热点分析偏性能剖析非栈快照从这张表能看出来pstack 的定位是“快速、直观、低门槛”。它不追求功能全面而是让你在几分钟内对进程状态有个整体判断。真正复杂的问题还是要靠 gdb 深入。所以我的建议是pstack 作为第一响应工具快速判断问题方向确认方向后再用 gdb 精确定位。3. 环境准备别急着敲命令先把地基打牢3.1 确认你的 pstack 到底指向什么前面说了pstack 是个封装脚本所以第一步不是急着用而是先搞清楚它背后是什么。执行下面这条命令which pstack file $(which pstack) cat $(which pstack)如果file显示它是 shell script那就cat出来看看它调用了谁。常见的几种情况调用gdb、调用eu-stack、或者调用一个叫pstack的二进制。搞清楚这一点后面出问题才知道往哪个方向查。如果系统里根本没有 pstack也不用慌。它本质上就是一条 gdb 命令的封装你完全可以自己定义一个别名alias pstackgdb -q -nx -batch -ex thread apply all bt -p这样用的时候直接pstack pid就行。注意这里的几个参数-q安静模式、-nx不加载初始化文件、-batch批处理模式执行完就退出、-ex执行指定命令。这套参数组合是我实测下来最稳的避免了 gdb 加载一堆配置导致的干扰。3.2 安装必要的依赖如果机器上连 gdb 都没有那就得先装。不同发行版的包管理命令不一样我列一下常见的# Debian/Ubuntu 系 apt-get install -y gdb # RHEL/CentOS 系 yum install -y gdb # 如果想用 eu-stack 方案 apt-get install -y elfutils # 或 yum install -y elfutils这里有个经验生产环境装 gdb 要谨慎。gdb 体积不小而且 attach 进程时会让目标进程短暂停顿stop the world。对于延迟敏感的服务这个停顿可能是致命的。所以如果只是偶尔排查装一个没问题如果要做高频采样建议用 eu-stack它对进程的侵入更小。3.3 权限问题为什么你 attach 不上新手最常遇到的报错就是ptrace: Operation not permitted或者Could not attach to process。这几乎都是权限问题。Linux 出于安全考虑默认限制了普通用户 attach 其他用户的进程。解决办法有几个用 root 或 sudo 执行最简单但生产环境要谨慎调整/proc/sys/kernel/yama/ptrace_scope的值0 表示允许同用户 attach给目标进程和调试工具配置相同的用户权限我个人的习惯是排查时用 sudo但排查完立刻退出不做长期提权。另外要注意有些容器环境比如某些精简的容器镜像默认禁用了 ptrace这种情况下 pstack 是没法用的需要重新配置容器的安全策略。提示attach 一个进程时目标进程会被暂停。对于高并发服务这个暂停可能导致请求超时。所以尽量在低峰期操作或者用 eu-stack 这类侵入更小的工具。4. 基础用法与输出解读把一堆栈信息读成故事4.1 最基础的几条命令pstack 的用法简单到令人发指核心就一条pstack pid执行之后它会打印出该进程所有线程的调用栈。输出格式大致是这样Thread 3 (Thread 0x7f8a1c2d3700 (LWP 12345)): #0 0x00007f8a2b3c4e5d in poll () from /lib64/libc.so.6 #1 0x0000000000412a3b in wait_for_event () #2 0x0000000000413c2d in worker_loop () #3 0x00007f8a2b5a1e25 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f8a2b2d3bad in clone () from /lib64/libc.so.6每一段以Thread开头后面跟着线程 ID 和 LWP轻量级进程号。下面的#0 #1 #2...就是调用栈#0是当前正在执行的函数越往下越是调用它的上层函数。读栈的顺序是从下往上最底下是线程入口最上面是当前卡住的位置。如果只想看某个特定线程可以先用ps -T -p pid找到线程 ID然后针对性分析。不过大多数时候直接看全部线程反而更容易发现规律——比如一堆线程都卡在同一个函数上那基本就是那里有问题。4.2 读懂栈顶问题往往就在 #0排查问题的核心技巧就是看每个线程的#0帧。#0代表线程当前正在执行的代码位置它直接告诉你这个线程此刻在干什么。常见的几种情况#0在poll、epoll_wait、select线程在等 IO通常是正常的空闲等待#0在pthread_mutex_lock、futex_wait线程在等锁如果大量线程都卡在这很可能有死锁或锁竞争#0在read、write、recv线程在做 IO 操作如果长时间卡住可能是对端慢或网络问题#0在某个业务函数里线程在跑业务逻辑如果 CPU 高这里就是热点我一般会先扫一遍所有线程的#0把状态分类统计一下。如果发现 90% 的线程都卡在等锁那问题方向就很明确了。这种“先看全局再看局部”的思路比一上来就盯着某个线程看效率高得多。4.3 一个真实的排查案例说个我印象深刻的例子。某次一个后台服务响应时间突然从 50ms 涨到 3s监控显示 CPU 和内存都正常。我上去先pstack了一把输出里发现有个线程的栈是这样的Thread 8 (LWP 23456): #0 __lll_lock_wait () #1 pthread_mutex_lock () #2 update_shared_cache () #3 handle_request () ...而另一个线程的栈是Thread 12 (LWP 23460): #0 do_slow_io () #1 refresh_cache () #2 update_shared_cache () #3 handle_request () ...看出来了吗线程 12 持有锁去做慢 IO线程 8 在等这把锁。锁的粒度太粗把 IO 操作包在了临界区里导致所有请求都被拖慢。这个问题光看日志根本发现不了因为日志里只有“请求处理中”没有锁的信息。pstack 一出手问题直接现形。后来把 IO 操作挪到锁外面响应时间立刻恢复正常。这个案例说明一个道理pstack 最大的价值是让“不可见”的线程状态变得“可见”。日志记录的是业务逻辑的输入输出而 pstack 记录的是线程在操作系统层面的真实状态两者互补缺一不可。5. 核心排查场景死锁、卡顿、CPU 飙高怎么破5.1 死锁排查找那个“环”死锁是 pstack 最经典的应用场景。死锁的本质是两个或多个线程互相等待对方持有的锁形成循环等待。用 pstack 排查死锁核心就是找这个“环”。具体做法连续执行几次pstack pid间隔几秒。如果每次输出都一样说明进程状态是“冻结”的基本可以确定是死锁或长时间阻塞。然后重点看那些卡在pthread_mutex_lock、futex_wait上的线程顺着它们的栈往上找看它们各自在等什么锁、持有什么锁。不过要提醒一句pstack 只能告诉你线程卡在哪不能直接告诉你锁被谁持有。要精确定位锁的归属还得靠 gdb 进一步分析或者结合代码审查。但 pstack 能帮你快速缩小范围——如果发现线程 A 卡在锁 X 上线程 B 卡在锁 Y 上而代码里 X 和 Y 有交叉持有的可能那死锁的嫌疑就很大了。注意排查死锁时建议至少采样 3 次间隔 5 秒以上。如果栈完全不变才是真死锁如果栈在变那可能只是慢不是死。5.2 卡顿排查区分“等 IO”和“等锁”服务卡顿但没死这种情况比死锁更常见也更难查。pstack 在这里的作用是帮你区分卡顿的类型。我通常按下面的流程走先pstack一次看所有线程的#0分布如果大量线程卡在poll/epoll_wait说明在等 IO去看下游依赖是不是慢了如果大量线程卡在futex_wait说明在等锁去看是不是有热点锁竞争如果线程都在正常跑业务函数但响应就是慢那可能是 CPU 被抢占或单次处理逻辑太重这个分类过程非常关键因为它直接决定了你下一步往哪个方向查。我见过有人一看到卡顿就去查数据库结果发现是本地锁竞争白折腾半天。先用 pstack 定性再针对性定量这是效率最高的排查路径。5.3 CPU 飙高排查找到那个“忙”线程CPU 飙高和卡顿正好相反卡顿是线程在“等”CPU 高是线程在“忙”。排查 CPU 高pstack 要配合top -H一起用。流程是这样的# 第一步找到 CPU 最高的线程 top -H -p pid # 第二步把线程 ID 转成十六进制pstack 输出里是十六进制 printf %x\n tid # 第三步pstack 看这个线程在干什么 pstack pid | grep -A 20 十六进制tid这样就能精确定位到是哪个线程在烧 CPU以及它在执行什么函数。如果发现某个线程一直在某个循环里打转那基本就是死循环或者算法效率问题。我实测下来这套组合拳对付 CPU 飙高问题命中率非常高。不过有个细节要注意pstack 采样是瞬时的可能刚好采到线程在干别的事。所以对于 CPU 高的问题建议多采几次看哪个函数反复出现那才是真正的热点。5.4 进程假死排查看主线程在等谁进程假死不响应信号、不接受请求是另一种常见故障。这时候 pstack 的重点是看主线程的栈。主线程通常负责接收请求、分发任务如果它卡住了整个进程就“假死”了。我遇到过一次主线程卡在waitpid上等一个子进程退出但那个子进程自己又卡住了导致主线程永远等下去。这种问题用 pstack 一看主线程栈就明白了。所以排查假死第一件事就是找到主线程通常是 PID 等于进程 ID 的那个线程看它的#0在哪。6. 常见问题与避坑指南那些文档不会告诉你的事6.1 输出全是问号怎么办这是最高频的问题。原因前面讲过就是符号缺失。解决办法分几种情况如果是自己编译的程序重新编译时加-g并且不要 strip如果是第三方库安装对应的 debuginfo 包比如glibc-debuginfo如果生产环境不能带符号就保留一份带符号的版本排查时用 gdb 手动symbol-file加载我个人的做法是构建流水线里同时产出两个版本一个 strip 过的用于发布一个带符号的存档用于排查。这样既不增加生产体积又保证了排查能力。这个习惯帮我省了无数次事。6.2 attach 导致服务停顿怎么破前面提过gdb attach 会暂停进程。对于延迟敏感的服务这个停顿可能造成请求超时。缓解办法有几个用 eu-stack 替代 gdb它的侵入性更小在低峰期操作或者先摘除流量再排查控制采样频率不要连续高频 attach如果服务对延迟极其敏感我建议提前在测试环境复现问题而不是直接在生产上 attach。生产环境排查优先用对进程影响小的工具。6.3 容器环境下的特殊处理容器里用 pstack 有几个坑。第一很多精简镜像没装 gdb需要自己加。第二容器默认的 ptrace 权限可能被限制需要调整安全配置。第三容器里的 PID 和宿主机不一样排查时要注意区分。我的经验是如果要在容器里排查最好用带调试工具的镜像或者临时起一个 debug 容器通过共享进程命名空间的方式去 attach。这样既不污染生产镜像又能获得完整的排查能力。6.4 常见问题速查表问题现象可能原因解决方向输出全是??符号被 strip加载 debuginfo 或带符号版本attach 报权限错误ptrace 限制用 sudo 或调整 ptrace_scope输出为空后端工具缺失检查 pstack 脚本调用了什么进程卡住不动可能死锁多次采样对比栈是否变化采样后服务超时attach 停顿改用 eu-stack 或低峰操作容器内无法使用ptrace 被禁调整容器安全策略这张表是我这些年踩坑总结出来的基本覆盖了 90% 的常见问题。遇到问题先查表能省不少时间。7. 几个让我印象深刻的实操心得先说一个关于采样时机的经验。很多人排查问题喜欢“事后”去 pstack但那时候进程状态可能已经变了。最好的时机是问题正在发生时哪怕服务已经卡了只要进程还在pstack 就能抓到现场。所以我的建议是监控告警一响第一时间上去 pstack别等重启之后再查那时候什么都晚了。再说一个关于栈对比的技巧。单次 pstack 只能看到“此刻”但多次采样的对比才能看出“趋势”。比如你每隔 3 秒采一次采 5 次如果某个线程的栈一直不变那它就是在阻塞如果栈在缓慢变化那可能只是处理慢。这个“动态对比”的思路比单看一次快照有用得多。最后分享一个关于符号管理的小技巧。我习惯在构建时把符号文件单独存一份命名带上版本号和构建时间放到一个统一的归档目录。排查时只要知道服务版本就能立刻找到对应的符号文件。这个习惯看起来麻烦但真到排查紧急问题时能帮你节省大量时间。毕竟线上问题争分夺秒谁也不想在找符号文件上浪费时间。pstack 这个工具说简单也简单一条命令的事说深也深背后涉及调试器原理、符号管理、进程状态分析一大堆东西。这篇“上篇”先把基础打牢把原理、环境、用法和常见场景讲清楚。下一篇我会继续深入聊聊怎么结合 gdb 做更精细的分析、怎么处理多线程复杂场景、以及怎么把 pstack 集成到自动化排查流程里。如果你现在就想上手建议先在自己的测试环境里跑几个进程手动 pstack 几次把输出格式和读栈顺序练熟这比看再多文档都管用。