常见进程异常表现
程序运行时卡死、响应变慢，或者直接崩溃退出，这类问题往往让人头疼。比如你正在处理一份重要报表，后台服务突然没了响应，任务管理器里进程还在，但就是不动了。这时候就得靠进程调试方法来揪出问题根源。
使用 ps 和 top 查看进程状态
在 Linux 系统中，最基础的操作是查看进程是否存在以及资源占用情况。用 ps aux | grep 进程名 可以快速找到目标进程的 PID。
ps aux | grep python如果发现某个进程 CPU 占用持续 90% 以上，可能是陷入了死循环或频繁重试逻辑。top 命令能实时观察变化：
top -p <PID>通过 strace 跟踪系统调用
当一个进程看起来“卡住”时，很可能是阻塞在某个系统调用上，比如读文件、等网络响应。strace 能帮你看到它到底在干什么。
比如一个 Python 脚本突然不动了，可以用下面命令附加到进程：
strace -p <PID>你会看到类似 read(3, 或 connect(4, 的输出，说明它正在等待 I/O。如果一直停在某一行，基本就能判断卡在哪一步了。
注意信号中断的情况
有时候 strace 显示 --- SIGURG {sa_handler=0x400000, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART} ---，这表示有信号触发。多数情况下不影响流程，但如果频繁出现，可能和定时器或多线程有关。
gdb 附加进程进行堆栈分析
对于 C/C++ 编写的程序，gdb 是更深入的工具。即使进程没开调试符号，也能看出大致调用路径。
先用 gdb 附加：
gdb /path/to/binary <PID>进入交互界面后输入：
bt会打印当前所有线程的调用栈。如果看到某函数反复出现在多个层级，可能是递归过深或死循环。Java 程序虽然不直接用 gdb，但可以通过 jstack 替代实现类似效果。
日志配合调试更高效
很多问题其实在日志里早有征兆。比如进程每隔几秒打一次心跳，突然中断前最后一条日志停留在数据库连接失败，那基本可以锁定是 DB 问题。加上 log 输出时间戳和线程 ID，排查起来更清晰。
没有日志怎么办？临时加一句 fprintf(stderr, "Reached checkpoint 5\n");，重新编译跑一遍，比盲调快得多。
利用 lsof 查看打开的资源
进程打不开文件、端口被占用，都可以用 lsof 查。
lsof -p <PID>输出中能看到该进程打开了哪些文件、套接字。如果发现大量 TIME_WAIT 状态的连接，可能是客户端没正确关闭连接池。
小技巧：kill -STOP 和 kill -CONT
想临时暂停一个进程观察状态，可以用：
kill -STOP <PID>暂停后做检查，比如看内存占用、dump 堆栈，再恢复：
kill -CONT <PID>这个操作不会终止进程，适合生产环境短时诊断。
避免陷入无限等待
调试时别忘了设置超时。比如用 strace 跟踪时加个 -t 参数，能看到每条系统调用的时间戳，方便判断是否长时间无进展。也可以用 timeout 命令限制执行时间：
timeout 30s strace -p <PID>防止调试过程本身拖慢系统。