docker内存软硬限制需协同配置：--memory-reservation设软限制（调度优先级），--memory设硬限制（oom防护），二者必须成对且软限小于硬限，结合应用特征与监控持续调优。
在 Docker 中配置内存软硬限制，核心是用好 --memory-reservation（软限制）和 --memory（硬限制）两个参数。它们不是替代关系，而是协同工作的分级控制机制：软限制管“调度优先级”，硬限制守“安全底线”。配对使用才能既保障关键服务不被挤占，又避免资源闲置或失控。
软限制与硬限制必须成对设置
只设 --memory-reservation 不设 --memory 是常见错误——软限制本身不设上限，容器可能无限吃内存，最终拖垮宿主机。同样，只设 --memory 而不设软限制，系统就失去内存压力下的智能调度依据，所有容器被一视同仁回收，关键服务反而容易被误杀。
- 硬限制（
--memory）是强制天花板，超限直接触发 OOM Killer 终止进程 - 软限制（
--memory-reservation）必须小于硬限制，它只在内存紧张时生效，作为内核回收内存的优先级参考 - 例如：
docker run -d --memory=1g --memory-reservation=512m nginx表示：平时可接近 1GB，压力下会被压缩回 512MB 左右
按应用特征设定合理数值
软硬限制不是拍脑袋定的，要结合应用实际行为。长期稳定占用 300MB、偶发峰值到 700MB 的服务，硬限制建议设为 900MB（预留约 20% 缓冲），软限制可设为 400–500MB，给弹性空间又不失控制力。
- 对突发型服务（如批处理任务），软限制可设低些，让其在空闲时多用，在争抢时快速让出
- 对长稳型服务（如 API 网关），软限制应贴近日常用量，确保压力下仍能守住基本性能
- 避免软限制设得过高（比如接近硬限制），否则调度失效；也别设得太低（如 100MB），导致频繁回收影响响应
配合监控持续验证效果
配置完不等于调优完成。需用 cAdvisor、docker stats 或 Prometheus + cgroup 指标，观察容器真实内存走势：是否长期卡在软限制附近？OOM 是否发生？压力下回收是否及时？
- 若发现容器常驻内存远低于软限制，说明预留过多，可下调软限制释放资源
- 若频繁触发内存回收（cgroup memory events 中
high或low频次高），说明软限制偏紧或硬限制不足 - 重点关注
memory.usage_in_bytes和memory.soft_limit_in_bytes的差值趋势
注意 cgroup v2 下的行为一致性
较新 Linux 发行版默认启用 cgroup v2，Docker 20.10+ 已原生支持。此时 --memory-reservation 对应内核的 memory.low，而 --memory 对应 memory.max。行为逻辑不变，但路径和工具链略有差异：
- 确认是否启用 v2：
stat -fc %T /sys/fs/cgroup返回cgroup2fs即为 v2 - v2 中软限制更偏向“保护性下限”，即尽力保障不低于该值，而非 v1 中的“回收触发点”
- 仍推荐保持
--memory-reservation 的配比逻辑，避免跨版本行为误解
