在 Docker 环境中，容器突然退出、服务反复重启，并显示 OOMKilled，通常意味着进程因内存不足被 Linux 内核终止。问题既可能来自容器内存上限过低，也可能是宿主机内存耗尽、应用存在内存泄漏或瞬时峰值过高。本文将从限制配置、状态确认、日志分析到优化方案，整理一套可直接执行的排查流程。🔍
一、理解 Docker 的内存限制机制
Docker 通过 Linux cgroup 控制容器可使用的资源。默认情况下，容器通常没有明确的内存上限，可以在宿主机资源允许的范围内持续申请内存。若单个容器占用过多，可能挤压其他服务，严重时会触发宿主机 OOM，影响整台机器。
内存限制一般分为硬限制和软限制。硬限制规定容器最多可以使用多少内存，达到上限后继续申请可能触发 OOM；软限制则表示宿主机内存紧张时，内核应优先回收或限制哪些容器。相关参数和行为可参考 Docker 资源约束官方文档。
二、为容器设置合理的内存上限
1. 使用 docker run 配置
启动容器时，可通过 --memory 设置硬限制，通过 --memory-reservation 设置软限制。例如，将容器硬限制设为 1 GB，软限制设为 768 MB：
docker run -d --name app --memory=1g --memory-reservation=768m my-app:latest
如需控制内存与交换空间的总量，可增加 --memory-swap。下面的配置表示容器最多使用 1 GB 物理内存，内存与 swap 合计最多 1.5 GB：
docker run -d --name app --memory=1g --memory-swap=1536m my-app:latest
swap 可以缓解短暂的内存峰值，但速度明显低于物理内存，不应把它当作长期扩容方案。生产环境还要结合磁盘性能、延迟要求和宿主机整体负载评估。
2. 使用 Docker Compose 配置
使用 Compose 时，可在服务配置中声明内存限制。不同 Compose 运行模式对部分字段的处理方式可能存在差异，修改后应通过容器检查命令确认限制是否真正生效。
services:
app:
image: my-app:latest
mem_limit: 1g
mem_reservation: 768m
memswap_limit: 1536m
配置完成后重新创建容器：
docker compose up -d --force-recreate
三、确认容器是否真的被 OOMKilled
退出码 137 常与 SIGKILL 有关，但不能仅凭退出码断定是内存问题。最可靠的第一步是检查容器状态：
docker inspect --format='{{.State.OOMKilled}} {{.State.ExitCode}} {{.State.Error}}' 容器名称
如果 OOMKilled 返回 true，说明容器内进程确实受到 OOM 终止。随后查看容器当前配置的内存上限：
docker inspect --format='Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}}' 容器名称
数值通常以字节表示。如果 Memory 为 0，一般代表没有设置明确的容器内存硬限制，此时还需要重点检查宿主机是否发生全局内存不足。
四、按顺序排查 OOMKilled 根因
- 观察实时占用：执行 docker stats，关注 MEM USAGE、MEM LIMIT 和 MEM %。如果占用持续上升且不回落，可能存在内存泄漏；如果只在特定任务期间激增，应检查批处理、缓存、文件解析或并发请求。
- 检查宿主机资源：执行 free -h、vmstat 1 和 ps aux --sort=-%mem，确认物理内存、swap 以及高占用进程。若多个容器同时异常，宿主机整体资源不足的可能性更高。
- 查看内核记录：执行 dmesg -T | grep -i -E 'out of memory|oom|killed process'，或使用 journalctl -k 搜索 OOM 事件。该步骤有助于区分容器达到 cgroup 上限与宿主机全局 OOM。
- 检查应用日志：执行 docker logs --tail 300 容器名称，观察退出前是否出现大对象分配、队列堆积、线程快速增长或请求量异常。
- 核对运行时参数：Java 堆、Node.js 堆、数据库缓存和连接池都可能占用大量内存。应用自身的内存上限应低于容器硬限制，为线程栈、原生内存、运行时元数据和系统库预留空间。
五、常见场景与处理方法
- 限制值明显偏低：根据监控结果适度提高容器上限，并通过压力测试验证，而不是在故障后无限增加内存。
- 内存持续线性增长：优先使用应用性能分析工具定位泄漏点，检查未释放对象、无限缓存、监听器和连接资源。
- 瞬时峰值触发 OOM：降低任务并发，将大文件改为流式或分批处理，并为队列设置长度上限与背压机制。
- 宿主机资源争抢：为所有关键容器设置合理限制，保留宿主机系统内存，并分散高负载任务。
- 容器不断重启：暂时调整重启策略，避免故障容器形成快速重启循环，同时保留现场日志和监控数据。⚠️
六、生产环境预防建议
上线前应通过压测记录应用的稳定占用、峰值占用和业务增长趋势，再确定限制值。监控系统应同时采集容器内存使用率、工作集、重启次数、宿主机可用内存和 OOM 事件，并在接近限制前告警。
不要随意使用 --oom-kill-disable 规避问题。关闭保护并不能消除内存不足，反而可能让宿主机进入严重抖动或失去响应。更稳妥的方式是限制资源、优化应用、控制并发，并预留必要的安全余量。
总结
处理 Docker OOMKilled 的核心思路是：先通过 docker inspect 确认事实，再结合 docker stats、内核日志和应用日志定位原因，最后在“调整限制”和“优化程序”之间选择正确方案。合理的内存配置不是简单填入一个数值，而是建立在真实监控、压力测试和容量规划之上。按照上述流程逐层排查，通常可以快速区分配置过小、应用泄漏、瞬时峰值和宿主机资源不足等问题，让容器运行更加稳定。✅
