核心是让jvm主动识别容器内存限制，需显式启用-xx:+usecontainersupport并用-xx:maxrampercentage等参数按容器limit百分比动态设堆，同时限制metaspace、线程栈和direct memory以防oomkilled。
核心是让 JVM 主动识别容器内存限制，而不是按宿主机内存瞎分配。不调参时，JVM 可能给堆分 4GB，而容器只给了 512MB——结果不是 Java 报 OOM，而是内核直接 Killed process xxx (java)，日志里连堆栈都没有。
必须开启容器感知支持
JDK 8u191+ 和 JDK 10+ 原生支持 cgroup 内存读取，但很多 OpenJDK 镜像或旧版默认关闭。不加这个参数，JVM 就看不到容器 limit：
- -XX:+UseContainerSupport：强制启用容器资源识别（务必显式写上）
- 验证方式：启动时加
-XX:+PrintGCDetails，看 GC 日志首行是否出现类似-XX:MaxRAM=536870912 (512M)；若显示的是宿主机总内存（如 64G），说明没生效
用百分比动态设堆，别硬编码
固定值如 -Xmx512m 在多环境部署中极易错配；用百分比能随容器 memory limit 自动缩放：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- -XX:InitialRAMPercentage=60.0 和 -XX:MaxRAMPercentage=60.0：堆初始与上限都设为容器 memory limit 的 60%
- 60% 是经验安全值：预留 40% 给 Metaspace、线程栈（
-Xss）、Direct Buffer、CodeCache 等非堆开销 - 不建议超过 75%，否则元空间暴涨或线程数突增（比如 200+ 线程 × 1MB 默认栈）极易突破总 RSS 限
封住非堆内存泄漏口
即使堆只占 60%，其他部分失控照样触发 OOMKilled：
- -XX:MaxMetaspaceSize=256m：防止类加载器持续增长吃光内存
- -Xss256k：将单线程栈从默认 1MB 降至 256KB，对多数 Spring Boot 服务足够且显著降低线程总开销
- 若用 Netty 或大量 NIO 操作，额外加 -XX:MaxDirectMemorySize=128m，避免堆外内存失控
启动后必须验证实际效果
配完参数不验证 = 白配。关键检查点：
- 查 GC 日志：确认
MaxHeapSize ≈ 容器 limit × 百分比（允许几十 MB 偏差） - 进容器执行
jcmd $PID VM.flags | grep -E "(MaxRAM|MaxRAMPercentage|UseContainerSupport)"，确保所有参数已生效 - 用
docker stats观察 RSS 实际占用，对比容器 limit 是否长期逼近 100%
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
