退出码137表示容器被SIGKILL终止，极大概率是OOM Killer所致；需结合docker ps -a、docker inspect查看ExitCode和OOMKilled字段，并通过dmesg -T | grep -i "killed process"确认内核级OOM记录。
直接看退出码和内核日志，这是最准的判断路径。容器因内存溢出被杀后，docker 本身不报 oom，而是用 exit code 137（sigkill）体现，且 oomkilled 字段在 docker inspect 中可能为 false，不能只信它。
查退出码和容器状态
运行以下命令快速确认是否被系统级 OOM 杀死：
-
docker ps -a—— 找到 STATUS 显示Restarting (137)的容器 -
docker inspect <容器ID> | grep -A 10 "State"—— 查看"ExitCode": 137和"FinishedAt"时间戳 -
docker inspect <容器ID> | grep "OOMKilled"—— 若返回true是强证据；但返回false不代表没发生，需继续查内核
抓内核 OOM Killer 记录
这是决定性步骤。Docker 层看不到 OOM 全貌，必须看宿主机内核日志：
dmesg -T | grep -i -E "killed process|out of memory|oom"- 重点识别含
Out of memory: Kill process和容器进程名（如java、node或你服务名）的行 - 关注
anon-rss值（实际物理内存占用），比如anon-rss:1964100kB≈ 1.97GB，对比容器内存限制是否超限
核对宿主机与容器内存使用
避免误判是“应用内存泄漏”还是“配置过小”：
-
free -h—— 看整体内存压力（如available小于 500MB 且used接近total，说明系统级紧张） -
docker stats <容器ID> --no-stream—— 实时观察 RSS 内存是否持续逼近你设置的--memory限额 - 若未设限额，容器可吃尽宿主机内存，极易触发全局 OOM Killer
交叉验证 Docker 事件与日志时间线
把多个来源的时间戳对齐，确认因果链：
- 从
docker inspect中记下FinishedAt（如2026-09-25T22:18:03.123Z） - 用该时间查：
docker logs -t --since "2026-09-25T22:18:00" <容器ID> | tail -10—— 看崩溃前最后输出 - 同时查：
journalctl -u docker.service --since "2026-09-25T22:18:00" | grep -i "fail\|kill\|oom" - 再比对
dmesg输出中同一秒附近的 OOM 记录 —— 四者时间一致，基本锁定根因
