程序挂起时应优先用strace定位内核态阻塞点（如open、read、futex），再用ltrace分析用户态库函数卡顿（如json解析、内存分配），二者结合可精准识别挂起层级与根因。
程序挂起（hang）时，往往不是卡在代码逻辑里，而是阻塞在某次系统调用或库函数调用上。ltrace 和 strace 正是定位这类问题的直接手段——一个看用户态“做了什么操作”，一个看内核态“等了什么资源”。关键不在于全量日志，而在于有针对性地缩小范围。
先判断挂起发生在哪一层
系统调用（strace）对应内核交互：文件打开、网络连接、信号等待、进程同步（如 futex）、磁盘 I/O 等。库函数（ltrace）对应用户态行为：内存分配（malloc）、字符串处理（strcpy）、配置解析（getenv、json_parse）、加密调用（EVP_EncryptInit 等）。若程序卡在读取某个配置文件但文件实际存在，大概率是 strace 显示 open 或 read 阻塞；若卡在解析一段 JSON 后无响应，更可能是 ltrace 暴露某个库函数陷入死循环或递归过深。
用 strace 快速抓取阻塞点
对已挂起的进程直接附加追踪：
-
strace -p
-T -e trace=open,read,write,connect,accept,futex ：只关注常见阻塞型系统调用，并显示每次耗时，一眼看出哪一调用长时间没返回 -
strace -p
-c ：汇总统计，查看哪类系统调用占用最多时间或次数异常高（比如大量重复 stat 或 futex 调用，提示锁竞争） -
strace -p
-tt -s 256 ：带毫秒时间戳和更长参数显示，便于结合日志比对上下文
用 ltrace 辅助分析逻辑卡点
当 strace 显示调用已发出但未返回（例如 read 已发起却无返回），说明问题可能在用户态处理环节；此时换 ltrace 查看是否卡在某个库函数内部：
-
ltrace -p
-f -e "malloc+free+realloc" ：检查内存分配是否异常（如反复 malloc 失败后重试、或大块内存申请卡住） -
ltrace -p
-e "*json*+*xml*+*conf*" ：聚焦配置/数据解析相关函数，常用于排查格式错误导致的无限循环 -
ltrace -p
-o ltrace.log ：输出到文件后用 grep 或编辑器搜索 “= ?”（表示未完成）或超长调用行
组合使用提升诊断效率
单一工具容易误判。典型配合方式：
- 先用 strace -p
-c 看整体热点，发现 90% 时间花在 futex 上 → 表明线程锁争用，再用 strace -p-T -e futex 看哪个线程在等谁 - strace 显示 read(3, ...) 挂住 → 用 lsof -p
查 fd 3 对应什么文件或 socket，再结合 ltrace -p 看 read 前刚调用了哪个库函数（如是否刚解密完数据就传给 read） - 程序启动即挂 → 用 strace -f -o start.strace ./program 全流程记录，从 execve 开始逐行查第一个没返回的调用
