容器因OOM被杀后无法恢复运行，只能重启或重建；需通过设置内存限制（-m）、OOM优先级（--oom-score-adj）、自动重启策略（--restart）并结合监控分析根因来防范。Docker 中没有 `DockerStart` 指令，也没有直接通过某条命令“快速恢复因 OOM（内存溢出）被系统杀死的容器”——因为被 OOM Killer 终止的容器已退出且状态为 `exited`，无法“恢复运行”，只能重启或重新创建。
你真正需要的是：**防止容器因内存不足被杀 + 容器异常退出后能可靠重启**。以下是实用方案：
1. 限制容器内存并启用 OOM 优先级控制
不设内存限制的容器最容易被 linux oom killer 选中杀掉。必须显式指定 --memory 和可选的 --oom-score-adj：
-
docker run -m 512m --oom-score-adj=300 nginx：限制内存为 512MB，同时提高该容器被 OOM Killer 杀死的优先级（值越小越不易被杀，范围 -1000~1000；默认为 0，建议生产环境设为 -500 ~ -300） - 若使用 Docker Compose，在 service 下添加：
deploy:<br> resources:<br> limits:<br> memory: 512M<br> oom_score_adj: -400
2. 配置自动重启策略（关键！）
容器因 OOM 退出后，靠重启策略才能“自动回来”。使用 --restart 参数：
-
--restart unless-stopped：最常用，容器退出（包括 OOM 退出）都会重启，除非手动执行docker stop -
--restart on-failure:5：仅在非 0 状态退出时重试最多 5 次（OOM 退出码通常为 137，属于失败） - Docker Compose 示例：
restart: unless-stopped
3. 查看和确认是否真因 OOM 被杀
别猜，用命令验证：
-
docker inspect <container_id> | grep -i "oom\|status"</container_id>→ 查看"Status": "exited"和"OOMKilled": true -
docker logs <container_id></container_id>：OOM 一般无日志，但可排除应用自身崩溃 -
dmesg -T | grep -i "killed process"（需宿主机权限）→ 直接看到内核日志中哪一进程被 OOM Killer 杀掉
4. 长期优化：监控 + 根因分析
重启只是兜底，治本要定位内存泄漏或配置不合理：
- 用
docker stats实时观察内存使用趋势 - 对 Java 等应用，加 JVM 参数如
-XX:+ExitOnOutOfMemoryError并结合 heap dump 分析 - 检查应用是否加载了过多资源、缓存未清理、连接池未释放等
不复杂但容易忽略。
