必须带小数点，否则JVM启动直接失败；因JDK8u191+/JDK9+中MaxRAMPercentage按double类型解析，纯整数字符串如"75"可能被atof()误转为0.0或触发异常，导致“Unrecognized VM option”等静默报错。
必须带小数点，否则 JVM 启动直接失败。这是最常踩的坑——-XX:MaxRAMPercentage=75 会报错，-XX:MaxRAMPercentage=75.0 才合法。
为什么必须写成浮点格式
从 JDK 8u191 和 JDK 9 开始，MaxRAMPercentage 是按 double 类型解析的。JVM 内部调用 atof() 或类似函数转换参数值，纯整数字符串（如 "75"）在某些 C 库实现中可能返回 0.0 或触发解析异常，导致启动中断。日志里通常只显示 Unrecognized VM option 或 Could not create the Java Virtual Machine，不提示具体哪项错。
实操建议：
- 所有百分比参数统一写成
X.X格式，比如50.0、75.0、85.0 - 别依赖 IDE 自动补全或 AI 生成的整数写法，手动加
.0 - 验证方式：容器内执行
java -XX:+PrintFlagsFinal -version | grep MaxRAMPercentage，确认输出是double类型且值非 0.0
MaxRAMPercentage 生效的前提是 UseContainerSupport
MaxRAMPercentage 不是独立生效的魔法参数。它依赖 JVM 能正确读取容器的 cgroup 内存限制（即 /sys/fs/cgroup/memory/memory.limit_in_bytes）。而这个能力由 -XX:+UseContainerSupport 控制——JDK 10+ 默认开启，但旧内核、未挂载 cgroup v2、或容器以 --privileged 外其他方式运行时，可能 fallback 到宿主机 /proc/meminfo 的 MemTotal。
常见错误现象：
- 容器
limits.memory=16Gi，设了-XX:MaxRAMPercentage=75.0，但jstat -gc <pid>显示最大堆只有 ~4GB（≈ 宿主机内存的 1/4） -
java -XX:+PrintFlagsFinal显示MaxRAMPercentage已设为 75.0，但MaxHeapSize却远低于预期
实操建议：
- 进容器检查：
cat /sys/fs/cgroup/memory/memory.limit_in_bytes是否可读、数值是否匹配 K8s limit - 确认没显式关闭：
-XX:-UseContainerSupport会彻底禁用该机制 - 高内存容器（>32GB）慎用默认行为：JVM 可能因压缩指针（
UseCompressedOops）判断失败而强制回退到保守堆大小；此时需加-XX:-UseCompressedOops并确保 cgroup 可读
MaxRAMPercentage 只管堆，不管整个 JVM 进程内存
这是 OOMKilled 最隐蔽的根源。MaxRAMPercentage 控制的是 -Xmx（最大堆），但 JVM 实际内存占用 = 堆 + Metaspace + 线程栈 + DirectByteBuffer + CodeCache + GC 元数据等。这些都在 cgroup 限制范围内，超了就会被 Linux OOM Killer 杀掉。
举例：容器 limits.memory=4Gi，设 -XX:MaxRAMPercentage=75.0 → 堆约 3Gi。但若 Metaspace 动态涨到 512Mi、100 个线程 × 1Mi 栈 = 100Mi、Direct Buffer 再占 300Mi，总内存轻松突破 4Gi。
实操建议：
- 预留至少 20%~25% 的容器内存给非堆区域（尤其 Metaspace 和 Direct Buffer）
- 显式限制非堆内存：
-XX:MaxMetaspaceSize=256m、-XX:MaxDirectMemorySize=512m - 监控指标优先看
jvm_memory_used_bytes{area="nonheap"}和process_resident_memory_bytes，而非只盯堆
真正麻烦的不是怎么写对参数，而是当 MaxRAMPercentage 看似生效、堆大小也符合预期，进程却仍被 OOMKilled 时——那问题一定出在堆外内存的失控或 cgroup 信息未被准确识别，这两处最容易被忽略。
