Linux操作系统本身并不会为整个系统设置一个“统一内存上限”，但通过内核的cgroup机制，管理员可以对一组进程施加严格的内存用量约束。这种能力已成为容器技术的基石——Docker、Kubernetes等平台正是依赖cgroup的memory子系统来确保容器不会耗尽宿主机的物理内存。那么，进程感受到的内存限制从何而来？它又如何影响应用的运行与稳定性？
cgroup v1中的内存限制与行为
在cgroup v1架构下，每个子系统拥有独立的挂载点，memory子系统的配置通过虚拟文件系统暴露。创建一个控制组后，向memory.limit_in_bytes文件写入数值即可设定该组内所有进程的内存使用上限。这个限制不仅包括物理内存（RSS），还包括页面缓存等内核维护的内存，遵循memory.usage_in_bytes统计口径。一旦使用量超过限制，内核就会依据memory.oom_control设置决定是直接杀死进程还是暂停并等待回收。
值得注意的是，达到限制后并非立即触发OOM。内核会尝试回收该组内的可回收内存（如文件缓存），如果仍无法释放足够空间，才会调用OOM killer选择并终止进程。我们可以通过memory.oom_control中的oom_kill_disable开关关闭自动Kill，此时进程会被置于不可中断睡眠状态，直到内存被释放或限制被提高。这种差异非常关键：开发环境可能希望进程直接退出以便调试，而生产环境则更倾向于通过监控告警并手动扩容。
实际使用中，许多用户会混淆memory.limit_in_bytes和memory.memsw.limit_in_bytes。后者控制的是物理内存加Swap空间的总和，如果单独设置内存上限而不限制Swap，应用可能大量使用Swap导致性能骤降甚至长时间卡死。推荐两者等值或禁用Swap，强制进程在物理内存不足时直接处理错误或触发OOM，避免交换风暴。
cgroup v2统一层次下的内存管理改进
cgroup v2将各个子系统整合到一个统一的层次结构中，memory控制器移除了许多冗余接口，并强化了内存保护与压力通知机制。在v2中，内存限制通过memory.max文件配置，使用“max”作为默认值表示无限制。相比于v1，v2不再有单独的memsw文件，Swap限制合并到memory.swap.max，且必须在打开memory控制器时通过cgroup.subtree_control一同启用。
v2引入了一个更精准的OOM处理机制：memory.oom.group。设置此值为1后，当组内任何进程触发OOM，整个组的所有进程都会被杀死，而非仅终止单个进程。这对于容器场景意义重大——避免容器内仅杀掉某个子进程而容器的PID 1继续存活，导致容器处于“半死不活”的不可预期状态。此外，v2还提供了memory.pressure文件，用于监测内存压力水平，配合用户态监控实现主动限流或告警，远比传统的OOM通知高效。
在实际切换cgroup v2时，需要检查内核版本及初始化系统是否支持。systemd从v252开始完整支持cgroup v2的统一层次，并能够自动将服务放入对应的slice单元。对于容器运行时，containerd 1.4+与runc 1.0+均已良好适配v2。迁移前应先通过mount | grep cgroup确认当前版本，并逐组调整限制参数，因为v2的接口文件路径和键值格式均有所变化。下面是一个简单的v2内存限制配置示例：
# 创建子cgroup（假设已在统一层次根下） mkdir /sys/fs/cgroup/myapp # 启用内存控制器 echo "+memory" > /sys/fs/cgroup/cgroup.subtree_control # 设置内存硬限制为200MB echo "209715200" > /sys/fs/cgroup/myapp/memory.max # 设置Swap限制为0（禁用Swap） echo "0" > /sys/fs/cgroup/myapp/memory.swap.max # 将当前shell进程移入控制组 echo $$ > /sys/fs/cgroup/myapp/cgroup.procs
容器与Namespace中的内存限制实践
容器技术并非魔法，其资源隔离的底层依然是cgroup与namespace的组合。当执行docker run -m 512m ...时，Docker守护进程会创建对应的cgroup组，并写入memory.limit_in_bytes（v1）或memory.max（v2）。同时，PID命名空间让容器内进程看上去拥有独立的内存视野，但/proc/meminfo等文件实际上仍反映出宿主机的物理内存总量——这可能误导应用内存判断，例如JVM默认会根据/proc/meminfo的数据计算堆大小。
为了避免容器内应用读取宿主机的内存信息，许多平台采取挂载fuse文件系统或使用ctxt aware的fakeprocfs来覆盖/proc/meminfo。在Kubernetes中，Pod的资源限制不仅通过cgroup实现，还会在容器的/sys/fs/cgroup/memory下插入memory.limit_in_bytes，并配合向下传的JAVA_OPTS等环境变量告知应用自身可用内存。实际上，如果只设置了CPU限制而未设内存限制，容器内的进程可以无限制地使用内存，直到宿主机OOM killer被动终止某个进程。因此，生产环境务必为每个Pod明确指定resources.memory.limits。
此外，Linux Namespace本身并不限制内存使用量，它只提供视图隔离。如果仅创建了Mount和PID Namespace而没有cgroup限制，进程组的内存使用依然受到宿主机全局内存管理的约束。正确的做法是始终将namespace与cgroup绑定，利用cgroup的memory.oom.group等特性增强容器的鲁棒性。在Kubernetes 1.26之后，kubelet默认启用cgroup v2，并能够根据Pod的QoS等级自动调节内存保护参数，这标志着Linux内存限制机制从“能用”走向“好用”的关键一步。