Docker Compose通过deploy.resources可精准限制CPU和内存：limits.cpus与limits.memory设硬上限（如'0.8'核、768M），reservations保障启动资源（如256M），需配合docker stack deploy完全生效，但docker-compose up（Engine≥24.0）亦可部分执行；Java服务须同步调低JVM堆（如-Xmx600m）、启用UseContainerSupport，并配置IO权重与tmpfs防隐性资源争抢。
直接在 docker-compose.yml 里配资源限制，就能从根源上防住多服务抢 CPU、吃光内存、拖垮整台机器——关键不是“能不能限”，而是“怎么限得准、不翻车”。
用 deploy.resources 正确设硬限和预留
Docker Compose v3.8+ 支持 deploy.resources，但必须搭配 docker stack deploy 才完全生效；而 docker-compose up 在多数版本中仍能识别并应用 limits（尤其 Docker Engine ≥24.0），实际压测验证有效。别被“仅 Swarm 生效”的旧文档误导。
-
CPU 硬限优先用
cpus：比如cpus: '0.8'表示最多占用 0.8 个逻辑核，内核 CFS 层强制执行，比cpu_shares更稳，适合网关、认证等延迟敏感服务 -
内存必须双控：
memory: 768M（硬上限） +memory_swap: 768M（禁用 swap），避免 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 容器，在
docker-compose.yml中加：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 --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}"，一眼看清各容器真实负载 - 重点关注
MEM %：持续 >85% 就该预警，>95% 几乎必然触发 OOM - 用
docker exec -it <容器名> jstat -gc $(pgrep java)查 JVM 实际堆使用，确认是否真由应用导致，而非配置偏差
