软限制（--memory-reservation）是弹性内存调度机制，必须配合硬限制（--memory）使用且值须小于等于硬限制；系统空闲时容器可接近硬限运行，内存紧张时内核优先回收超软限部分，避免OOM Kill。
通过 --memory-reservation 实现弹性伸缩，关键在于它不设死线，而是为容器划出“优先保障区”——系统内存宽松时，容器可接近硬限制运行；压力上升时，内核会优先压缩超过软限制的部分，避免直接触发 oom killer。
软限制如何配合硬限制工作
软限制必须搭配 --memory（硬限制）使用，且值必须小于等于硬限制。例如：
-
--memory=1g --memory-reservation=512m：容器在空闲时可使用最多 1GB，但当宿主机内存紧张时，Docker 会主动回收超出 512MB 的部分，保留基础运行所需 - 若只设
--memory=1g而不设 reservation，容器一旦用满 1GB 就可能被 OOM Kill，没有缓冲空间 - 软限制默认为 0，即不启用弹性机制；设为 0 等同于未配置
适合弹性伸缩的典型场景
这类配置特别适用于内存使用波动大、但核心功能需持续在线的服务：
- Java 应用（JVM 堆外内存 + GC 波动），预留 60%~70% 的硬限制作为软限，给 GC 和临时缓存留余地
- Nginx 或 API 网关，突发请求导致内存短暂飙升，软限制可吸收毛刺而不中断服务
- 批处理任务容器（如日志清洗），启动时预占内存，执行中按需增长，结束后快速释放
验证与调优要点
仅设置参数不够，需结合监控确认弹性是否生效：
- 用
docker stats <container></container>观察MEM USAGE / LIMIT和MEM %，对比软限值判断是否被动态压制 - 在内存压力下（如用
stress-ng --vm 2 --vm-bytes 2G模拟竞争），检查目标容器是否降级运行而非被 kill - 软限不宜设得过高（如 >80% 硬限），否则失去弹性意义；也不宜过低（如
和 Docker Compose 的集成方式
在 docker-compose.yml 中对应字段是 reservations.memory，需放在 deploy.resources 下：
services:
app:
image: myapp:latest
deploy:
resources:
reservations:
memory: 512M
limits:
memory: 1G
