必须显式启用-XX:+UseContainerSupport，否则JVM按宿主机内存估算堆大小，90%的OOMKilled源于此；该参数在JDK 8u191+/10+默认启用但受-Xmx干扰，旧版本需手动解锁或不支持。
现代 JVM（如 HotSpot）从 Java 10 起默认启用容器感知能力，核心在于 -XX:+UseContainerSupport 参数。它不是简单开关，而是触发 JVM 主动读取 /sys/fs/cgroup/ 下的限制文件，并据此动态调整内存、CPU 等关键资源策略。
自动识别 cgroup 内存限制
JVM 启用该参数后，会优先检查 /sys/fs/cgroup/memory/memory.limit_in_bytes，而非读取宿主机的 /proc/meminfo。若该值为 9223372036854771712（即 -1），说明未设内存上限，JVM 回退到传统估算逻辑；若为具体数值（如 1073741824 表示 1GB），则作为“可用 RAM 基准”参与后续计算。
- 默认行为：Java 10+ 中该参数已默认开启，无需手动添加
- 显式启用更稳妥：尤其在 JDK 8u191+ 或 8u212+ 环境中，建议明确写入启动参数
- 禁用场景极少：仅当调试宿主机资源行为或兼容极老旧容器运行时才考虑关闭
堆内存按比例动态分配
单靠识别 cgroup 不足以防止 OOM，必须配合堆大小控制策略。JVM 使用 -XX:MaxRAMPercentage 将容器内存限制按百分比折算为 -Xmx 值：
- 设为
75.0：1GB 容器 → 堆上限 ≈ 768MB，为元空间、线程栈、直接内存等留出约 25% 余量 - 避免设为
100.0：JVM 非堆内存（如 CodeCache、Compressed Class Space）仍需空间，超限将直接触发 cgroup OOM Killer - 可搭配
-XX:InitialRAMPercentage和-XX:MinRAMPercentage控制初始堆行为，提升冷启动稳定性
CPU 资源协同适配
该参数同样激活对 CPU cgroup 的解析，主要影响 Runtime.availableProcessors() 返回值和 GC 线程数：
- 读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us与cpu.cfs_period_us，推算有效 CPU 配额（如 quota=200000, period=100000 → 2 核） - 据此设置并行 GC 线程数（如 G1 默认使用
availableProcessors的 25%～60%，避免线程过多争抢） - 若容器未设 CPU 限制（cfs_quota_us = -1），则 fallback 到宿主机核数，但此时建议额外配置
-XX:ActiveProcessorCount显式约束
验证是否生效的实操方法
不依赖日志或文档，直接在容器内运行诊断代码：
- 打印关键指标：
Runtime.getRuntime().maxMemory()应接近memory.limit_in_bytes × MaxRAMPercentage / 100 - 检查系统属性：
System.getProperty("java.vm.info")中含container字样，表示已进入容器模式 - 查看 JVM 启动日志：启用
-Xlog:gc+init可见类似Using VM: OpenJDK 64-Bit Server VM (container)的标识
