容器中jvm需协同控制堆、非堆及系统开销内存：启用-xx:+usecontainersupport，用rampercentage动态设堆（65%为佳），并显式限制metaspace、xss、directmemory，确保总和≤容器limit×0.9。
在容器化环境里，JVM 堆内和堆外内存“双向挤爆”是高频故障：堆设得太大，留不出空间给元空间、线程栈、Direct Buffer；堆设得太小，又逼应用把大量数据往堆外塞，结果 RSS（常驻集）悄悄突破 memory limit，被 Kubernetes 的 OOM Killer 一刀杀掉——连异常都来不及抛。关键不是分别调两个参数，而是让堆、非堆、系统开销三者协同受控。
让 JVM 主动读取容器限制，别再猜宿主机内存
旧版 JVM 默认无视 cgroup，会按物理机总内存（比如 64G）算堆，默认分出十几 GB，而容器可能只给了 1GiB —— 这是绝大多数 OOMKilled 的起点。
- 必须加 -XX:+UseContainerSupport：JDK 8u191+ / JDK 10+ 支持，显式启用才能读取
memory.limit_in_bytes - 验证是否生效：启动时加 -XX:+PrintGCDetails，看 GC 日志首行是否出现类似
-XX:MaxRAM=1073741824 (1024M)；若显示的是 64G 或其他远超容器 limit 的值，说明没读到，需检查 runtime 是否禁用 cgroup v1/v2
用百分比动态定堆，60%～70% 是安全水位线
硬写 -Xmx512m 在多规格部署或弹性伸缩时极易失效。应让堆大小随容器 memory limit 自动缩放，并预留至少 30% 给非堆区域。
- -XX:InitialRAMPercentage=65.0 -XX:MaxRAMPercentage=65.0：初始堆 = 最大堆 = 容器 limit × 65%，避免扩容抖动；65% 是兼顾空间与安全的常用值
- 不建议超过 75%：一旦 Metaspace 突增、线程数翻倍或 Direct Buffer 批量分配，RSS 很快触顶
- 举例：容器 limit 设为 2GiB（2147483648 字节），65% ≈ 1395MB，JVM 实际
MaxHeapSize就会落在这个范围附近
堵住堆外三大“漏点”：元空间、线程栈、直接内存
堆只占一部分，真正容易失控的是堆外内存。这三块必须显式设限，且值要彼此协调：
- -XX:MaxMetaspaceSize=256m：防止类加载器泄漏或动态生成类（如 Spring CGLIB、Groovy 脚本）导致元空间无限增长
- -Xss256k：默认 1MB/线程，高并发下 200 个线程就吃掉 200MB；256k 可支撑约 800 线程，够大多数 Web 应用
-
-XX:MaxDirectMemorySize=512m：明确划清 NIO Direct Buffer 上限；推荐设为堆的 1/2～1/3（如堆 1395MB → 直接内存 512MB），并确保
堆 + MaxDirectMemorySize + MaxMetaspaceSize + Xss×maxThreads≤ 容器 limit × 0.9
运行时验证与持续盯防
配完不等于稳了，得用工具确认实际行为是否符合预期：
- 启动后立刻执行：
jcmd <pid> VM.native_memory summary</pid>（需提前加 -XX:NativeMemoryTracking=summary），查看 total、heap、class、thread、direct 各项占比 - 压测中监控
java.nio:type=BufferPool,name=direct的MemoryUsed，长期接近MaxDirectMemorySize就说明有泄漏 - 定期查
cat /sys/fs/cgroup/memory/memory.usage_in_bytes（容器内），对比 limit，RSS 持续 > 90% limit 就该预警
