JVM必须显式启用-XX:+UseContainerSupport才能正确识别cgroup限制，否则按宿主机内存估算堆大小，导致90%的OOMKilled；该参数在JDK 8u191+/10+默认启用但受-Xmx干扰，在旧版本需手动解锁或不支持。
必须显式启用 -XX:+UseContainerSupport，否则 JVM 会按宿主机内存估算堆大小，90% 的 OOMKilled 都源于此被忽略。
UseContainerSupport 在不同 JDK 版本的行为差异
它不是“开或不开”的简单开关，而是和 JDK 版本强绑定的感知能力：
- JDK 8u191+ 和 JDK 10+：默认已启用，但仅当未显式设置
-Xmx时才生效；一旦写了-Xmx512m，JVM 就彻底忽略 cgroup 限制 - JDK 8u131–u190：需手动加
-XX:+UnlockExperimentalVMOptions -XX:+UseContainerSupport - JDK 8u121 及更早：不支持，必须用已废弃的
-XX:+UseCGroupMemoryLimitForHeap（且仅限内存，无 CPU 感知）
验证是否生效最直接的方式是启动时加 -XX:+PrintGCDetails 并观察日志中 MaxHeapSize 是否接近容器内存限制 × MaxRAMPercentage，而不是宿主机总内存的 1/4。
为什么只开 UseContainerSupport 还不够？
开启后只是“能读”，不代表“会用”——JVM 还需要明确知道堆该占多少比例：
-
-XX:MaxRAMPercentage=75.0是关键：它告诉 JVM “堆最多用容器可用内存的 75%”，这个“可用内存”只有UseContainerSupport启用后才从/sys/fs/cgroup/memory/memory.limit_in_bytes读取 - 若同时设了
-Xmx，比如-Xmx1g，则MaxRAMPercentage完全失效，JVM 回退到传统模式 - 推荐搭配
-XX:InitialRAMPercentage=50.0，避免初始堆过小触发频繁 GC，尤其在冷启动场景
示例命令：java -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0 -jar app.jar
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
CPU 配额同样依赖 UseContainerSupport，但容易被忽视
很多人以为内存配好就万事大吉，其实 CPU 限额不感知会导致线程调度失衡、GC 线程数爆炸、甚至被 K8s throttled：
- JVM 会从
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us计算出有效 CPU 核心数（如 quota=50000, period=100000 → 0.5 核） - 据此自动调整并行 GC 线程数（
ParallelGCThreads）、JIT 编译线程数等，避免争抢 - 若未启用
UseContainerSupport，JVM 仍按宿主机/proc/cpuinfo的物理核数分配，比如宿主机 32 核、容器只给了 1 核，JVM 却起 32 个 GC 线程
可通过 jstat -gc <pid></pid> 查看 LGCC（Last GC Cause）是否频繁为 Allocation Failure，结合 top -H -p <jvm-pid></jvm-pid> 观察线程数是否远超容器 CPU limit，就是典型征兆。
Off-Heap 内存不受 UseContainerSupport 控制，必须单独约束
UseContainerSupport 只管堆（Heap），而 Netty 的 DirectByteBuffer、JNA、JIT code cache、Metaspace 等都属于 Off-Heap，它们不走 GC，也不受 MaxRAMPercentage 管辖：
-
-XX:MaxDirectMemorySize=256m必须显式设置，否则默认等于-Xmx，极易突破容器内存 limit -
-XX:MaxMetaspaceSize=256m推荐设，避免类加载过多导致元空间无限膨胀 - Kubernetes 中建议把
limits.memory设为heap + 20%~30% off-heap buffer，例如堆设 768Mi，则容器 limit 至少 1Gi
最容易被忽略的是：即使所有 JVM 参数都配对了，netty-transport-native-epoll 或 grpc-netty-shaded 这类库仍可能绕过 JVM 约束直接 malloc，最终导致 OOMKilled —— 此时必须靠 memory.limit_in_bytes 的硬限制兜底，而非依赖 JVM 自觉。
