根本原因是JVM在容器中无法感知内存限制，按宿主机物理内存计算堆大小导致超限被OOM Killer终止；自JDK 8u191和JDK 10起，启用默认的-XX:+UseContainerSupport可使JVM读取cgroup memory.limit_in_bytes合理设堆，建议-Xmx设为容器内存上限的70%～75%，并配置-XX:MaxMetaspaceSize、HeapDumpOnOutOfMemoryError等防护与可观测参数。
根本原因是 JVM 在容器里看不到内存限制，按宿主机物理内存算堆大小，结果实际用超了被 Docker OOM Killer 杀掉。解决思路很明确：让 JVM 知道自己在容器里、别乱猜，再留出非堆内存余量。
让 JVM 正确识别容器内存限制
从 JDK 8u191 和 JDK 10 开始，官方支持 -XX:+UseContainerSupport（默认开启），它能让 JVM 读取 cgroup 的 memory.limit_in_bytes 做堆大小计算。确认是否生效：
- 进容器执行 java -XX:+PrintFlagsFinal -version | grep UseContainerSupport，输出为 true 即已启用
- 若为 false，启动命令中显式加上 -XX:+UseContainerSupport
- 同时建议加 -XX:+UnlockExperimentalVMOptions（JDK 8u191 之前必需）
合理设置 -Xmx，别把容器内存全给堆
JVM 内存 = 堆 + 元空间 + 线程栈 + 直接内存 + JIT 编译代码等。如果容器 mem_limit 设为 1024M，-Xmx 设成 1024m 就必然超限。
- 保守做法：-Xmx 设为容器内存上限的 70%～75%，比如 mem_limit: 1024M → -Xmx768m
- 生产建议：先压测，用 jstat -gc <pid> 观察元空间、直接内存等非堆使用量，再反推预留空间
- 务必同步设 -XX:MaxMetaspaceSize=256m，防类加载过多撑爆元空间
补充关键防护与可观测配置
光调参数还不够，得让问题可发现、可追溯：
- 启动时加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，OOM 时自动生成快照
- 加 -XX:+ExitOnOutOfMemoryError，避免 OOM 后带病运行、行为异常
- Docker Compose 中为服务加 oom_kill_disable: false（保持默认），确保真超限时能被杀，而不是卡死
- 配合监控查 docker stats <容器名> 或 Prometheus 的 container_memory_usage_bytes，对比 JVM 堆使用和容器总内存使用曲线
验证是否真正解决
改完配置后别只看启动成功，要实测：
- 容器启动后，进容器执行 cat /sys/fs/cgroup/memory/memory.limit_in_bytes，确认是预期值（如 1073741824）
- 执行 ps aux | grep java，检查启动参数是否含 -Xmx 和 -XX:+UseContainerSupport
- 用压力工具模拟流量，观察 docker stats 输出中的 MEM USAGE 是否稳定在 limit 以下，且无 OOMKilled 标记
