jvm需自动感知容器内存限制并动态设堆，启用-xx:+usecontainersupport后用-xx:maxrampercentage=60.0等参数按百分比分配堆，确保maxheapsize≈limit×60%，并配-xx:maxmetaspacesize、-xss等防非堆超限。
在容器环境里，JVM 堆内存若超出容器的 memory limit，Kubernetes 会直接触发 OOMKilled，进程被强制终止——这不是 JVM 抛出 OutOfMemoryError，而是系统级杀进程，无法捕获、无法兜底。要避免这种情况，核心不是“手动对齐”，而是让 JVM **自动感知容器内存限制，并把堆大小严格控制在 limits 范围内**，同时预留合理开销空间。
启用容器感知支持（必须开启）
从 JDK 8u191、JDK 10 起，JVM 支持通过 cgroup 读取容器内存上限。必须显式启用：
-
-XX:+UseContainerSupport：开启容器资源感知（JDK 10+ 默认开启，但建议显式写上，尤其在旧版 JDK 或 OpenJDK 衍生版本中） - 不加此参数时，JVM 仍按宿主机总内存计算堆（比如宿主机 64G，容器 limit 1G，它仍可能默认分 16G 堆），极易触发 OOMKilled
用百分比动态设定堆边界（推荐方式）
避免硬编码 -Xmx512m 这类固定值，改用基于容器 memory limit 的百分比参数，确保堆随 limits 变化自动伸缩：
-
-XX:InitialRAMPercentage=60.0：堆初始大小 = 容器 memory limit × 60% -
-XX:MaxRAMPercentage=60.0：堆最大大小 = 容器 memory limit × 60% - 两个值设为一致，可避免堆动态扩容带来的 GC 波动；60% 是兼顾堆空间与非堆开销（Metaspace、CodeCache、线程栈、Direct Buffer 等）的安全值
- 不建议超过 75%，否则一旦其他内存组件突增（如大量线程或 NIO buffer），极易突破容器 limit
验证是否生效（关键一步）
光配参数不够，得确认 JVM 实际读到的内存上限是否正确：
- 启动时加
-XX:+PrintGCDetails -XX:+PrintGCDateStamps，GC 日志首行会显示类似：
-XX:MaxRAM=1073741824 (1024M), -XX:MaxRAMFraction=1, -XX:MaxRAMPercentage=60.0 → MaxHeapSize = 644245094 (614M) - 检查日志中
MaxHeapSize是否 ≈ 容器 limit × 所设百分比（允许少量字节偏差） - 若仍显示宿主机总内存（如 64G），说明
UseContainerSupport未生效，需检查 JDK 版本或容器 runtime 是否禁用了 cgroup v1/v2 接口
补充防护：预留非堆空间 + 防止误超限
即使堆设为 60%，仍可能因元空间暴涨、线程数过多或堆外内存泄漏导致整体 RSS 超限。建议组合配置：
-
-XX:MaxMetaspaceSize=256m：限制元空间，防止其无限增长 -
-Xss256k：减小单线程栈，默认 1M，高并发场景下几十个线程就吃掉几百 MB -
-XX:+UseG1GC -XX:MaxGCPauseMillis=200：G1 更适合容器环境，可控停顿，避免 CMS 或 Parallel GC 在堆紧张时引发长时间 STW 导致响应延迟激增 - K8s 中
requests.memory应略小于limits.memory（如 limit=1Gi，request=900Mi），给调度器和节点组件留余量
