容器因oom崩溃本质是内存超限被内核终止，需从编排层、运行时、应用层三层联动排查：先通过退出码137、oomkilled标记及dmesg确认是否真oom；再检查资源limits配置合理性与运行时感知能力；接着分析内存使用趋势峰值；最后进入容器定位内存占用源头。
服务编排环境（如 Kubernetes 或 Docker Swarm）中容器因 OOM 崩溃，本质是单个容器内存使用超限被内核强制终止。排查需结合编排层可观测性、容器运行时状态和应用内部行为三层联动，不能只盯一个环节。
确认是否真是 OOM 导致崩溃
先排除误判：容器退出不等于 OOM。关键看退出码和系统标记：
- Kubernetes 中执行 kubectl describe pod
，在 Events 或 Last State 段找 OOMKilled 和 ExitCode: 137（128+9，即被 SIGKILL 杀死） - Docker 环境运行 docker inspect
| grep -i "oom\|exit" ，确认"OOMKilled": true - 查内核日志：dmesg -T | grep -i "killed process"，输出会明确写出被杀进程名、RSS 内存用量和 cgroup 限制值
检查编排层资源定义是否合理
服务编排工具（如 K8s Deployment、Helm Chart、Docker Compose）里写的 limits 是第一道防线，错配是高频原因：
- 用 kubectl get pod
-o yaml 或 docker-compose config 查看实际生效的resources.limits.memory - 重点核对：Java/Go 等运行时是否“感知容器限制”？例如 Java 必须加
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，否则 JVM 无视 cgroup 限额，按宿主机总内存算堆大小，必触发 OOM - 对比
requests和limits：若 requests 过低，Pod 可能被调度到内存紧张节点；若 limits 过小（比如 Java 应用设 512Mi），而实际堆+非堆内存常驻 800Mi，就注定失败
分析容器内存使用趋势与峰值
OOM 往往发生在瞬时尖峰，而非平均值超标。静态配置检查完，必须看动态行为：
- K8s 环境：用 kubectl top pod
--containers 查实时内存；搭配 Prometheus 查询container_memory_working_set_bytes{pod="xxx"}看历史曲线，关注 P95/P99 峰值是否逼近 limits - Docker 环境：运行 docker stats --no-stream
，注意 MEM USAGE / LIMIT 和 MEM %，同时观察 PRIO 列是否频繁波动（说明内存压力大） - 若已部署监控，直接看 Grafana 内存水位看板——真正危险的是“80% → 100% → 崩溃”的陡升，不是长期稳定在 60%
深入容器内定位内存占用源头
确认是应用自身问题后，进容器抓现场数据：
- Java 应用：提前在启动参数中加入
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof；OOM 后用 kubectl cp 或 docker cp 拿出 dump 文件，用 VisualVM 或 Eclipse MAT 分析大对象、泄漏链 - Go 应用：暴露
/debug/pprof/heap，用 kubectl port-forward 转发后执行go tool pprof http://localhost:6060/debug/pprof/heap查 top allocs - 通用方法：进入容器运行 top -o %MEM 或 ps aux --sort=-%mem | head -10，看哪个进程或线程吃内存最多；再结合 cat /sys/fs/cgroup/memory/memory.usage_in_bytes 对比当前实际用量和 limit
