JVM读取的物理内存值决定容器内存识别是否生效，加-Xlog:os可查看日志中“OS: Physical memory”是否带“from cgroup”，若显示宿主机内存则识别失效，常见原因包括JDK版本过旧、cgroup v2兼容问题或禁用UseContainerSupport。
JDK 升级后容器内存识别是否生效，不能只看 -Xmx 配置有没有写，得看 JVM 实际读到的“物理内存”到底是宿主机的还是容器的——这个值直接决定默认堆大小、-XX:MaxRAMPercentage 计算基准、甚至 GC 策略触发条件。
怎么看 JVM 读到的物理内存值？
最直接的方式是用 -Xlog:os 打印底层 OS 层识别结果。在容器中启动时加这个参数：
java -Xlog:os:stdout -version
重点关注日志里类似这样的两行：
OS: Memory: 5368709120 bytes (5.00GB) — from cgroupOS: Physical memory: 5368709120 bytes (5.00GB)
如果出现 from cgroup，说明已正确读取容器 memory.limit_in_bytes；若显示的是宿主机总内存（比如 64GB），说明容器内存识别失效。
常见失效原因包括：
- JDK 版本太旧（
8u131之前完全不支持） - 用了
cgroup v2，但 JDK 是15之前版本（8u292/11.0.11等虽有 backport，但部分场景仍 fallback 到 v1） - 镜像里禁用了
UseContainerSupport（如手动加了-XX:-UseContainerSupport）
为什么 -XX:MaxRAMPercentage 算出来不对？
这个参数不是按 Pod 的 limits.memory 直接算的，而是用 JVM 读到的“物理内存” × 百分比。如果它读错了，结果必然错。
例如：Pod limits 设为 2Gi，但 JVM 读到的是宿主机 64Gi，则 -XX:MaxRAMPercentage=75.0 算出来是 48Gi，远超容器限制，OOM 必然发生。
验证方法很简单：
- 启动时加
-XX:+PrintGCDetails -Xlog:gc*:stdout，看日志开头的堆初始/最大值 - 或运行中用
jstat -gccapacity <pid></pid>查NGCMN/NGCMX（新生代）和OGCMN/OGCMX（老年代） - 对比计算：若容器
limits.memory=2G，JDK 8u222+ 默认应设堆≈1.5G（75%），而不是 16G
容器里跑 jinfo -flag MaxRAMPercentage <pid></pid> 返回 -1 怎么办？
这不代表参数没生效，而是说明该 flag 没被显式设置过——JVM 用的是内部默认值（JDK 8u191+ 默认 25.0，JDK 10+ 默认 25.0，但部分发行版如 Temurin 17+ 改为 75.0）。
真正要看的是最终生效的堆大小，不是 flag 是否“被设置”。更可靠的验证方式是：
- 用
ps aux | grep java确认启动参数里确实带了-XX:MaxRAMPercentage=75.0 - 查
/proc/<pid>/status</pid>中的MMU和VmRSS，观察 RSS 是否稳定在 limits × 1.1~1.3 倍内（超出太多说明非堆内存失控） - 在容器内执行
cat /sys/fs/cgroup/memory/memory.limit_in_bytes，确认返回值与预期 limits 一致（比如2147483648= 2Gi）
容易被忽略的一点：JDK 27 虽然默认用 G1，但它读取容器内存的逻辑和 JDK 17 一致；真正出问题的往往是旧镜像沿用了 8u131 那套半吊子 cgroup 支持，又没开 UseCGroupMemoryLimitForHeap，升级后反而因为默认行为更“激进”而暴露问题。
