Java应用在Docker中启动慢、OOMKilled主因是JVM未适配容器内存限制；需启用-XX:+UseContainerSupport（8u131+默认开）、显式设-Xmx/-Xms为容器内存的50%~75%，并选用eclipse-temurin等轻量镜像、多阶段构建、正确配置HEALTHCHECK与actuator端点。
Java应用跑在Docker里会不会启动慢、内存爆掉
会，但不是Docker的问题，是JVM没适配容器。Java 8u131+ 和 Java 10+ 默认仍按宿主机内存算堆大小，比如宿主机有32GB，-Xmx没显式设置就可能默认分到8GB，而容器只给了2GB内存限制——结果就是OOMKilled。
- Java 8u131+ 起必须加
-XX:+UseContainerSupport（默认已开启，但旧镜像可能关了） - 务必显式设置
-Xmx和-Xms，建议设为容器内存限制的 50%~75%，例如-Xmx1280m配合mem_limit: 2g - Java 10+ 默认启用容器感知，但若用
openjdk:8-jre-slim这类老基础镜像，仍需手动确认 JVM 版本和参数
选哪个OpenJDK Docker镜像最稳妥
别用 openjdk:8-jre 或 openjdk:11-jre 这种无后缀的“latest”标签，它们指向的可能是 Debian 基础镜像，体积大、漏洞多、启动慢。
- 生产首选
eclipse-temurin:17-jre-jammy（原 Adoptium），轻量、定期更新、支持 cgroup v2 - 若需 Alpine，用
eclipse-temurin:17-jre-alpine，但注意：Alpine 的 musl libc 可能导致某些 JNI 库（如 JNA）行为异常 - 绝对避开
java:8（已弃用）、openjdk:8-jdk（含 javac，镜像大且不必要）
Dockerfile里COPY jar包 vs. 构建时打包进镜像
推荐把构建好的 fat jar 直接 COPY 进镜像，而不是在 Dockerfile 里 RUN mvn package。前者构建快、层少、安全；后者会把整个 Maven 缓存、依赖、临时文件全塞进镜像，体积膨胀、复现难、易泄露凭证。
- 使用多阶段构建：第一阶段用
maven:3.8-openjdk-17编译，第二阶段用eclipse-temurin:17-jre-jammy仅运行 -
COPY target/*.jar app.jar后，用ENTRYPOINT ["java","-Xmx1280m","-jar","/app.jar"]，避免 shell 形式导致 PID 1 不是 Java 进程 - 不要
COPY . /app再RUN java -jar xxx.jar—— 容器启动即退出，且无法传参
Spring Boot应用在Docker里怎么调优日志和健康检查
默认 stdout 输出日志是对的，但 Spring Boot 的 /actuator/health 若没配好，Docker 的 HEALTHCHECK 会误判容器为 unhealthy。
立即学习“Java免费学习笔记（深入）”；
- 确保
management.endpoints.web.exposure.include=health,info，否则健康端点返回 404 - Dockerfile 中加：
HEALTHCHECK --interval=30s --timeout=3s --start-period=15s --retries=3 CMD curl -f http://localhost:8080/actuator/health || exit 1 - 日志别重定向到文件再挂卷，直接 stdout/stderr；用
logging.pattern.console控制格式，避免 ANSI 颜色码干扰日志采集器
容器化 Java 最容易被忽略的，其实是 JVM 参数和健康探针的耦合——一个配置错，K8s 就反复重启，查起来却像网络或代码问题。
