Docker软硬资源限制基于Linux Cgroups确定性管控：--cpus和-m为硬限制，超限即节流或OOM；--cpu-shares和--memory-reservation为软限制，仅在资源争抢时生效，实现“低峰多用、高峰保底”的弹性调度。
CPU：用好 --cpus（硬上限）和 --cpu-shares（软调度权）
硬限制推荐直接使用 --cpus，它设定了容器在单位时间（默认 100ms 周期）内能使用的最大 CPU 时间，支持小数，语义明确：
-
--cpus 1.5= 每 100ms 最多用 150ms CPU 时间 ≈ 1.5 个核满载 - 该值是绝对上限，超了会被内核节流，不会影响其他容器
软限制则靠 --cpu-shares 实现——它不设上限，只在多个容器同时争抢 CPU 时起作用：
- 默认值是 1024；设为
--cpu-shares 2048表示同等负载下拿约 2 倍于默认容器的 CPU 时间 - 仅当宿主机 CPU 使用率接近 100% 时才生效；空闲时所有容器都能跑满
- 适合给核心服务（如订单服务）更高权重，非关键任务（如日志清理）设低权重
内存：-m 是硬门槛，--memory-reservation 才是弹性关键
-m / --memory 是必须设置的硬限制，超过即触发 OOM Kill：
-
-m 1g表示物理内存最多用 1GB；一旦超限，进程被杀，容器退出 - 务必配合
--memory-swap明确是否允许 Swap（生产环境通常禁用：--memory-swap 1g）
真正体现“弹性”的是 --memory-reservation（内存软限制）：
- 它不阻止容器使用更多内存，但告诉内核：“请优先保障我至少有这么多内存可用”
- 例如：
-m 2g --memory-reservation 1.2g表示平时可涨到 2GB，但系统内存紧张时，会优先压缩它回 1.2GB 以下 - 这是实现“低峰多用、高峰保底”的关键参数，也与 Kubernetes 的 requests/limits 设计思路一致
组合配置示例：一个 Web 服务的生产级写法
假设你部署一个 Nginx + PHP-FPM 的 Web 应用，希望它日常平稳、高峰期扛压、极端时让位：
docker run -d \--name web-prod \-
--cpus 1.2 \← 硬上限防 CPU 啃光 -
--cpu-shares 1536 \← 比默认高 50%，争抢时优先 -
-m 1.5g \← 内存硬顶，防 OOM -
--memory-reservation 1g \← 日常保底，压力下可收缩 -
--memory-swap 1.5g \← 禁用 Swap（swap=memory） nginx:alpine
验证与调优提示
运行后别忘了确认是否生效：
-
docker stats web-prod→ 实时看 CPU% 和 MEM USAGE 是否卡在预期范围内 -
docker exec web-prod cat /sys/fs/cgroup/memory/memory.limit_in_bytes→ 查硬限制字节数 -
docker exec web-prod cat /sys/fs/cgroup/cpu/cpu.shares→ 查 CPU 权重值
记住：软限制不是“保证能用”，而是“尽量留着”；硬限制不是“设得越小越好”，而是“略高于 P95 峰值 + 20% 缓冲”。实际值需结合监控数据（如 Prometheus + cAdvisor）持续校准。
