java微服务容器化应避免在运行镜像中安装完整jdk，优先选用eclipse-temurin:17-jre-slim等轻量jre镜像；通过多阶段构建分离编译与运行环境，显式设置jvm堆参数或启用容器感知，确保内存限制生效。
容器化微服务中不建议在每个容器里重复安装完整 JDK，而是按需选择轻量、安全、可复用的 Java 运行时方案。核心原则是：**JDK 仅用于构建，JRE 或精简 JDK 用于运行；生产环境优先使用发行版维护的镜像，避免自建或手动拷贝 JDK。**
选对基础镜像，别自己装 JDK
直接基于主流 OpenJDK 发行版的 Docker 镜像启动，省去安装、配置和安全更新负担。推荐使用：
-
Eclipse Temurin（官方推荐）：通过
eclipse-temurin:17-jre-slim或21-jre-alpine启动，体积小、TCK 认证、更新及时； -
Microsoft Build of OpenJDK：Azure 场景下默认支持自动 JVM 调优（如
jaz启动器），适合云原生部署； - Amazon Corretto 或 Azul Zulu：企业级长期支持（LTS），提供 glibc/musl 双版本适配。
避免使用 openjdk:17-jdk 这类含完整开发工具链的镜像——微服务运行时不需要 javac、jstack 等，只会增大镜像体积、延长拉取时间、增加攻击面。
构建与运行分离：多阶段构建更干净
利用 Docker 多阶段构建，在构建阶段用 JDK 编译打包，运行阶段只复制 JAR 和最小 JRE：
- 第一阶段用
maven:3.8.6-jdk-17拉依赖、编译、生成可执行 JAR； - 第二阶段用
eclipse-temurin:17-jre-slim，仅 COPY JAR 并运行； - 最终镜像不含 Maven、源码、.class 文件缓存，大小通常压缩到 100–200 MB 内。
内存与 JVM 参数要匹配容器限制
容器设置了内存上限（如 --memory=1g），但 JVM 默认不感知该限制，可能申请超限内存导致 OOM Kill。解决方式有：
- 显式设置堆参数：
java -Xms512m -Xmx512m -jar app.jar； - 启用容器感知（JDK 10+ 默认开启）：确保使用
-XX:+UseContainerSupport（现代镜像已内置）； - 用云原生启动器替代 java 命令：如 Azure 的
jaz、Quarkus 的java -Dquarkus.jvm=true，自动根据 cgroup 限制推导堆大小和 GC 策略。
特殊场景才考虑自定义 JDK
极少数情况需要定制 JDK，例如：
- 合规要求必须剔除特定加密模块；
- 嵌入式或边缘设备资源极度受限，需 jlink 构建最小运行时；
- 内部审计要求所有二进制组件来源可控，需从源码构建 Temurin。
此时应使用 jlink 或 jdeps 分析依赖，生成仅含所需模块的运行时镜像，并通过 CI 流水线统一构建、签名、推送，而非在 Dockerfile 中 apt install 或 curl + tar 手动安装。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
