进程僵死表现为cpu≈0%、内存停滞、无法响应信号、网络与日志中断；ps看stat为d或长时r，strace可定位卡在futex/read/epoll_wait等系统调用。
进程僵死的典型表现与快速确认
进程僵死通常表现为：CPU占用率接近0%、内存不再增长、无法响应信号（如kill -15）、网络连接停滞、日志停止输出。可通过ps aux | grep your_script观察STAT列——若显示D（不可中断睡眠）或长时间R（运行中但无进展），需警惕。用strace -p PID可实时查看系统调用卡在何处，比如停在futex、read或epoll_wait上，这是定位阻塞点的关键线索。
常见僵死原因及对应检查项
Python进程僵死往往不是代码逻辑错误，而是资源交互层面的问题：
- 文件描述符耗尽：打开大量文件/Socket未关闭，导致后续open()或socket()阻塞在内核；检查lsof -p PID | wc -l是否接近系统限制（ulimit -n）
- 锁竞争死锁：多线程中threading.Lock或RLock被异常持有（如未进finally块释放）；用pstack PID或gdb -p PID -ex "thread apply all bt" -ex quit看各线程持锁与等待状态
- 子进程僵持：调用subprocess.Popen后未读取stdout/stderr又未设置timeout，子进程输出缓冲区满导致阻塞在write()；建议统一使用run(..., timeout=30)或显式管理管道
- GIL之外的C扩展阻塞：如某些数据库驱动（psycopg2旧版）、加密库（pycryptodome）在底层调用中未释放GIL却陷入系统调用；需查文档确认是否支持异步/超时，或升级到支持interruptible的版本
异常退出的痕迹追踪方法
进程非正常退出（如段错误、被OOM Killer杀死、信号终止）不会留下Python级traceback，需从系统层捕获线索：
- 检查dmesg -T | tail -30：若出现Out of memory: Kill process XXX (python)，说明被OOM Killer干掉；调整vm.overcommit_memory或限制容器内存
- 启用core dump：ulimit -c unlimited并配置/proc/sys/kernel/core_pattern，用gdb python core.xxx分析崩溃现场
- 监听信号：在程序入口加signal.signal(signal.SIGSEGV, handler)等，或用strace -e trace=signal -p PID观察是否收到SIGKILL、SIGABRT
- 检查父进程行为：若为systemd服务，运行journalctl -u your-service --since "1 hour ago"；若为supervisord，查supervisorctl tail -f your-program stderr
预防性加固建议
避免问题发生比事后排查更高效：
立即学习“Python免费学习笔记（深入）”；
- 所有阻塞I/O操作强制加超时：socket.settimeout(30)、requests.get(url, timeout=30)、redis.Redis(..., socket_timeout=5)
- 关键锁操作包裹在try/finally中，或使用with lock:语法确保释放
- 定期调用resource.getrusage(resource.RUSAGE_SELF).ru_maxrss记录内存峰值，配合监控告警
- 生产环境启动时加-X dev（Python 3.7+）启用开发模式，自动报告ResourceWarning（如未关闭文件）
