Docker基础教程（254）Docker资源控制之限制内存：别让容器变成“内存饕餮”！Docker内存限制的“紧箍咒”实战手册

深度分析Docker资源控制之限制内存，并附完整示例

一、 引言：当容器变成“脱缰的野马”

想象一下，你正在管理一个现代化的微服务“动物园”。每个服务都被优雅地打包在一个Docker容器里，它们本应是轻快灵巧的“宠物”，在自己的小窝里安静运行。然而，某个夜深人静的晚上，一个名为java-app-最新版的容器，突然食欲大增，开始疯狂吞噬宿主机的内存。它像一只失控的“哥斯拉”，不仅吃光了自己的口粮，还开始抢夺邻居（其他容器）的食物，最终一脚踩塌了整个动物园（宿主机崩溃）！

这绝非危言耸听。Docker容器的核心优势之一是资源隔离，但默认情况下，一个容器最多可以使用宿主机的所有可用内存。如果容器内应用发生内存泄漏（Memory Leak）或遭遇异常高负载，它就会毫无节制地占用资源，导致：

1. “邻里”失和： 同一宿主机上的其他容器因资源不足而性能下降或崩溃。
2. “房东”遭殃： 宿主机本身内存耗尽，触发内核的OOM Killer（Out-Of-Memory Killer）。这个“霸道房东”为了自保，会开始随机“杀死”进程（很可能包括你的重要应用或系统进程），造成服务不可用。
3. 系统雪崩： 整个系统陷入不稳定状态，甚至彻底宕机。

因此，为容器设定内存限制，不是可选项，而是生产环境中必须履行的“安全准则”。这就像给每个宠物戴上牵引绳，划定活动区域，确保整个动物园井井有条。

二、 内存限制的核心原理：读懂容器的“粮票”

在Docker中，控制内存主要通过docker run命令的-m或--memory参数实现。但这背后是一套精密的Linux内核机制——Cgroups（Control Groups）。你可以把Cgroups理解为宿主机资源的管理员，它负责给每个容器（进程组）分发“粮票”，规定它们能吃多少内存、用多少CPU。

当我们设置 -m 512m 时，我们实际上是在告诉Cgroups：“这个容器最多只能使用512MB的物理RAM。”

但故事到这里还没结束，还有一个关键角色常常让人困惑：交换分区（Swap）。

内存 vs. 交换分区（Swap）：一个生动的比喻

• 物理内存（RAM）： 就像你电脑桌的桌面。东西放在上面，读写速度极快，但空间有限。
• 交换分区（Swap）： 就像你桌子下的抽屉。空间可能很大，但存取东西需要弯腰、开抽屉，速度慢得多。

当桌面（RAM）不够用时，系统会把一些暂时不用的东西挪到抽屉（Swap