docker中java应用jvm堆内存需与容器限制协同：启用-xx:+usecontainersupport并设-xx:maxrampercentage=75.0，预留非堆空间，显式entrypoint传参，避免cmd覆盖失效。
在 Docker 中运行 Java 程序时，JVM 堆内存配置不能照搬物理机习惯——容器有独立的内存限制（如 --memory=512m），而 JVM 默认按宿主机总内存分配堆，极易导致 OOMKilled。关键不是“设多大”，而是让堆大小与容器限制协同、留出非堆空间、避免硬编码。
显式声明启动命令，确保 JVM 参数真正生效
Docker 的 ENTRYPOINT 和 CMD 协作机制容易导致参数丢失。必须把 JVM 参数直接写进启动命令，而不是依赖覆盖式传参。
- ✅ 正确：用 JSON 数组格式，在
ENTRYPOINT中完整写出 java 命令和所有 JVM 参数ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-XX:+UseG1GC", "-jar", "/app.jar"] - ❌ 错误：
ENTRYPOINT ["java", "-jar", "/app.jar"]+CMD ["-Xmx512m"]—— CMD 不会合并到 ENTRYPOINT，只会整体替换，JVM 参数失效 - ? 提示：若需灵活调整，改用
JAVA_TOOL_OPTIONS环境变量（如ENV JAVA_TOOL_OPTIONS="-Xms256m -Xmx512m"），它会被 JVM 自动读取，但注意它对所有 JVM 子进程（如 jstack）也生效
用容器感知参数替代固定 -Xmx，适配不同环境
硬写 -Xmx512m 在测试/生产切换时要改镜像或命令；更优解是让 JVM 主动读取容器内存上限并按比例分配堆。
- JDK 8u191+ / JDK 10+ 默认开启
-XX:+UseContainerSupport，无需额外解锁 - 搭配
-XX:MaxRAMPercentage=75.0：表示堆最多占容器内存限制的 75%
例如容器限制--memory=1g→ JVM 堆自动设为约 768MB - 可选加
-XX:InitialRAMPercentage=50.0控制初始堆，减少启动期 GC - ⚠️ 验证是否生效：进入容器执行
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize，确认数值接近预期
为非堆内存预留空间，防止总内存超限
容器内存 = JVM 堆 + 元空间 + 线程栈 + 直接内存 + JVM 自身开销。只设 -Xmx 不够，常因元空间膨胀或线程过多导致 OOM。
- 限制元空间：
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m（避免动态扩张失控） - 减小线程栈：
-Xss256k（默认 1MB，微服务线程多时影响显著） - 约束直接内存：
-XX:MaxDirectMemorySize=128m（尤其用 Netty/NIO 时必加） - 估算公式参考：容器限制 ≥
-Xmx× 1.3 + 100MB（操作系统及 JVM 运行基础开销）
选对基础镜像，从源头压低内存基线
镜像体积大、依赖多，不仅拉取慢，还会增加运行时内存占用（如 glibc、调试工具等静态链接库）。
- 优先用
openjdk:17-jre-slim或openjdk:17-alpine，比 full 版本小 60%+，启动更快 - 务必采用多阶段构建：编译用 maven 镜像，运行仅 COPY JAR 到轻量 JRE 镜像，剔除源码、Maven 缓存、.class 文件等无用内容
- 避免使用
openjdk:latest或未标-slim/-alpine的镜像，它们可能含完整 JDK 工具链，徒增内存负担
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
