线上最让人困惑的一类问题，就是程序没有明显报错，却突然没了。很多时候，罪魁祸首不是代码主动退出，而是系统在内存压力下触发 OOM，或者容器 / 服务所在的 cgroup 资源限制被打穿。

这类问题难的地方在于：从应用视角看，症状往往只是“进程消失了”；从系统视角看，其实背后已经有很清楚的内存竞争和资源约束逻辑。

资源限制不是为了刁难程序，而是为了避免一份失控占用拖垮整台机器。

为什么这一篇重要

如果不理解 OOM 和 cgroup，容器时代很多“服务无故退出”问题就会显得非常玄学。

先把核心问题想清楚

  • OOM 是系统在极端内存压力下的自我保护机制。
  • cgroup 用来对一组进程做资源隔离和限制。
  • 应用没报错退出，不代表系统层没有做出强制决策。

实战里更该关注什么

  • 排障时除了看应用日志，也要去查内核日志和容器事件。
  • 理解容器内看到的资源和宿主机真实资源边界可能不同。
  • 把内存占用增长、limit 配置和 OOM 时间点串起来看。

常见误区

  • 进程消失就先怀疑应用自己崩了。
  • 只会调大 limit，不去分析为什么会打穿。
  • 不了解 cgroup，就很难看懂容器里的资源表现。

一个值得自己做的小练习

在可控环境里给一个进程设置较低内存限制，再让它逐步申请更多内存，观察系统日志、cgroup 统计和进程退出现象。

小结

OOM 与 cgroup 是现代 Linux 运行环境里绕不开的一层资源治理逻辑，理解它们能大幅减少很多“进程神秘消失”的困惑。