strace能定位死锁线程和锁地址，但不能直接指出哪行代码出问题；它只暴露“谁卡在哪个系统调用”，需结合ps查状态、pstack/gdb看栈、源码比对地址才能反推具体锁变量及上下文。
strace 能定位死锁线程和锁地址，但不能直接告诉你哪行代码出问题——它只暴露“谁卡在哪个系统调用”，后续得靠你对照源码反推。
strace -p 线程ID 卡住不动，先确认是不是真死锁
执行 strace -p 12345 后终端没输出，别急着 Ctrl+C：
- 先跑 ps -o pid,stat,comm -p 12345，看 STAT 列是否含 D（不可中断睡眠）——如果是，进程可能已卡在 I/O 或内核锁里，strace 只是同步阻塞；
- 如果 STAT 是 S 或 T，但 strace 仍无响应，大概率线程正阻塞在 futex、sem_wait 或 pthread_mutex_lock 上；
- 不要反复中断 strace，多次 SIGINT 可能导致其内部状态异常，后续跟踪失效；
- 想安全退出，换终端执行 kill -SIGUSR1 $(pgrep -f "strace.*12345")（仅部分 strace 版本支持）。
只抓锁相关系统调用，避免刷屏干扰
默认输出全是 open/read，关键线索容易被淹没。用 -e trace= 锁定目标：
- 关注用户态锁： strace -e trace=futex,clone,exit_group -p 12345；
- 若怀疑是 POSIX 信号量：加 sem_wait、sem_post；
- 只看失败调用（返回 -1）：加 -z 参数；
- 需要耗时统计辅助判断：加 -T；
- 输出太长难读？用 -s 1024 增大字符串截断长度，避免地址被截成 0x557a...<unfinished ...></unfinished>。
从 futex 地址反推代码中哪个 mutex
当 strace 显示类似 futex(0x557a41002040, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)：
- 这个 0x557a41002040 就是用户态 mutex 变量的内存地址；
- 在源码中搜索初始化该 mutex 的位置（如 pthread_mutex_init(&g_mutex, NULL)），并在附近加 printf("g_mutex addr: %p\n", &g_mutex);；
- 下次复现时对比地址，就能确认是哪个锁；
- 注意：如果程序用了 PTHREAD_MUTEX_INITIALIZER 静态初始化，地址通常在 data/bss 段，可结合 objdump -t a.out | grep mutex 辅助定位；
- 多线程下，不同线程的 futex 调用可能指向同一地址，说明它们在争抢同一个锁。
配合 pstack/gdb 看线程栈，确认调用上下文
strace 告诉你“卡在哪条系统调用”，但不知道“是谁调的”：
- 单独运行 pstack 12345，快速看所有线程当前函数栈；
- 或进 gdb -p 12345，执行 thread apply all bt，找哪些线程停在 pthread_mutex_lock；
- 对比 strace 中卡住的线程 ID 和 pstack 中的 LWP ID（轻量级进程号），锁定具体线程；
- 如果栈里出现 __lll_lock_wait 或 futex_wait_queue_me，基本坐实是 pthread mutex 死锁；
- 注意：某些优化编译（-O2）可能导致内联，栈帧不完整，这时需关优化重编译验证。
真正麻烦的不是看到 futex，而是多个线程卡在不同锁上形成循环等待——strace 只能帮你揪出每个“卡点”，串起来靠你读代码逻辑。比如一个线程卡在锁 A 等锁 B，另一个卡在锁 B 等锁 A，这种依赖关系 strace 不会画图，得你自己画出来。
