容器 exit code 137 表示进程收到了 sigkill 信号，通常是因为触发了 oom（内存溢出）被内核强制终止。排查时先通过 docker inspect 查看 oomkill 字段确认是否为内存不足，再检查宿主机的 dmesg 日志寻找 out of memory 记录。如果确认是资源限制导致，需要调整容器的 --memory 参数或优化应用内存使用。
如何确认容器是否因 OOM 被杀
要确认容器是否因内存不足被杀，最直接的方法是检查 Docker 容器的元数据。执行 docker inspect <container_id></container_id>，在返回的 JSON 中查找 State.OomKill 字段。如果该值为 true，则明确表明容器进程是被 Linux 内核的 OOM Killer 机制终止的。此外，还可以查看 State.ExitCode，虽然 137 是标准信号值，但结合 OomKill: true 才能排除其他人为 kill -9 的情况。这一步能迅速锁定问题方向，避免在磁盘 I/O 或网络问题上浪费时间。
{
"Name": "/my_container",
"State": {
"Status": "exited",
"ExitCode": 137,
"OomKill": true
},
"HostConfig": {
"Memory": 536870912
}
}
上述代码展示了 docker inspect 的典型输出片段。重点关注 OomKill 为 true，这直接证实了退出原因。同时 HostConfig.Memory 显示了容器被限制的内存上限，单位为字节。如果这个值设置得过小，而应用实际运行时需要更多内存，就会触发此错误。开发者应据此判断是否需要增加内存配额。
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
如何在宿主机层面验证内存压力
除了检查容器内部状态，还需要在宿主机上验证系统层面的内存压力。Linux 内核在杀死进程前通常会在系统日志中留下痕迹。使用 dmesg | grep -i 'out of memory' 或 dmesg | grep -i 'killed process' 可以搜索相关记录。这些日志会明确指出哪个 PID 的进程因为内存不足被终止，并可能包含 cgroup 的相关信息。如果宿主机本身内存充足，但容器仍被杀，可能是由于 cgroup 限制严格，或者存在内存泄漏导致局部爆发。此时，结合 free -m 和 top 命令观察历史内存使用情况，有助于理解触发阈值。
$ dmesg | tail -n 20 [12345.678901] Out of memory: Kill process 1234 (java) score 900 or sacrifice child [12345.678902] Killed process 1234 (java) total-vm:2048000kB, anon-rss:1024000kB
这段 dmesg 输出示例展示了内核杀死进程的具体信息。其中 Killed process 1234 (java) 指明了被杀进程的 PID 和名称。 anon-rss:1024000kB 显示了进程实际使用的匿名内存大小，这通常接近或超过容器设置的内存限制。通过对比这个数值与容器配置的 --memory 值，可以量化内存缺口。如果 anon-rss 远小于配置限制，则可能需要考虑是否存在 swap 交换导致的性能问题或其他非 OOM 因素，但在 137 退出码下，OOM 仍是首要嫌疑。
如何根据具体输入调整内存限制以解决 137
当确定是 OOM 问题时，具体的解决方案是调整容器的内存限制。假设当前容器启动命令为 docker run --name my_app -d my_image，且未设置内存限制，导致其占用宿主机全部内存而被杀。我们可以添加 --memory=512m 参数来限制其最大内存使用。例如：docker run --name my_app -d --memory=512m my_image。这样即使应用有内存泄漏，也不会影响宿主机其他服务。如果调整后仍然出现 137，说明 512MB 仍不足，需继续增加，如 --memory=1g。关键在于找到一个平衡点，既保证应用正常运行，又不耗尽宿主资源。对于 Java 应用，还需注意 JVM 堆内存设置应与容器限制匹配，避免 JVM 内部分配超出容器限制。
