关键不是单纯加内存，而是精准划定边界、分清轻重缓急、堵住隐性漏洞：必须设置--memory硬限制，配合--oom-score-adj分级保护，并检查/dev/shm容量与--memory-reservation软限制，辅以docker stats和dmesg监控。
解决Docker容器因资源竞争引发的内存溢出（OOM），关键不是单纯加内存，而是精准划定边界、分清轻重缓急、堵住隐性漏洞。宿主机空闲内存再多，只要单个容器突破自己的限额，内核就会杀进程——退出码137就是最直接的信号。
设置硬限制：给容器划一条不能越过的线
没有--memory，其他所有优化都失去前提。内核只在超限时才启动OOM Killer评估，不设限等于交出“生杀大权”。
-
--memory=2g：强制容器最多使用2GB物理内存，超限即进入OOM判定流程 -
--memory-swap=2g：禁用交换空间，避免swap延迟掩盖真实压力（生产环境强烈推荐） - 避免
--memory=0或不设值，这等同于不限制，风险极高
区分服务优先级：让核心服务更难被杀
资源紧张时，不能靠运气保活。通过--oom-score-adj告诉内核哪些进程更关键。
-
--oom-score-adj=-500：显著降低被终止概率，适合Jupyter、Redis、数据库等核心服务 -
--oom-score-adj=300：提高回收优先级，适合日志压缩、数据导出等临时任务 - 验证是否生效：
docker exec 容器名 cat /proc/1/oom_score_adj，应返回设定值
检查共享内存/dev/shm：64MB默认值常成真凶
很多OOM并非主内存爆了，而是/dev/shm撑满触发的。Chrome Headless、PyTorch推理、PostgreSQL都重度依赖它，而Docker默认只给64MB。
- 进容器执行
df -h /dev/shm，若使用率超90%，极可能就是根源 - 启动时加
--shm-size=1g，对UNet图像处理、Puppeteer等场景建议直接设为1GB - Kubernetes中对应配置为
emptyDir: { medium: Memory, sizeLimit: 1Gi }
配合软限制与监控：提前干预，而非被动救火
硬限制防崩溃，软限制助调度，监控则提供决策依据。
-
--memory-reservation=1.5g：提示Docker在内存紧张时主动回收超出该值的部分，降低OOM触发概率 - 用
docker stats --no-stream 容器名持续观察MEM USAGE / LIMIT，接近95%就该预警 - 定期查
dmesg -T | grep -i "killed process"，确认是否真由OOM引起
