docker容器资源限制核心是防止单容器耗尽cpu/内存引发“嘈杂邻居”问题，须按业务设合理硬上限（如--cpus、--memory），禁用swap，并配--pids-limit兜底进程数，再通过docker inspect验证cgroups真实状态。
在docker中配置容器资源限制，核心是防止某个业务容器“吃掉”过多cpu、内存等资源，避免拖垮其他容器——也就是解决“嘈杂邻居”问题。关键不在于堆参数，而在于按业务特征设合理上限，并配合监控验证效果。
CPU限制：用--cpus最直观有效
对大多数业务容器，优先使用--cpus参数设定硬性上限，它直接对应CPU核心数（支持小数），底层通过cgroups的cpu quota机制实现，调度稳定、理解成本低。
- Web服务类（如Nginx、API网关）：设--cpus="0.5"或"1.0"，避免突发请求打满CPU影响其他服务
- 计算密集型任务（如数据处理、转码）：可设--cpus="2.0"，但需确保宿主机有冗余核心
- 不要混用--cpu-shares和--cpus：前者是竞争时的权重比例，非硬限，容易误判；生产环境建议统一用--cpus
内存限制：必须配--memory，慎用swap
内存超限会触发OOM Killer强制杀进程，是最危险的资源失控场景。务必为每个容器明确设置--memory（即-m），值应略高于应用实测峰值。
- 典型值：轻量API服务设--memory="512m"，Java应用因堆外内存考虑建议加20%余量，如--memory="1g"
- 慎设--memory-swap：若开启，总可用内存=memory+swap，可能掩盖真实内存压力；建议设为--memory-swap="1.5g"（当memory=1g时），或直接禁用（设--memory-swap="-1"）
- 避免只限CPU不限内存：常见错误，会导致内存耗尽后整机响应迟缓甚至假死
进程与并发数兜底：--pids-limit不能少
CPU和内存限制无法阻止fork炸弹或连接数爆炸。对网络服务类容器，必须叠加--pids-limit，从进程总数层面控制并发规模。
- Nginx/Envoy等代理服务：设--pids-limit=200，防连接数突增导致进程泛滥
- Go/Python微服务：根据goroutine或线程池上限设值，例如--pids-limit=100，比默认无限更安全
- 该参数与应用层限流（如Nginx limit_conn、rate包）互补，属于系统级最后一道防线
Docker Compose中统一管理资源策略
多容器编排场景下，把资源限制写死在docker-compose.yml的deploy.resources.limits里，既可版本化管控，又能被Swarm/K8s兼容识别。
- 示例配置：
services: api: image: my-api deploy: resources: limits: cpus: '0.8' memory: 768M reservations: cpus: '0.3' memory: 384M - limits是硬上限，保障不越界；reservations是软预留，确保调度时有最低资源可用，避免冷启动卡顿
- 启动后用docker inspect 容器名 | grep -i "nano\|memory"验证配置是否生效
