导语：Docker 容器突然退出、服务请求中断，日志里却没有完整异常，往往与 OOM（Out of Memory，内存不足）有关。OOM 并不只是“容器内存用完了”，还可能由宿主机整体内存紧张、应用内存泄漏、并发突增或 cgroup 限制不合理引起。下面从现象确认、原因定位到治理方案，给出一套可直接操作的排查流程。🔍
一、Docker 容器为什么会被 OOM 杀死
Docker 通过 Linux cgroup 对容器的内存进行统计和限制。当容器设置了内存上限，并且应用申请内存时无法通过回收获得足够空间，内核可能在该容器所属的 cgroup 中触发 OOM Killer，终止一个或多个进程。若容器没有设置限制，应用还可能持续消耗宿主机内存，最终触发主机级 OOM。
Docker 官方指出，容器默认没有资源限制，可以使用宿主机内核允许的内存。宿主机发生严重内存不足时，Docker 守护进程、容器进程及其他系统进程都可能成为终止对象，因此生产环境不应依赖默认配置。具体限制机制可参考 Docker 资源约束官方文档。
常见触发原因
- 容器内存上限过低：应用正常运行所需内存已经接近限制，流量高峰、批量任务或缓存增长就可能触发 OOM。
- 应用存在内存泄漏：对象、连接、线程、文件内容或本地缓存未及时释放，内存持续增长且无法回落。
- 运行时参数不匹配：JVM 堆、Node.js 堆或其他运行时的可用内存设置过大，没有给线程栈、直接内存和原生库预留空间。
- 宿主机内存不足：多个容器同时抢占资源，即使某个容器没有达到自身上限，也可能受到主机级 OOM 影响。
- 瞬时并发或任务峰值：大文件处理、图片转换、数据导入和高并发请求可能在短时间内产生明显内存尖峰。
- Swap 配置不当：完全没有 Swap 会减少缓冲空间，但过度依赖 Swap 又可能引发严重延迟，甚至造成服务假死。
二、先确认是不是 OOMKilled
第一步不要急着扩大内存，应先检查容器状态。执行 docker inspect 容器名，重点查看 State.OOMKilled、State.ExitCode、State.Error 和 FinishedAt。如果 OOMKilled 为 true，基本可以确认容器进程曾被内核因内存问题终止。
退出码 137 表示进程收到了 SIGKILL，但它并不等同于 OOM 的唯一证明。手工执行 docker kill、编排系统强制终止或停止超时，也可能产生相同退出码。因此必须结合 OOMKilled 字段和内核日志判断，不能只看退出码下结论。⚠️
随后在宿主机执行 dmesg -T | grep -i oom，并继续检索 killed process、out of memory 等关键词。如果系统使用 systemd，也可以通过 journalctl -k 查看内核日志。日志通常能够说明是主机级 OOM，还是某个 cgroup 内部触发了内存回收失败。
三、检查容器限制与实际使用
使用 docker stats 可以实时观察容器的内存使用量、限制值和百分比。建议不要只看故障发生后的瞬时结果，而是持续采集至少覆盖一个业务高峰周期的监控数据，重点比较常态、峰值以及重启前的增长趋势。
再通过 docker inspect 检查 HostConfig.Memory、MemoryReservation、MemorySwap 等配置。docker run 场景常用 --memory 设置硬限制，使用 --memory-reservation 设置软限制。若使用 Compose，应同步检查 services 下的内存配置是否被当前部署模式实际采用，避免配置写了却没有生效。
判断重点不是“现在用了多少内存”，而是“内存是否持续增长、尖峰发生在什么操作、限制是否覆盖应用堆外开销”。
四、深入排查应用内存组成
容器内存并不只有应用堆。线程栈、共享库、直接内存、文件映射、网络缓冲区、子进程以及部分文件缓存都可能被计入 cgroup。以 Java 为例，只调整最大堆并不能完全控制容器总内存，还要考虑 Metaspace、Direct Memory、线程数量和 GC 工作空间。
可以进入容器使用 ps、top 或 smem 定位高占用进程，再使用对应运行时工具分析。Java 可采集堆转储并检查大对象与引用链，Node.js 可对比 Heap Snapshot，Go 可使用 pprof，Python 则应关注对象增长、进程模型以及大数据集合是否被长期持有。
在 cgroup v2 环境中，还可以查看 memory.current、memory.max、memory.stat、memory.events 和 memory.pressure。memory.events 中的 oom、oom_kill 等计数有助于识别历史事件，memory.pressure 可反映任务因内存回收而停顿的压力情况。相关字段含义可查阅 Linux 内核 cgroup v2 文档。
五、建立可复用的排查顺序
- 记录容器名称、退出时间、退出码和 OOMKilled 状态。
- 检查宿主机 dmesg 或 journalctl 内核日志，确认 OOM 范围。
- 核对容器内存、软限制及 Swap 配置是否真实生效。
- 查看监控曲线，区分持续上涨、周期波动和瞬时尖峰。
- 定位容器内高内存进程，分析堆内、堆外、缓存及子进程开销。
- 在压测或预发布环境复现，验证调整限制或修复代码后的效果。
六、修复与预防建议
如果限制确实低于合理峰值，可以适度增加容器内存，但应保留宿主机安全余量，避免所有容器限制值之和远超主机承载能力。若内存持续单调增长，则应优先修复泄漏，而不是通过定时重启掩盖问题。
应用侧应限制缓存容量、上传大小、批处理数量和并发任务数，大任务尽量采用流式读取或分块处理。运行时内存上限应低于容器硬限制，为堆外内存和系统开销留出空间。📈
监控方面，建议同时设置内存使用率、增长速度、重启次数、OOM 事件和宿主机可用内存告警。只设置“达到限制才报警”通常太晚，应在明显回收压力或持续增长阶段提前通知。对于关键服务，还应进行容量测试，记录稳定负载和高峰负载下的内存基线。
总结
Docker 容器 OOM 排查的核心，是区分容器级限制触发、宿主机整体内存不足和应用自身异常增长。正确流程应从 inspect 状态和内核日志确认事实，再结合资源配置、监控趋势、cgroup 指标与运行时分析定位根因。增加内存只能解决容量不足，无法修复泄漏或无边界缓存。通过合理限制、容量压测、应用优化和提前告警，才能真正降低 OOM 导致的服务中断风险。✅
