在 Docker 环境中，容器突然退出、反复重启并出现 OOMKilled，通常意味着进程触碰了内存限制，或宿主机整体内存不足。与普通应用异常不同，OOM 终止往往由 Linux 内核直接执行，应用来不及完成日志刷新和资源清理，因此需要结合容器状态、内核日志和内存趋势进行定位。🔍
一、理解 Docker 的内存限制机制
Docker 本身并不直接管理物理内存，而是通过 Linux cgroup 限制容器可使用的资源。默认情况下，容器可能没有明确的内存上限，只要宿主机还有可用资源，就可以持续申请内存。一旦宿主机内存耗尽，内核会启动 OOM Killer，选择并终止部分进程以恢复系统运行。
创建容器时，可以使用 --memory 设置硬限制。例如设置为 512 MB 后，容器内进程及其相关内存消耗达到限制时，可能触发 cgroup OOM。生产环境不建议让重要容器无限制地占用宿主机内存，具体参数和行为可参考 Docker 资源约束官方文档。
- --memory 或 -m：设置容器可使用的最大内存。
- --memory-reservation：设置软限制，通常在宿主机出现内存竞争时发挥作用。
- --memory-swap：限制内存与 Swap 的合计使用量，需要结合 --memory 配置理解。
- --memory-swappiness：控制容器匿名内存换出到 Swap 的倾向。
Swap 可以缓解短时内存峰值，但磁盘访问速度远低于物理内存。配置不合理可能把“快速失败”变成“长时间卡顿”，因此不能把 Swap 当作修复内存泄漏的方案。
二、正确认识 OOMKilled 与退出码 137
容器退出后，如果 Docker 状态中的 OOMKilled 为 true，说明容器曾因内存不足受到 OOM 处理。常见的退出码 137 可理解为进程收到了 SIGKILL 信号，但需要注意：退出码 137 并不必然等于 OOMKilled，人工执行强制终止或其他系统组件发送 SIGKILL，也可能产生相同退出码。
因此，排查时不能只看 ExitCode，而应同时检查 OOMKilled 字段、容器内存限制以及宿主机内核日志。若 OOMKilled 为 false，则应继续检查人为操作、自动化脚本、健康检查、编排平台驱逐策略等因素。
三、按顺序执行异常定位
1. 确认容器退出状态
首先执行 docker ps -a 查看容器是否已经退出、退出时间和状态。随后使用 docker inspect 容器名，重点关注 State 区域中的 OOMKilled、ExitCode、Error、StartedAt 和 FinishedAt。也可以使用格式化参数，只输出所需字段，减少无关信息干扰。
2. 检查实际内存限制
继续查看 HostConfig.Memory 和 HostConfig.MemorySwap。Memory 为 0 通常表示没有设置容器级硬限制；如果存在非零值，则应换算后与业务运行所需内存进行比较。使用 Docker Compose 时，还要核对实际启动配置，避免只修改配置文件却未重新创建容器。⚙️
3. 观察实时内存变化
执行 docker stats，持续观察 MEM USAGE、MEM LIMIT 和 MEM %。如果内存平稳后突然陡升，可能与流量峰值、批处理任务、大文件解析或缓存集中生成有关；如果内存长期单向增长且难以下降，则应优先怀疑内存泄漏、无上限缓存、连接未释放或对象持续堆积。
4. 查看内核与系统日志
在 Linux 宿主机上，可以通过 dmesg 或 journalctl -k 搜索 oom、out of memory、killed process 等关键词。内核日志通常能够显示被终止的进程、相关 cgroup 以及当时的内存压力。如果多个容器在相近时间异常退出，更要检查宿主机是否发生了全局内存不足。
5. 对照业务日志和负载
将 OOM 发生时间与请求量、定时任务、消息积压、文件处理和版本发布时间进行关联。若每次都在同一操作后出现，应在测试环境复现并采集进程级数据。对于 Java、Node.js 等运行时，还要检查堆内存设置是否感知容器限制，并为线程栈、元空间、直接内存和本地库预留空间。
四、常见原因与处理方式
- 容器限制过低：根据压测和历史峰值重新评估限制，不要仅凭空闲时占用量配置。
- 应用存在内存泄漏：使用语言对应的分析工具获取堆快照或分配信息，定位持续增长的对象。
- 缓存没有边界：设置容量、过期时间和淘汰策略，避免把容器内存当作无限缓存。
- 大对象集中加载：通过流式读取、分块处理和分页查询降低瞬时峰值。
- 并发量过高：限制工作线程、任务队列和批处理规模，必要时通过水平扩容分散压力。
- 宿主机资源超卖：汇总所有容器的限制和实际峰值，为系统服务以及突发流量保留安全余量。
五、生产环境的预防建议
治理 OOM 的关键不是简单调大内存，而是建立“限制、监控、告警、分析、验证”的闭环。📊 应为核心容器配置明确的内存上限和重启策略，同时监控当前占用、工作集、Swap、容器重启次数以及宿主机可用内存。
告警阈值应当留出处理时间，避免等到内存达到上限后才通知。每次调整限制前后都要进行压力测试，并记录正常值、峰值和持续时间。对于频繁 OOM 的服务，应保存异常时段的指标、应用日志和内核日志，避免容器重启后证据丢失。
总结
排查 Docker OOMKilled 时，应先通过 inspect 确认 OOMKilled 状态，再核对内存与 Swap 限制，随后结合 docker stats、内核日志和业务负载寻找触发点。修复措施既可能是合理提高资源上限，也可能是处理内存泄漏、限制缓存、降低并发或优化数据处理方式。只有区分容器级超限与宿主机级内存不足，才能避免盲目扩容，让服务在明确的资源边界内稳定运行。✅
