不用——但写代码、编译、调试仍需本地JDK；Docker镜像自带JDK仅解决运行时隔离，IDE和mvn等构建工具依赖本地JDK；省掉的是服务器JDK安装，非开发机。
Java应用用Docker打包后，本地开发环境还用不用装JDK？
不用——但有前提。Docker镜像里自带JDK（比如 openjdk:17-jre-slim），运行时完全隔离；但你在写代码、编译、调试时仍需本地JDK，因为IDE（如IntelliJ）和构建工具（mvn compile）不跑在容器里。
常见误区是以为“用了Docker就彻底告别JDK”，结果 mvn clean package 直接报错：java: command not found。真正能省掉的是目标服务器上的JDK安装步骤，不是你开发机上的。
build.gradle里没配jib或dockerfile，怎么让Java项目生成Docker镜像？
不能自动。Gradle本身不生成镜像，必须显式引入构建方案：
- 用
jib插件（推荐）：不依赖Docker daemon，直接推镜像到registry，适合CI/CD - 手写
Dockerfile+gradle build产出jar，再docker build -t myapp . - 用
docker-compose build配合build: context指向含Dockerfile的目录
漏掉任一环节（比如忘记 COPY jar包、或JRE路径写成 /usr/lib/jvm/java-11-openjdk-amd64 却用了ARM镜像），就会出现 exec user process caused: no such file or directory —— 实际是动态链接库不匹配，不是文件真丢了。
立即学习“Java免费学习笔记（深入）”；
Spring Boot的application.yml在Docker里怎么覆盖配置？
优先级顺序固定：命令行参数 > 环境变量 > application.yml（jar包内）> application.yml（外部挂载）。关键点在于环境变量名转换规则：
-
spring.profiles.active→SPRING_PROFILES_ACTIVE -
server.port→SERVER_PORT - 嵌套属性如
logging.level.com.example→LOGGING_LEVEL_COM_EXAMPLE（点变下划线，小写）
挂载外部配置时别用 volume 覆盖整个 /app，否则可能把jar删了；正确做法是 docker run -v $(pwd)/config:/config -e SPRING_CONFIG_LOCATION=file:/config/，再在 /config/application.yml 里只写要覆盖的项。
Java进程在Docker里OOM被kill，是不是该加-Xmx？
不一定，甚至可能更糟。Docker容器内存限制（--memory=512m）和JVM堆设定是两层控制：
- 没设
-Xmx：JVM默认按宿主机内存算堆大小（比如宿主机64G，它就分16G），远超容器limit，触发OOMKiller - 硬设
-Xmx400m：看似安全，但JVM元空间、直接内存、线程栈等还会额外吃内存，仍可能超限 - 最佳实践：用JDK 8u191+/10+ 的容器感知参数：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，让JVM自动按容器cgroup limit算可用内存
验证是否生效：进容器执行 java -XX:+PrintFlagsFinal -version | grep MaxRAM，看 MaxRAMPercentage 是否被识别，以及 MaxHeapSize 数值是否接近容器limit × 75%。
容器化不是配置甩手掌柜，Java的内存模型和Linux cgroup的交互细节，稍不注意就卡在“为什么本地跑得好，一上Docker就崩”。
