关键是要让JVM与容器内存限制对齐：启用-XX:+UseContainerSupport，用-XX:MaxRAMPercentage=75.0动态设堆，限制元空间、线程栈和直接内存，并通过ENTRYPOINT显式声明参数，选用slim/alpine基础镜像。
关键不是堆设多大，而是让 JVM 和容器内存限制真正对齐——堆要留余量、非堆要设上限、参数得写进启动命令里，否则再小的 -Xmx 也救不了 OOMKilled。
用容器感知参数替代硬编码 -Xmx
固定写 -Xmx512m 在测试/生产切换时得改镜像或启动命令，容易漏配。更稳妥的方式是让 JVM 主动读取容器内存上限并按比例分配堆：
- 启用容器支持：-XX:+UseContainerSupport（JDK 8u191+ 默认开启，无需额外解锁）
- 设堆占容器内存比例：-XX:MaxRAMPercentage=75.0（例如 --memory=1g → 堆约 768MB）
- 可选控制初始堆：-XX:InitialRAMPercentage=50.0，减少启动期 GC 频率
验证是否生效：进容器执行 java -XX:+PrintFlagsFinal -version | grep MaxHeapSize，确认数值接近预期值。
为非堆内存划边界，防元空间/线程栈/直接内存失控
容器内存 = JVM 堆 + 元空间 + 线程栈 + 直接内存 + JVM 自身开销。只设 -Xmx 不够，常见超限原因其实是这些“堆外”部分膨胀：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 限制元空间：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m（避免类加载过多导致无限扩张）
- 压缩线程栈：-Xss256k（默认 1MB，高并发场景下省出大量内存）
- 约束直接内存：-XX:MaxDirectMemorySize=128m（Netty/NIO 必加，否则可能突破容器限制）
估算公式参考：容器限制 ≥ -Xmx × 1.3 + 100MB（含操作系统及 JVM 运行基础开销）。
显式声明 ENTRYPOINT，确保 JVM 参数不被覆盖
Docker 的 ENTRYPOINT 和 CMD 协作机制容易导致参数丢失。CMD 不会合并到 ENTRYPOINT，只会整体替换：
- ✅ 正确写法（JSON 数组格式）：
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-XX:+UseContainerSupport", "-jar", "/app.jar"] - ❌ 错误写法：
ENTRYPOINT ["java", "-jar", "/app.jar"]+CMD ["-Xmx512m"]→ JVM 参数失效
如需灵活调整（比如不同环境调参），可用 ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75.0"，它会被 JVM 自动读取，但注意对所有子进程（如 jstack）也生效。
选轻量基础镜像，从源头压低内存基线
镜像体积大、依赖多，不仅拉取慢，还会增加运行时内存占用（如 glibc、调试工具等静态链接库）：
- 优先用 openjdk:17-jre-slim 或 openjdk:17-alpine，比 full 版本小 60%+，启动更快
- 进阶可尝试 jlink 构建最小 JRE，仅保留应用所需模块，镜像体积可压至 150MB 以内
- 避免使用包含完整 JDK 的镜像（如 openjdk:17-jdk）跑纯运行时应用
搭配 --memory=1g --memory-swap=1g 强制物理内存硬上限并禁用 swap，防止因堆外内存增长拖垮宿主机。
