1. 为什么我放弃了在物理机上裸装JDK刚入行那会儿每换一台开发机我都要重复一套固定动作去官网找JDK安装包、配JAVA_HOME、改PATH、装Maven、调settings.xml、再装个Tomcat或者Spring Boot的运行时。一套流程走下来顺利的话半小时不顺利的话光环境变量就能折腾一下午。最要命的是团队里每个人的机器环境都不一样你这边跑得好好的代码同事拉过去就报NoSuchMethodError或者UnsupportedClassVersionError排查半天发现是JDK版本差了半个小版本。后来我把整套Java开发环境搬进了Docker一个docker-compose up就能拉起JDK、Maven、数据库、中间件换机器只需要把配置文件拷过去。这篇文章就把我这几年攒下来的容器化Java环境搭建经验完整拆一遍从镜像选型到目录挂载从Maven私服配置到多版本JDK共存尽量把每个决策背后的理由讲清楚。不管你是刚接触Docker的新手还是想把手头环境标准化一下的老手应该都能直接抄作业。需要先说明一点容器化开发环境不是银弹。它的核心价值在于环境一致性和可复现性而不是性能。如果你追求极致的编译速度物理机裸装仍然有优势。但对于绝大多数日常开发、联调、CI场景Docker带来的收益远大于那点性能损耗。2. 镜像选型别一上来就docker pull openjdk很多人第一次搭Java容器环境下意识就是docker pull openjdk:8。这个操作本身没错但选哪个镜像、哪个Tag里面的门道比想象中多。选错了轻则镜像体积大几百兆重则遇到架构不兼容或者证书问题。2.1 三个主流JDK镜像源的取舍逻辑目前社区里常见的Java基础镜像主要有三类我把它们的实际使用体验整理成了一张表镜像来源典型Tag示例体积压缩后适用场景我的实际体验OpenJDK官方openjdk:17-slim约180MB通用开发、CI稳定但更新慢部分Tag已停止维护Eclipse Temurineclipse-temurin:17-jdk约200MB生产级开发社区活跃长期支持有保障Amazon Correttoamazoncorretto:17约190MB云上部署与AWS生态契合本地开发也够用我现在的默认选择是Eclipse Temurin。原因很直接它是Adoptium项目下的产物有明确的长期支持策略而且Docker Hub上的Tag维护得很勤快安全补丁跟得紧。OpenJDK官方镜像虽然经典但有些版本已经不再更新用久了心里不踏实。提示如果你所在团队对JDK来源有明确规范优先遵循团队规范。没有规范的话Temurin是当前比较稳妥的默认项。2.2-jdk、-jre、-slim这几个后缀到底怎么选这是新手最容易迷糊的地方。我见过有人为了体积小选了-jre结果进容器发现没有javac编译都跑不起来。-jdk包含完整的开发工具链有javac、jar、jdb等。开发环境必须选这个。-jre只有运行时体积小但没法编译。只适合跑已经打好的包。-slim基于更精简的基础镜像去掉了部分非必要工具。体积小但可能缺一些调试工具。-alpine基于Alpine Linux体积最小但用的是musl libc而不是glibc某些依赖本地库的Java应用会出问题。我的建议很明确开发环境一律用-jdk不要碰-jre和-alpine。-slim可以用但你要做好心理准备进去之后可能连vim和curl都没有调试的时候会有点难受。如果磁盘空间不是特别紧张直接用标准版-jdk最省心。2.3 多版本JDK共存的镜像策略实际项目里经常遇到这种情况老项目跑在JDK 8上新项目要用JDK 17。物理机上装两个JDK切换来切换去很烦Docker里就简单多了——一个版本一个镜像互不干扰。我的做法是给每个JDK版本打一个本地Tag比如myjava:8、myjava:17、myjava:21然后在docker-compose.yml里通过不同的service来区分。这样启动哪个项目就起哪个容器环境变量天然隔离不会出现我明明改了JAVA_HOME怎么还是老版本这种问题。3. 手把手搭建从零到能跑Spring Boot的完整链路光说理论没意思直接上操作。下面这套流程是我在多个项目里反复验证过的照着走基本不会翻车。3.1 目录结构规划先把挂载点想清楚在写任何Docker命令之前先把本地目录结构定下来。这一步偷懒后面挂载的时候就会乱。我习惯用这样的结构java-dev-env/ ├── docker-compose.yml ├── jdk17/ │ └── Dockerfile ├── maven/ │ ├── settings.xml │ └── repository/ # 本地仓库缓存挂载出来避免重复下载 ├── workspace/ # 代码目录挂载到容器内 └── scripts/ └── entrypoint.sh这里有几个关键决策需要解释为什么要把Maven本地仓库挂载出来因为容器是无状态的每次重建容器~/.m2/repository里的依赖就全没了。一个中型项目拉一次依赖可能要好几分钟反复重建容器的时间成本太高。挂载出来之后依赖只下载一次后续所有容器共享。为什么代码目录也要挂载这样你在宿主机上用任何IDE改代码容器里立刻就能看到。不需要在容器里装编辑器也不需要docker cp来回拷文件。settings.xml单独放而不是塞进镜像因为私服地址、镜像源这些配置经常变塞进镜像意味着改一次配置就要重新build。放在宿主机挂载改完重启容器就生效。3.2 Dockerfile编写把该装的工具一次装齐基于Temurin的JDK 17镜像我通常会再补一些开发常用工具。下面是我常用的DockerfileFROM eclipse-temurin:17-jdk # 换国内镜像源加速apt根据实际网络环境调整 RUN sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list || true # 安装常用工具 RUN apt-get update apt-get install -y --no-install-recommends \ git \ curl \ vim \ unzip \ rm -rf /var/lib/apt/lists/* # 设置工作目录 WORKDIR /workspace # 配置Maven假设Maven单独安装或通过包管理器 ENV MAVEN_HOME/opt/maven ENV PATH${MAVEN_HOME}/bin:${PATH} # 设置字符集避免中文乱码 ENV LANGC.UTF-8 ENV LC_ALLC.UTF-8 CMD [/bin/bash]这里有几个细节值得展开说字符集设置。LANGC.UTF-8这行看起来不起眼但如果你不设容器里处理中文文件或者输出中文日志的时候大概率会乱码。我踩过这个坑日志里全是问号排查了半天才发现是locale的问题。--no-install-recommends。这个参数能避免apt装一堆你用不到的推荐包镜像体积能小几十兆。开发环境虽然不差这点空间但养成习惯没坏处。Maven的安装方式。上面Dockerfile里我用了ENV指向/opt/maven但没写具体安装步骤因为Maven的安装方式有好几种。最省事的是直接用apt-get install maven但版本可能偏旧。想要指定版本的话可以下载二进制包解压ARG MAVEN_VERSION3.9.6 RUN curl -fsSL https://dlcdn.apache.org/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz \ | tar -xz -C /opt \ mv /opt/apache-maven-${MAVEN_VERSION} /opt/maven注意下载地址里的域名和路径可能随版本更新变化实际使用时先去官网确认当前可用的下载链接。如果网络环境访问官方源较慢可以换成对应的镜像源地址。3.3 docker-compose编排一条命令拉起整套环境单跑一个JDK容器用docker run就够了但实际开发往往还需要数据库、Redis这些配套服务。这时候docker-compose的优势就体现出来了。version: 3.8 services: java-dev: build: context: ./jdk17 dockerfile: Dockerfile container_name: java-dev volumes: - ./workspace:/workspace - ./maven/settings.xml:/root/.m2/settings.xml - ./maven/repository:/root/.m2/repository working_dir: /workspace tty: true stdin_open: true ports: - 8080:8080 - 5005:5005 # 远程调试端口 environment: - TZAsia/Shanghai networks: - dev-net mysql: image: mysql:8.0 container_name: dev-mysql environment: MYSQL_ROOT_PASSWORD: dev123456 MYSQL_DATABASE: devdb ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql networks: - dev-net networks: dev-net: driver: bridge这份编排文件里有几个点需要重点说明tty: true和stdin_open: true。这两行是让容器保持运行的关键。没有它们容器启动后执行完CMD就会退出你根本进不去。很多人第一次写compose文件发现容器起来就没了八成是漏了这两个配置。端口映射的选择。8080是应用端口5005是Java远程调试端口。远程调试这个特别有用——你可以在宿主机IDE里直接对容器内的应用下断点。配置方式是启动应用时加上java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 -jar app.jar然后在IDE里新建一个Remote JVM Debug配置连localhost:5005就行。时区设置。TZAsia/Shanghai这行不加的话容器内时间是UTC日志时间戳和你的本地时间差8小时排查问题的时候会很迷惑。网络配置。自定义一个dev-net桥接网络让Java容器和MySQL容器在同一个网络里。这样Java应用连数据库可以直接用服务名mysql作为主机名不用去查容器IP。3.4 启动与验证确认环境真的可用编排文件写好后启动命令很简单docker-compose up -d-d是后台运行。启动完成后进容器验证docker exec -it java-dev bash进去之后依次检查java -version # 确认JDK版本 javac -version # 确认编译器可用 mvn -version # 确认Maven可用 echo $JAVA_HOME # 确认环境变量如果这几条都正常输出说明基础环境没问题了。接下来可以试着编译一个项目cd /workspace/your-project mvn clean package -DskipTests第一次执行会下载大量依赖耐心等一会儿。下载完成后maven/repository目录里就会有缓存下次再编译就快多了。4. 那些让我熬夜排查的坑以及怎么绕过去环境搭起来只是第一步真正让人头疼的是各种意料之外的问题。下面这几个坑我都亲身踩过有的排查了大半个晚上。4.1 文件权限容器内创建的文件宿主机改不了这是挂载目录最经典的问题。容器里用root用户跑创建的文件属主是root。你在宿主机上用普通用户编辑就会提示权限不足。解决方案有两种方案一容器内创建与宿主机UID一致的用户。在Dockerfile里加ARG USER_ID1000 ARG GROUP_ID1000 RUN groupadd -g ${GROUP_ID} devuser \ useradd -m -u ${USER_ID} -g ${GROUP_ID} devuser USER devuser然后在compose文件里通过build.args传入你宿主机的UID和GID。查宿主机UID的命令是id -u和id -g。方案二启动容器时指定用户。在compose里加user: ${UID}:${GID}配合环境变量使用。这种方式更灵活不用重新build镜像。我一般用方案二因为改起来快。但要注意如果容器内用户没有/workspace的写权限还得提前在宿主机上把目录权限设好。4.2 Maven下载慢镜像源配置的正确姿势默认情况下Maven从中央仓库下载依赖国内访问速度很不稳定。配置镜像源是必须的。settings.xml里加这么一段mirrors mirror idaliyun-mirror/id mirrorOfcentral/mirrorOf nameAliyun Maven Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror /mirrors这里有个细节mirrorOf写central表示只代理中央仓库。如果你公司有私服私服的地址不要被这个镜像覆盖掉否则会出问题。更稳妥的写法是mirrorOf*,!your-private-repo/mirrorOf用!排除掉私服。提示镜像源地址可能会调整配置前建议先确认当前可用的地址。另外如果公司内网有自建的仓库服务优先用内网的速度更快也更稳定。4.3 容器内中文乱码不只是LANG的问题前面提过设置LANGC.UTF-8但有时候设了还是乱码。这种情况通常是两个原因一是宿主机文件本身的编码问题。如果源文件是GBK编码容器里按UTF-8读照样乱码。这种要在IDE里统一改成UTF-8。二是JVM的默认字符集。可以在启动参数里显式指定java -Dfile.encodingUTF-8 -jar app.jar从JDK 18开始file.encoding默认就是UTF-8了但如果你用的是JDK 8或11最好显式加上。4.4 远程调试连不上地址绑定的坑配远程调试的时候address*:5005和address5005是有区别的。前者绑定所有网络接口后者只绑定localhost。在容器里必须用*:5005否则宿主机连不进去。另外JDK 8和JDK 9的调试参数写法不一样JDK版本调试参数写法JDK 8-agentlib:jdwptransportdt_socket,servery,suspendn,address5005JDK 9-agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005JDK 8的写法在JDK 9上会报错反过来也一样。这个坑我在升级JDK版本的时候踩过应用直接起不来看日志才发现是参数格式问题。5. 让这套环境真正好用的几个进阶配置基础环境跑通之后还有一些配置能让日常开发效率再上一个台阶。这些不是必须的但加上之后体验会好很多。5.1 用.env文件管理可变配置compose文件里写死的端口、密码这些抽到.env文件里管理会更清爽JAVA_PORT8080 DEBUG_PORT5005 MYSQL_PORT3306 MYSQL_ROOT_PASSWORDdev123456 TZAsia/Shanghai然后在docker-compose.yml里用${JAVA_PORT}这样的变量引用。好处是不同开发者可以根据自己机器的情况调整端口不用改compose文件本身。.env文件记得加到.gitignore里避免把个人配置提交上去。5.2 给容器加资源限制默认情况下容器可以使用宿主机的全部资源。跑编译的时候Maven可能会吃掉大量内存导致宿主机卡顿。在compose里加上限制deploy: resources: limits: cpus: 4 memory: 4G reservations: cpus: 2 memory: 2Glimits是硬上限reservations是预留资源。具体数值根据你机器的配置调整。我一般给Java开发容器留4核4G编译大项目也够用了。5.3 常用命令封装成脚本每次进容器都要敲一长串docker exec -it java-dev bash时间长了也烦。在scripts目录下建几个脚本#!/bin/bash # scripts/into.sh - 进入开发容器 docker exec -it java-dev bash # scripts/build.sh - 在容器内编译项目 docker exec -it java-dev bash -c cd /workspace/$1 mvn clean package -DskipTests # scripts/restart.sh - 重启环境 docker-compose down docker-compose up -d给这些脚本加上执行权限然后软链到/usr/local/bin下就能像系统命令一样用了。5.4 镜像构建缓存优化Dockerfile里指令的顺序会影响构建缓存。把不常变的部分放前面常变的放后面。比如先装系统工具再配Maven最后才拷贝项目代码。这样改代码的时候不会触发前面几层的重新构建。另外apt-get update和apt-get install最好写在同一层RUN里中间用连接。分开写的话update那层可能被缓存导致install的时候用的是过期的包索引。6. 关于这套方案适用边界的实话说了这么多好处也得客观讲讲这套方案的局限。性能损耗是真实存在的。特别是文件IO密集的操作比如大量小文件的编译容器挂载卷的读写速度比宿主机直接操作要慢。如果你的项目特别大编译一次要十几分钟那容器化带来的时间开销可能就不太划算了。这种情况可以考虑把代码也打进镜像而不是挂载但那样就失去了实时编辑的便利。图形界面工具用不了。容器里跑不了需要图形界面的IDE你还是在宿主机上用IDE写代码容器只负责编译和运行。这个分工其实挺合理的但如果你期待的是整个开发环境都在容器里那可能会失望。学习成本不能忽略。Docker本身的命令、网络、存储这些概念对没接触过的人来说需要花时间理解。如果团队里有人完全不熟悉Docker推广这套方案的时候要做好培训准备。Windows和Mac上的差异。在Linux上跑这套方案是最顺的因为Docker原生支持。Windows和Mac上Docker实际上是跑在虚拟机里的文件挂载的性能损耗更明显路径映射的坑也更多。Windows上建议用WSL2后端体验会好很多。我个人的判断是团队规模超过3人、或者需要在多台机器之间切换开发环境、或者有CI/CD需求这套方案就值得投入时间搭建。如果只是个人做个小项目物理机裸装可能更省事。工具是为人服务的别为了用而用。最后分享一个我用了很久的小技巧把docker-compose.yml和相关的Dockerfile、配置文件一起放在项目根目录下的.devcontainer文件夹里然后在README里写清楚启动步骤。新同事拉下代码照着README敲两行命令就能跑起来省去了大量你帮我看看我环境怎么配的沟通成本。这个习惯坚持下来团队整体的环境问题能减少一大半。
