1. 从零开始：搞定你的Windows开发环境

很多朋友一上来就想把Java11部署到服务器或者塞进Docker，结果第一步就卡住了。我自己带团队的时候，发现超过一半的“部署问题”，根源其实在本地开发环境就没配好。今天咱们就从最基础的Windows环境说起，手把手带你走一遍，确保你的“起点”就是正确的。

首先，你得把Java11的安装包弄到手。现在Oracle的JDK下载需要登录账号，对新手来说有点麻烦。我个人的习惯是，如果项目没有强制要求必须用Oracle JDK，我会优先选择OpenJDK的发行版，比如Adoptium（以前叫AdoptOpenJDK）或者Amazon Corretto。它们都是完全免费、开源且长期支持的，用起来更省心。你可以直接去Adoptium的官网（adoptium.net）找到JDK 11的安装程序，选择.msi格式的，下载下来双击安装就行，跟装个普通软件没区别。

安装过程中有个关键点：记住你的安装路径。默认情况下，它可能装在C:\Program Files\Eclipse Adoptium\jdk-11.0.xx-hotspot这样的目录里。这个路径等会儿配置环境变量要用到，最好复制下来存到记事本里。

安装完只是第一步，接下来是重头戏：配置环境变量。很多教程让你去“系统属性”里点来点去，其实有个更快的办法。按下 Win + R，输入 sysdm.cpl 回车，打开系统属性，切换到“高级”选项卡，点击“环境变量”。在“系统变量”区域，你需要新建一个变量，名字就叫 JAVA_HOME，值就是你刚才记下的那个JDK安装路径，比如 C:\Program Files\Eclipse Adoptium\jdk-11.0.xx-hotspot。这个变量本身不直接起作用，但它是一个“锚点”，很多Java工具和IDE（比如Maven、Gradle）都会读取它来定位JDK。

接下来，找到系统变量里已有的 Path 变量，选中它，点击“编辑”。在弹出的窗口里，点击“新建”，然后输入 %JAVA_HOME%\bin。这里有个小技巧，你可以通过“上移”按钮，把这个条目挪到靠前的位置。因为系统在Path里找命令时，是按顺序来的，放前面能确保它优先被找到。全部设置好后，一路点“确定”关闭所有窗口。

现在来验证一下。打开一个新的命令提示符（CMD）或者PowerShell窗口，输入 java -version 和 javac -version。如果一切顺利，你应该能看到类似 openjdk version "11.0.xx" 的输出。这里有个坑我踩过：如果你之前装过Java 8或者其他版本，并且没有彻底清理，可能会发现命令提示符里显示的版本号还是旧的。这通常是因为旧版本的路径还在Path变量里，并且排在了新版本前面。你需要回到Path变量里，把那些指向旧版本Java bin目录的条目删除或者调整顺序。

本地环境配好了，但你的项目可能还在用旧版本的Java配置。如果你用的是Maven，需要检查一下项目的pom.xml文件。我习惯用全局搜索的方式，在IDE里搜索 <maven.compiler.source> 和 <java.version> 这两个标签。把它们都改成 11。同时，确保 <maven.compiler.target> 也是 11。这样Maven在编译时就会使用Java 11的语法和特性。有时候你可能会遇到一些第三方库在Java 11下运行报错，提示不认识的JVM参数。这时候可以尝试在启动命令里加上 -XX:+IgnoreUnrecognizedVMOptions 这个参数，让JVM忽略那些它不认识的选项，这招经常能解决一些兼容性警告。

2. 进军Linux服务器：手动部署与版本管理

把本地开发好的应用扔到Linux服务器上，是每个后端开发者的必修课。这一步的关键在于“干净”和“可控”，避免把服务器环境搞得一团糟。我经历过好几次因为服务器上多个Java版本打架，导致应用半夜崩溃的惨剧，所以下面这套流程是我用血泪教训总结出来的。

首先，你得知道你的服务器是啥“品种”。连上你的服务器（比如用SSH），在终端里输入 cat /etc/os-release。这个命令会清晰地告诉你系统是Ubuntu、CentOS还是别的什么，以及具体的版本号。比如，你会看到 NAME="Ubuntu" 和 VERSION="20.04.6 LTS"。知道这个很重要，因为不同Linux发行版的包管理命令（apt vs yum）和软件源可能不一样。

接着，确认服务器的CPU架构。输入 arch 命令，它会返回 x86_64（也就是常说的64位x86）或者 aarch64（ARM架构）。下载JDK的时候必须选对架构，不然根本运行不了。

准备工作做完，开始安装。我不太推荐直接用系统自带的包管理器（如 apt install openjdk-11-jdk）来安装，因为这样安装的路径和版本管理有时候不那么透明。我更倾向于手动下载压缩包来安装，这样所有文件都在我指定的目录下，卸载和切换版本都非常方便。

去哪里下载呢？Oracle官网需要登录，而且有许可协议问题。我常用的两个国内镜像源是华为云镜像和清华大学开源软件镜像站。以华为云镜像为例，它的OpenJDK仓库地址是 https://mirrors.huaweicloud.com/openjdk/。找到11版本的目录，选择对应你系统架构的 .tar.gz 包。比如对于x86_64的Linux，文件名类似 openjdk-11.0.2_linux-x64_bin.tar.gz。

在服务器上，我们可以用 wget 命令直接下载到 /usr/local 目录，这个目录通常用来存放手动安装的软件：

sudo wget -P /usr/local https://mirrors.huaweicloud.com/openjdk/11.0.2/openjdk-11.0.2_linux-x64_bin.tar.gz

下载完成后，进入该目录并解压：

cd /usr/local
sudo tar -zxvf openjdk-11.0.2_linux-x64_bin.tar.gz

解压后会生成一个类似 jdk-11.0.2 的文件夹。为了以后管理方便，我通常会给它改个名，或者创建一个软链接：

sudo ln -s jdk-11.0.2 java-11

这样，/usr/local/java-11 就指向了我们的JDK安装目录，以后升级版本，只需要更换这个软链接的目标就行了，环境变量完全不用动。

现在配置环境变量。编辑 /etc/profile 文件，这个文件是所有用户共享的shell配置：

sudo vi /etc/profile

在文件末尾加上这么几行：

export JAVA_HOME=/usr/local/java-11
export PATH=$JAVA_HOME/bin:$PATH

注意 $PATH 放在后面，我们把 $JAVA_HOME/bin 加在了最前面，确保优先级最高。保存退出后，执行 source /etc/profile 让配置立即生效。最后，用 java -version 验证，应该能看到Java 11的版本信息。

但是，事情往往没这么顺利。有时候你会发现，明明配置了，java -version 显示的却是旧的Java 8。这通常是系统里预装了其他Java，并且通过 alternatives 机制设置了默认版本。你可以用 which java 看看 java 命令到底指向哪里，再用 ls -l 一路追踪软链接。解决方法就是手动更新 alternatives 或者像我上面说的，确保你的 PATH 变量里，新JDK的 bin 目录路径排在所有其他路径的最前面。彻底检查一遍 echo $PATH 的输出顺序，能解决90%的版本切换问题。

3. 拥抱容器化：用Docker封装Java11应用

手动部署在少数几台服务器上还能应付，一旦服务多了、需要弹性伸缩，就力不从心了。容器化，特别是Docker，成了现代部署的标配。它能把你的应用连同它的运行环境（Java 11）一起打包，做到“一次构建，到处运行”，彻底解决“在我机器上是好的”这个千古难题。

首先，你得为你的Java应用选择一个合适的基础镜像。直接去Docker Hub搜 openjdk:11 会出来很多。我一般会考虑几个选择：

• openjdk:11-jre-slim：这是官方镜像，基于Debian的slim版本，只包含Java运行环境（JRE），没有编译工具，镜像体积最小，适合纯运行。
• adoptopenjdk:11-jre-hotspot：Adoptium社区的镜像，提供不同的JVM实现（HotSpot/OpenJ9），选择丰富。
• amazoncorretto:11：Amazon Corretto的镜像，亚马逊维护的OpenJDK发行版，在AWS环境集成度好。

我个人的经验是，如果应用只是跑起来，用 -jre-slim 就够了，能显著减少镜像大小，上传下载都快。但如果你的应用在运行时需要用到 javac 等工具（比如某些动态编译场景），那就得选带JDK的标签，比如 openjdk:11-jdk-slim。

选好镜像后，编写 Dockerfile 就是核心了。我以一个最简单的Spring Boot应用为例（假设你的可执行Jar包叫 myapp.jar）：

# 使用轻量级的JRE基础镜像
FROM openjdk:11-jre-slim

# 设置工作目录，后面的命令都会在这个目录下执行
WORKDIR /app

# 将宿主机构建好的jar包复制到镜像中
COPY target/myapp.jar app.jar

# 声明容器运行时监听的端口（只是一个说明，实际映射在运行命令）
EXPOSE 8080

# 设置JVM参数，这是调优的关键
ENV JAVA_OPTS="-Xmx512m -Xms256m -XX:+UseG1GC"

# 启动应用，使用 exec 格式的 ENTRYPOINT 能让应用接收Unix信号，优雅关闭
ENTRYPOINT exec java $JAVA_OPTS -jar app.jar

这个 Dockerfile 很简单，但有几个细节值得说：

1. 镜像分层：COPY 命令会创建一个新的镜像层。如果你的 myapp.jar 经常变，而前面的基础镜像层不变，Docker可以利用缓存，加速构建。
2. JVM参数：通过环境变量 JAVA_OPTS 来设置非常灵活。在运行容器时，你可以随时覆盖它，比如 docker run -e "JAVA_OPTS=-Xmx1g" ...，而不需要重新构建镜像。
3. 优雅关闭：使用 exec java ... 这种形式，能让Java进程成为容器内的PID 1进程，从而可以正常接收 SIGTERM 等停止信号，执行资源清理，实现优雅关机，这对于Kubernetes这样的编排平台非常重要。

构建镜像的命令很简单：

docker build -t my-java-app:latest .

构建完成后，用 docker run -d -p 8080:8080 --name myapp my-java-app:latest 就能跑起来。但是，如何知道应用在容器里启动是否顺利呢？查看日志是必备技能：

# 查看最后100行日志
docker logs --tail 100 myapp
# 实时跟踪日志输出（类似 tail -f）
docker logs -f myapp

如果启动失败，日志里通常会打印出堆栈错误信息，这是你排查问题的第一手资料。

4. 多环境配置与持续集成实战

开发、测试、生产，每个环境的数据源地址、Redis连接、日志级别可能都不一样。把配置写死在代码里是灾难的开始。我们的目标是一套镜像，通过注入不同的配置，就能在各个环境运行。这才是真正的“一次构建，到处运行”。

最实用的方法是通过环境变量和外部配置文件挂载。Spring Boot天生就支持这个。假设你的应用使用 application.yml，你可以这样写：

server:
  port: 8080

spring:
  datasource:
    url: ${DB_URL:jdbc:mysql://localhost:3306/mydb}
    username: ${DB_USER:root}
    password: ${DB_PASS:123456}

logging:
  level:
    com.myapp: ${LOG_LEVEL:INFO}

配置里使用了 ${VAR_NAME:default_value} 的语法。如果环境变量 DB_URL 存在，就使用它的值；如果不存在，就使用冒号后面的默认值。

那么，在Docker运行时，我们就能非常灵活地注入配置：

docker run -d \
  --name myapp-prod \
  -p 8080:8080 \
  -e "DB_URL=jdbc:mysql://prod-db:3306/proddb" \
  -e "DB_USER=produser" \
  -e "DB_PASS=strongpassword" \
  -e "LOG_LEVEL=WARN" \
  my-java-app:latest

对于更复杂的配置文件（比如有几十个参数），一个个写 -e 太麻烦。我们可以事先把不同环境的配置写成 .env 文件，然后使用 --env-file 参数：

# 运行生产环境
docker run -d --env-file .env.production my-java-app:latest
# 运行测试环境
docker run -d --env-file .env.test my-java-app:latest

另一种常见需求是，需要把服务器上的某个目录（比如日志目录、上传文件目录）映射到容器内部。这时候要用到数据卷挂载（-v）：

docker run -d \
  -v /host/path/logs:/app/logs \
  -v /host/path/uploads:/app/uploads \
  my-java-app:latest

这样，容器内应用写入 /app/logs 和 /app/uploads 的文件，实际上都保存在宿主机的对应目录下，即使容器被删除，数据也不会丢失。

最后，我们把这一切串起来，放到一个CI/CD（持续集成/持续部署）流程里。以GitLab CI为例，一个简单的 .gitlab-ci.yml 可能长这样：

stages:
  - build
  - test
  - deploy

build-jar:
  stage: build
  image: maven:3.8-openjdk-11
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar

build-docker-image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

deploy-to-test:
  stage: deploy
  image: alpine/helm:latest
  script:
    - echo "使用kubectl或helm，将镜像 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA 部署到测试环境"
    - helm upgrade --install myapp-test ./chart --set image.tag=$CI_COMMIT_SHA --namespace test
  only:
    - develop

deploy-to-production:
  stage: deploy
  image: alpine/helm:latest
  script:
    - echo "部署到生产环境，可能需要手动批准"
    - helm upgrade --install myapp-prod ./chart --set image.tag=$CI_COMMIT_SHA --namespace production
  when: manual
  only:
    - main

这个流程自动化了从代码提交到部署的整个过程：在build-jar阶段用Maven镜像打包；在build-docker-image阶段构建Docker镜像并推送到仓库；最后根据不同的分支，自动部署到测试环境或手动触发部署到生产环境。镜像标签使用了Git提交的SHA，保证了每次部署的版本都是唯一且可追溯的。当你熟悉了这套从本地到云端容器化的完整流程后，就会发现，Java应用的部署不再是玄学，而是一套稳定、可重复的工程实践。