容器资源配额限制防止进程耗尽内存CPU资源
容器里的进程一旦失控，比如内存泄漏或 CPU 占满，会直接拖垮宿主机，甚至影响同在一台机器上的其他业务。
容器资源配额限制就是把每个容器能用的内存和 CPU 锁死，让单个进程最多只能用到你允许的额度。
本文用 Docker 为例，从设置命令、配置编排文件、验证效果到踩坑排查，带零基础用户完整跑一遍。
先搞懂限制什么：内存和 CPU 是两个维度
Docker 对资源的限制主要分两块：内存和 CPU。
内存限制决定容器最多能占多少内存，超过阈值会被系统杀掉或触发 swap；
CPU 限制决定容器最多能用到几个核或者多少百分比的计算能力。
没有限制时，容器进程从宿主机资源池里随意申请，一遇到异常就会引发连锁故障。
用 docker run 参数直接限制
创建容器时，通过 -m 或 --memory 限制内存，通过 --cpus 限制 CPU 核数。
例如：
docker run -d --name myapp \
-m 512m \
--cpus 0.5 \
nginx上面命令表示容器最多使用 512 MB 内存和 0.5 个 CPU 核。
这样即使 nginx 内部出现异常，也不会把宿主机的 8 核 16G 全部吃掉。--cpus 是 Docker 1.13 以后推荐的写法，比老的 --cpu-quota 和 --cpu-period 好理解。
用 Docker Compose 固化配置
项目部署建议用 Compose 文件管理，资源配额写在服务定义里，团队协作更清晰。
在 docker-compose.yml 中：
services:
web:
image: nginx
deploy:
resources:
limits:
cpus: "0.5"
memory: 512M执行 docker compose up -d 后，配额就会随容器一起生效。
有一点要额外留意，deploy.resources 在 Docker Compose V2 中默认生效；
如果你还在用 docker-compose 命令，需要确认版本支持，否则资源限制可能被忽略。
验证配额是否真的生效
容器起来后，用 docker stats 实时查看资源占用：
docker stats myapp可以看到内存使用上限显示为 512 MiB，CPU 百分比被限制在 50% 左右。
也可以用压测工具模拟高负载，比如在容器内执行 stress 工具（测试完记得删除容器）：
docker run --rm -it -m 512m --cpus 0.5 ubuntu sh -c "apt update && apt install -y stress && stress --vm 1 --vm-bytes 600M"当 stress 申请超过 512M 内存时，容器进程会被内核 OOM 杀掉，这就是配额在起作用。
注意容器的退出码如果是 137，表示被系统终止，属于预期现象。
常见坑：内存限制不完整、CPU 限额无效
给容器设置 -m 512m 时，如果不设置 --memory-swap，默认 swap 上限等于内存上限，也就是容器最多可以写 512M 内存加 512M 交换分区。
如果服务器内存紧张，建议同时指定 --memory-swap 512m，彻底禁用 swap 扩展，避免进程实际多用内存。
CPU 限制有几个容易踩的坑：--cpus 0.5 在低版本内核或 Windows 容器上不一定有同样语义；
另外，如果容器内进程开启了多个线程，CPU 限制按时间片控制总量，不是限制进程数，别用 top 里的 CPU% 直接对照。
还有，使用 Docker Compose 时，deploy.resources.limits 在 Swarm 模式下标准行为和服务副本有关，单机部署请先确认 Docker Engine 版本在 20.10 以上，并优先使用 docker compose（新版命令）而不是旧的 docker-compose。
如果你的宿主机已经有其他负载，建议把容器配额设置在总资源的 70% 以内，给系统预留缓冲。
定期用 docker stats 和宿主机 free -h、top 观察，再结合实际压测结果调整阈值，让容器资源配额限制真正起到防止进程耗尽内存 CPU 资源的作用。
