java容器中jvm必须启用-xx:+usecontainersupport（java 8u191+默认开启），配合-xx:maxrampercentage=70.0等百分比参数动态设堆，并启用g1gc与合理停顿目标，避免oomkilled。
Java 应用跑在容器里，JVM 参数不能照搬物理机那一套。核心问题在于：JVM 默认看不到容器内存限制，容易按宿主机总内存分配堆，结果刚启动就被 OOMKilled。关键不是“加参数”，而是让 JVM 真正理解容器边界。
必须启用容器感知能力
从 Java 8u191、Java 10 起，-XX:+UseContainerSupport 是基础开关，默认已开启（但低版本需显式加）。它让 JVM 能读取 cgroup 文件，获取容器实际的 CPU 和内存上限。没这个，后面所有百分比参数都无效。
- Java 8u131 及更早版本不支持该特性，务必升级或手动指定堆大小
- 验证是否生效：运行
java -XX:+PrintFlagsFinal -version | grep UseContainerSupport，输出true表示已启用
用百分比代替固定值设堆大小
硬编码 -Xmx2g 在弹性扩缩环境中难维护。推荐用 -XX:MaxRAMPercentage 和 -XX:InitialRAMPercentage，让 JVM 按容器内存限制动态计算堆上限。
- 设为
70.0是常见稳妥值（预留 30% 给非堆内存：线程栈、元空间、JIT 代码缓存、直接内存等） - 避免设到 100%，否则可能因非堆内存突增触发 Linux OOM Killer，容器退出码 137
- 两个参数保持一致，防止堆在运行中扩容，减少 GC 波动
搭配 G1 回收器提升稳定性
容器资源有限，G1GC 更适合：可设定停顿目标、对大堆响应更可控、避免 Serial 或 Parallel GC 在小内存下频繁 Full GC。
- 加上
-XX:+UseG1GC，并配-XX:MaxGCPauseMillis=200明确延迟预期 - 若堆小于 4GB，G1 仍是优选；不建议回退到 SerialGC（仅适用于极小内存场景）
- 避免混用
-Xmx和-XX:MaxRAMPercentage，后者会覆盖前者
启动命令示例与落地要点
一个生产可用的最小安全配置长这样：
java \ -XX:+UseContainerSupport \ -XX:InitialRAMPercentage=70.0 \ -XX:MaxRAMPercentage=70.0 \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=/tmp/heap.hprof \ -jar app.jar
- Dockerfile 中通过
memory限制容器内存（如docker run -m 1g），JVM 才能据此计算 - Kubernetes 场景下，在 Pod 的
resources.limits.memory设置后，上述参数才起作用 - 镜像建议用 JDK 11+ 或带容器支持的发行版（如 Temurin、Zulu、Microsoft Build of OpenJDK）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
