直接在docker-compose.yml中配置deploy.resources可从根源防止多服务资源抢占，需CPU与内存双控：cpus和memory设硬上限（如'0.8'核、768M），memory_swap设等值禁用swap，reservations保障启动资源（如256M），Java服务须同步调低JVM堆（-Xmx600m）、启用UseContainerSupport，并配置IO权重、tmpfs及实时监控验证。
直接在 docker-compose.yml 里配 deploy.resources，就能从根源上防住多服务抢 CPU、吃光内存、拖垮整台机器——关键不是“能不能限”，而是“怎么限得准、不翻车”。
CPU 和内存必须双控，硬限+预留缺一不可
只设上限不管启动资源，容器可能根本起不来；只留资源不限上限，又容易爆发式抢占。
-
CPU 硬限用
cpus：比如cpus: '0.8'表示最多占 0.8 个逻辑核，内核 CFS 层强制执行，比cpu_shares更稳，适合网关、认证等延迟敏感服务 -
内存必须设硬上限 + 禁 swap：
memory: 768M+memory_swap: 768M（即swap=0），避免 OOM Killer 误杀邻近容器 -
预留值要真实可用：
reservations.memory: 256M是告诉调度器“这个服务至少要 256MB 才能跑起来”，防止启动时因瞬时内存不足失败
Java 服务得同步调 JVM，否则白配限制
很多重启问题不是代码写的差，而是 JVM 没管住自己——-Xmx 设太高，容器内存一满，宿主机直接干掉整个容器进程（exit code 137）。
- 若容器
memory: 1G，JVM 堆建议设为-Xmx600m或更低，留出 400MB 给元空间、线程栈、本地 Direct Buffer - 镜像优先选轻量型：如
eclipse/jre17:jre-17.0.2_8-jre或amazoncorretto:21-alpine-jre，比传统 OpenJDK 内存开销低 30%+ - 加启动参数：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=60.0，让 JVM 主动读取 cgroup 限制，自动适配
IO 和磁盘争抢不能只看 CPU 内存
日志服务、文件上传模块常偷偷打满磁盘吞吐，间接卡死数据库连接池——这种争抢不会报 OOM，但会让所有服务变慢。
- 对 MySQL 容器，加
blkio_weight: 800（范围 10–1000），提升磁盘调度优先级 - 对 ELK 日志收集器，加
device_read_bps: /dev/sda:5mb和device_write_bps: /dev/sda:3mb，硬限 I/O 带宽 - 高频写日志的服务，挂载
tmpfs卷：volumes: ["/var/log/app:/var/log/app:tmpfs,size=64m"]，减少落盘压力
运行时得盯紧，配置再好也得靠观察验证
配置写得再好，也得靠实时观察来验证效果。
- 用
docker stats实时看各容器 CPU、内存、IO 使用率，快速定位异常服务 - 查配置是否落地：
docker inspect <container-id> | grep -A 10 Resources，确认 limits/reservations 已生效 - 压测时重点观察：当某服务 CPU 达到
cpus上限时是否被平滑压制，内存接近memory时是否触发 GC 而非被 kill
