Java程序打包Docker镜像需显式配置JVM内存参数，因旧版JDK无法自动识别容器cgroup限制，导致OOM或启动失败。
Java程序打包成Docker镜像的关键步骤
直接用 java -jar 运行 JAR 包进容器，不加额外配置，大概率启动失败或退出。核心问题在于：JVM 默认会根据宿主机内存/CPU 设置堆大小，而 Docker 容器的 cgroup 限制对老版本 JDK（
- 必须显式设置 JVM 内存参数，例如
-Xms256m -Xmx512m，且-Xmx值不能超过容器内存限制（如docker run -m 768m） - JDK 8u191+ / JDK 10+ 支持自动识别容器内存限制，但需启用：
-XX:+UseContainerSupport（默认已开启，但低版本需确认） - 基础镜像优先选
eclipse/jetty、openjdk:17-jre-slim等 slim 版本，避免openjdk:17-jdk带编译工具增大体积 -
ENTRYPOINT推荐用 exec 形式：ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-jar", "/app.jar"]
，避免 shell 层导致 PID 1 不是 Java 进程，无法响应SIGTERM
Dockerfile 中 COPY 和 ADD 的实际区别与选择
COPY 和 ADD 都能复制文件进镜像，但行为差异直接影响构建可维护性和安全性。
-
ADD支持自动解压本地 tar 文件、支持远程 URL（不推荐，破坏构建可重现性），还可能触发隐式解压逻辑，造成意外行为 -
COPY严格按字面意思复制，无副作用，是明确、可控的选择 - 常见错误：把
ADD target/*.jar /app.jar写成ADD target/app-*.jar /app.jar—— 若匹配多个 JAR，Docker 会报错；应先确保构建产物唯一，再用COPY target/app.jar /app.jar - 多阶段构建中，从 build 阶段复制 JAR 到运行阶段时，必须用
COPY --from=build，不能省略--from
容器内 Java 进程收不到 SIGTERM 的原因和修复
Spring Boot 应用在 docker stop 后卡住几秒才退出，或直接被 SIGKILL 强杀，说明 JVM 没正常处理终止信号。根本原因是 PID 1 进程未转发信号。
- 若使用
sh -c "java -jar app.jar"启动，shell 成为 PID 1，但默认不转发SIGTERM给子进程 - 解决方案一：用 exec 启动（即
exec java -jar ...），让 Java 进程直接成为 PID 1 - 解决方案二：改用
tini作为 init 进程，在Dockerfile中：RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--", "java", "-jar", "/app.jar"] - 验证方式：容器运行后执行
docker exec -it，确认ps aux java进程 PID 是 1
Spring Boot 应用在 Docker 中的日志输出乱码或丢失
控制台日志在 docker logs 中显示为空、截断、或中文变问号，通常不是编码问题，而是输出缓冲导致。
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 默认使用 Logback，其
ConsoleAppender在非 TTY 环境下会启用immediateFlush=false，日志写入缓冲区后未及时刷出 - 解决方法：启动时加 JVM 参数
-Dlogback.stdout.buffered=false，或在logback-spring.xml中显式配置：
true - 避免用
System.out.println()输出关键日志——它不受 Logback 控制，且默认行缓冲，在容器中极易丢失 - 若仍乱码，检查基础镜像是否缺失中文字体或 locale（如
openjdk:17-jre-slim默认无en_US.UTF-8），可追加：RUN apt-get update && apt-get install -y locales && locale-gen en_US.UTF-8
