必须同时设置--cpus和--memory硬限制，否则单一维度失控将危及主机稳定；--cpus是严格配额，--memory超限触发oom killer；--memory-swap应禁用或严格限制；deploy.resources仅在swarm模式生效；限制后须用docker stats和cgroup验证实际效果。
直接限制容器资源上限，是防止其在压力下拖垮主机最有效、最可控的手段。不设 --cpus 和 --memory，等于把主机 CPU 和内存裸露给容器自由争夺。
必须同时设置 CPU 和内存硬限制
只限一个维度，另一维度仍可能失控。比如只设 --memory=512m，但没控 CPU，一个死循环进程就能占满所有核心，导致调度器卡死、其他容器无法响应；反之，只限 --cpus=0.5 却不限内存，Java 应用可能缓存暴涨，触发 OOM Killer 杀掉宿主机上的 SSH 或监控进程。
-
--cpus是硬性配额，无论系统是否空闲，容器都无法突破该值（例如--cpus=1.0表示最多用满 1 个物理核心） -
--memory触发内核 OOM Killer：一旦容器 RSS 内存超限，内核会立即终止其主进程，不会等待或降级 - 避免使用
--cpu-shares替代--cpus：它只是争抢时的权重，无实际约束力；--cpu-shares=512在单容器运行时等同于不限制
慎用 memory-swap，多数场景应禁用 swap
启用 --memory-swap 会让容器在内存不足时使用磁盘交换空间，表面看“缓解”了 OOM，实则掩盖问题并引入严重延迟——尤其当多个容器同时换页，I/O 队列堆积，整台主机响应停滞，表现和 DoS 几乎一致。
- 生产环境推荐设
--memory-swap等于--memory（如--memory=512m --memory-swap=512m），即禁用 swap - 绝对不要设
--memory-swap=-1：这等于开放无限 swap，风险极高 - 若确实需保留少量 swap 缓冲，
--memory-swap最大值不应超过--memory的 1.2 倍，且必须配合 I/O 限速（--device-write-bps）
Docker Compose 中 deploy.resources 不是默认生效的
很多人写了 deploy.resources.limits 却发现没起作用，根本原因是：这些配置仅在 Swarm 模式或 docker stack deploy 下才被识别。用 docker-compose up 启动时，deploy 字段被完全忽略。
- 开发/测试环境想用 Compose 生效，必须加
--compatibility参数：docker-compose --compatibility up -d - 更稳妥的做法是，在 CI/CD 或部署脚本中统一转为
docker run命令，显式传入--cpus和--memory -
reservations在 Compose 中仅影响调度器预估（对单机无实质作用），别误以为它能“预留资源”——Linux 不会为未运行的容器锁住 CPU 或内存
限制之后必须验证是否真正生效
参数写对 ≠ 效果落地。cgroups v2 已成主流，但部分旧内核或容器运行时（如某些 containerd 版本）对 --cpus 解析有偏差，可能导致实际限制宽松或失效。
- 启动后立刻执行
docker stats <container-name></container-name>，观察 CPU % 是否稳定在理论上限附近（如--cpus=0.5应 ≤ 50%） - 检查 cgroup 设置：
cat /sys/fs/cgroup/docker/<container-id>/cpu.max</container-id>，输出应为类似50000 100000（表示每 100ms 最多用 50ms） - 用
stress-ng --vm 2 --vm-bytes 1G类工具主动压测，确认容器在内存超限时是否被 OOM Killer 终止（查dmesg | tail是否含Killed process）
最容易被忽略的一点：资源限制不是一劳永逸的配置项。应用版本升级、流量模式变化、JVM 堆参数调整，都可能让原有 --memory 值从安全变成危险阈值。上线新镜像前，务必重跑压测并更新 limits。
