容器生命周期异常中断需紧盯退出码、日志、资源状态：退出码0为正常结束，1为应用错误，137多因oom，143提示优雅关闭失败；结合docker inspect和docker logs精准定位；同时核查healthcheck、内存限制及pid 1进程是否前台长期运行。
容器生命周期异常中断，核心要盯住三件事：退出码、日志、资源状态。不是看它“停了”，而是看它“为什么停”。
查退出码，锁定故障类型
退出码是容器中断的“诊断报告单”，直接反映终止原因：
-
0：正常结束，不是故障，可能是命令执行完就退出（比如用
docker run ubuntu echo hello） - 1：应用内部出错，如代码异常、配置加载失败、依赖缺失
-
137：被系统强制杀掉，99% 是内存超限（OOM），
dmesg | grep -i "killed process"可验证 -
143：收到
SIGTERM后未及时退出，说明优雅关闭逻辑有问题 - 139：段错误，常见于 C/C++ 程序空指针或非法内存访问
执行命令获取退出码：docker inspect <container_id> --format='{{.State.ExitCode}}'</container_id>
翻日志，还原运行现场
日志不是扫一眼，要结合退出码有针对性地读：
- 退出码为 1 → 查看最后一段报错堆栈，定位异常类/行号
- 退出码为 137 → 日志里搜
OutOfMemory、GC overhead或启动后突增的内存分配记录 - 退出码为 143 → 检查日志末尾是否有
Received SIGTERM，再看之后是否还有处理日志（如连接关闭、队列清空）
常用命令：docker logs --tail 200 --timestamps <container_id></container_id>
加 --since "2026-09-25T21:00:00" 可精确到分钟级回溯
看资源与健康检查配置
很多“中断”其实是假象——容器没崩溃，但被判定不健康而重启：
- 检查 HEALTHCHECK 是否超时：默认
--timeout=3s太激进，启动慢的服务容易误判；用docker inspect查.State.Health看失败详情 - 确认内存限制是否过低：
docker inspect <container_id> | grep -A 5 Memory</container_id>，对比应用实际 RSS 内存 - 观察磁盘空间：
df -h /var/lib/docker，空间不足会导致容器无法写日志或临时文件而静默失败
验证主进程是否真正存活
容器生命周期由 PID 1 进程决定。如果 CMD 是短命令（如 bash、sh），执行完就退出，容器立刻停止：
- 用
docker ps -a看状态是否为Exited (0)，大概率是这个原因 - 修复方式：改用长运行命令，例如
tail -f /dev/null占位；或使用tini作为 init，托管子进程并正确转发信号 - Dockerfile 示例：
ENTRYPOINT ["/sbin/tini", "--"]<br> CMD ["java", "-jar", "/app.jar"]
