Linux 安装 JDK 与 Maven：环境变量、多版本共存与非交互式环境避坑

新机器到手，第一件事往往不是写代码，而是把 Linux 上的 JDK 和 Maven 装利索。这件事看起来简单——解压、配环境变量、验证，三步走完似乎就结束了——但我见过太多人在这三步里栽跟头：装完java -version能跑，mvn -v却报 JAVA_HOME 不对；本地跑得好好的，一提交到构建机上就找不到命令；想换个 JDK 版本，结果把系统里其他依赖 Java 的服务全弄挂了。这篇就把我在 Linux 上安装 JDK 和 Maven 的完整流程摊开讲，从版本选择、目录规划、环境变量写法，到多版本共存、非交互式环境失效这些真正让人头疼的问题，一条条过一遍。内容偏实操，命令和配置都能直接抄，适合刚接触 Linux 服务端环境的新手，也适合已经装过几次但总在细节上翻车的朋友对照排查。

1. 开工之前：先搞清楚你要装哪个 JDK、装到哪

1.1 系统源里的 JDK 为什么经常不能用

很多人第一反应是打开包管理器，一条安装命令搞定。这条路在桌面环境上问题不大，放到服务端就未必合适。主流发行版的软件源为了兼容性，收录的 JDK 版本往往偏保守，尤其是那些生命周期长的发行版，源里的默认版本可能落后好几个大版本。你按官方文档要求用 JDK 17 编译的项目，在源里只能找到 JDK 11，编译直接报不支持的类文件版本。

更麻烦的是包管理器安装的 JDK 会往系统里塞一堆东西：/usr/lib/jvm下多个目录、/etc/alternatives里一堆软链接、还有各种openjdk-xx-jre-headless之类的依赖包。这些在正常使用时不碍事，一旦你要清理重装，就得花时间搞清楚哪些能删、哪些删了会影响别的软件。我遇到过一台机器上同时存在三个不同来源的 JDK，which java指向的路径和JAVA_HOME指向的路径根本不是同一个，排查了半天才发现是之前装某个软件时被顺带装上的。

所以我的习惯是：服务端的 JDK 一律手动下载官方压缩包，解压到独立目录，用软链接管理版本。好处是来源清晰、版本可控、卸载就是删目录，不会污染系统包管理器的状态。

1.2 手动安装与包管理器安装的取舍对照

不是说包管理器一无是处。小规模试用、临时跑个脚本、容器基础镜像里需要个 JRE，用包管理器最省事。判断标准很简单：这个东西要不要长期维护、要不要精确控制版本。要，就手动装。

表格里最后一行是我最看重的。构建机这种东西，最怕的就是环境漂移——今天装的是这个版本，明天运维重装系统变成了另一个版本，同一个 commit 编译出来的东西都不一样了。手动装 + 固定目录 + 写进配置管理脚本，才能保证环境可复现。

1.3 安装目录规划：别把东西丢在 /tmp

选目录这件事，新手最容易随手扔。下载到/tmp，解压到/tmp，配完环境变量跑通了，重启机器一看全没了——因为很多发行版会把/tmp配置成重启清空，甚至挂载时带noexec参数，解压出来的二进制根本没法执行。

我一般用这几个位置，按优先级排：

• /opt：第三方独立软件的惯例位置，JDK、Maven 这类自解压的绿色包放这里最合适，目录名带版本号，比如/opt/jdk-17.0.9、/opt/apache-maven-3.9.6。
• /usr/local：如果你所在团队习惯把自编译、自安装的东西统一放这里，那跟着团队走，别自成一套。
• 用户主目录下的~/tools或~/.local：只有当前用户需要、没有 root 权限时的选择，缺点是换用户就失效。

我倾向于/opt配合一个不带版本号的软链接，比如/opt/java指向/opt/jdk-17.0.9，/opt/maven指向/opt/apache-maven-3.9.6。所有环境变量、脚本、服务配置一律引用软链接路径，将来升级只需要改软链接指向，其他配置文件一个字都不用动。这套做法我在几台机器上用了好几年，升级 JDK 从 11 到 17 的时候，改一条ln -sfn命令就完事，业务配置零改动。

注意：解压前先看一眼磁盘余量。JDK 解压后通常三五百兆，Maven 一百多兆，加上后续依赖仓库的占用，/opt所在分区至少留出几个 G。用df -h /opt确认一下，别装到一半空间不足留下半拉子目录。

2. JDK 落地实操：从确认环境到验证通过

2.1 第一步：摸清系统底细与残留 Java

动手之前先做体检，这一步能省掉后面大量返工。

确认架构，决定下载哪个包：

uname -m

输出x86_64就是常见的 64 位 Intel/AMD 架构，输出aarch64就是 ARM 架构。这两种的 JDK 包完全不同，下错了解压出来执行会报“无法执行二进制文件”，而且这个报错信息很不直观，新手容易误以为是权限问题。顺手看一眼系统版本：

cat /etc/os-release

然后查一下机器上是不是已经有 Java 了：

which java java -version readlink -f $(which java)

三条命令分别看：命令在哪、版本是多少、真实文件在哪。重点看第三条，因为系统里常见的做法是/usr/bin/java是个软链接，链到/etc/alternatives/java，再链到真正的 JDK 目录。三级跳下来才能看到真身。

如果确认机器上装过 JDK 且你打算替换，别急着删。先记录下来原来指向哪，万一某个老服务依赖它，你还得还原回去。我的做法是保留旧版本目录，只改软链接和JAVA_HOME，旧目录留着占几百兆空间，但换来的是随时可以切回去的安全感。

2.2 下载包与完整性校验

从 JDK 发行方官网的下载页拿到 Linux 64 位压缩包，文件名通常形如jdk-17.0.9_linux-x64_bin.tar.gz。这里有个容易忽略的点：要下 JDK，不是 JRE。JRE 只有运行时，没有javac，装完你会发现 Maven 编译直接失败。下载页上这两个包挨得很近，下错的人不在少数。

下完先校验，别嫌麻烦：

sha256sum jdk-17.0.9_linux-x64_bin.tar.gz

拿输出的哈希值和官网页面上公布的校验值比对，一致再往下走。大文件下载中断、被中间设备改写、镜像同步延迟，都会导致包损坏。不校验直接解压，运气不好就是解压报错或者解压出来但跑不起来，那时候再回头查原因，成本高得多。顺手看一眼文件大小，ls -lh，如果只有几百 K，那基本是下到了一个错误页面而不是安装包。

2.3 解压、目录规范化与软链接

把包放到/opt下解压：

sudo tar -xzf jdk-17.0.9_linux-x64_bin.tar.gz -C /opt

解压出来的目录名一般就是jdk-17.0.9，正好符合我们带版本号的命名习惯。如果名字里带了平台后缀，改一下更清爽：

sudo mv /opt/jdk-17.0.9_linux-x64 /opt/jdk-17.0.9

如果是用普通用户解压而不是 root，可能会遇到属主警告。加--no-same-owner参数可以避免：

tar --no-same-owner -xzf jdk-17.0.9_linux-x64_bin.tar.gz -C /opt

建立软链接：

sudo ln -sfn /opt/jdk-17.0.9 /opt/java

-sfn三个参数的组合值得说一下：s建软链接，f强制覆盖已存在的同名链接，n表示如果目标是软链接就当成普通文件处理而不是跟进去。少了n，当/opt/java已经是个指向目录的软链接时，命令会试图在目标目录里再建一个链接，结果变成一个套娃，非常隐蔽。

权限也要顺手处理。如果 JDK 只给特定用户用：

sudo chown -R deploy:deploy /opt/jdk-17.0.9

如果是给整机所有用户用，保持 root 属主、目录权限 755 即可，别人只能读和执行，不能改。

2.4 JAVA_HOME 与 PATH 的写法

这一步是全场最容易出事的地方。我推荐写一个独立的环境脚本文件，放在/etc/profile.d/下：

sudo tee /etc/profile.d/java.sh > /dev/null <<'EOF' export JAVA_HOME=/opt/java export PATH=$JAVA_HOME/bin:$PATH EOF

为什么不用直接往/etc/profile里追加？因为/etc/profile是系统文件，很多发行版的升级流程会检查它的改动，你可能在升级时被提示合并冲突。而/etc/profile.d/下的独立脚本是官方预留的扩展点，登录时会被自动 source，互不干扰，将来卸载直接删文件就行。

写法的两个关键点：

第一，PATH里$JAVA_HOME/bin必须放在前面。如果你写成export PATH=$PATH:$JAVA_HOME/bin，那么当系统里已经存在/usr/bin/java时，shell 会优先命中系统的那个，你配的 JDK 压根不生效。表现出来就是JAVA_HOME看着是对的，java -version却是另一个版本。这个坑我被坑过不止一次。

第二，不要用JAVA_HOME=/opt/java/带尾斜杠的写法。有些脚本会自己拼$JAVA_HOME/bin/java，多一个斜杠变成双斜杠，绝大多数情况下能用，但少数工具的路径解析逻辑会出问题。统一不带尾斜杠，省心。

写完立刻生效：

source /etc/profile.d/java.sh

2.5 验证清单与几个容易翻车的细节

别只看java -version一行输出就收工，按这份清单过一遍：

echo $JAVA_HOME which java java -version javac -version

四项都对上才算真的配好了。javac那行尤其重要，它能验证你装的是 JDK 而不是 JRE，同时也能验证PATH里确实包含$JAVA_HOME/bin。

再补一个更彻底的验证，直接让 Java 自己报告它的家在哪：

java -XshowSettings:properties -version 2>&1 | grep java.home

输出的java.home应该等于你配置的JAVA_HOME加上运行时目录。如果两者对不上，说明环境变量和实际执行的 Java 不是同一套，赶紧回头查。

这里说一个我踩过的坑：某些发行版的登录脚本会在~/.bashrc里再设一次JAVA_HOME，指向另一个版本。因为~/.bashrc在/etc/profile.d/之后加载，会把你刚配的覆盖掉。表现就是 root 用户下一切正常，切成部署用户就变了版本，非常迷惑。排查方法是：

grep -rn "JAVA_HOME" ~/.bashrc ~/.bash_profile ~/.profile /etc/profile /etc/profile.d/ 2>/dev/null

把结果从头看一遍，记住后加载的覆盖先加载的这个顺序，问题就一目了然。

3. Maven 安装：不是解压完就完事

3.1 Maven 与 JDK 的版本对应关系

Maven 本身是 Java 写的，它需要先有一个 JDK 才能跑起来。所以顺序不能颠倒：先把 JDK 装好并验证通过，再来装 Maven。

版本匹配上，近几年的 Maven 3.8、3.9 系列要求 JDK 8 及以上。但这只是“能跑起来”的底线，实际项目里还得看编译插件的目标级别。比如你用 JDK 17 跑 Maven，但项目的maven.compiler.target还写着 1.8，那编译出来的是 Java 8 字节码，能跑但用不上新特性；反过来，项目写的是 17 而你的 Maven 跑在 JDK 11 上，就会看到那句经典的“不支持发行版本 17”。

我一般建议让 Maven 运行所用的 JDK 和项目编译的目标 JDK 保持一致，或者至少运行环境不低于目标版本。省掉很多莫名其妙的编译问题。

3.2 安装流程与权限处理

流程和 JDK 几乎一样：

sudo tar -xzf apache-maven-3.9.6-bin.tar.gz -C /opt sudo mv /opt/apache-maven-3.9.6 /opt/apache-maven-3.9.6 sudo ln -sfn /opt/apache-maven-3.9.6 /opt/maven

注意下载的包名里要有-bin，不要下成-src或者-bin.zip。-src是源码包，需要自己构建，纯属给自己找麻烦；.zip在 Linux 上当然也能解，但多一层东西没必要。

环境变量同样丢到profile.d：

sudo tee /etc/profile.d/maven.sh > /dev/null <<'EOF' export MAVEN_HOME=/opt/maven export PATH=$MAVEN_HOME/bin:$PATH EOF source /etc/profile.d/maven.sh

M2_HOME这个变量你可能在一些老文档里见过，那是 Maven 2 时代的叫法，现在用MAVEN_HOME就行。两个都写上也没坏处，但我更推荐只写一个，避免将来排查时多一层干扰。

验证：

mvn -v

输出里要能同时看到三行关键信息：Apache Maven 的版本、Maven home 路径、Java version。如果 Java version 显示的是你没预期的那个版本，说明JAVA_HOME有问题，回到上一节重查。

3.3 settings.xml 三段式配置：本地仓库、镜像、编译级别

到这一步 Maven 能跑了，但直接拿来用会很痛苦。默认配置下，所有依赖都会往中央仓库拉，网络状况不好时一次构建能耗掉几十分钟，还经常卡在某个依赖上超时。所以必须改配置。

配置文件位置有两个，优先级不同：

• $MAVEN_HOME/conf/settings.xml：全局配置，对所有用户生效。
• ~/.m2/settings.xml：用户级配置，优先级更高，会覆盖全局配置中的同名项。

我习惯在用户级配置里改，因为构建机上常常有多个账号跑不同项目，各自的需求不同。目录不存在的话手动建：

mkdir -p ~/.m2

第一段：本地仓库位置。默认在~/.m2/repository，随用户主目录走。如果主目录所在分区很小，或者多个用户想共享一份依赖缓存，就指到别处：

<localRepository>/data/maven-repo</localRepository>

共享缓存这事要谨慎。多个进程同时往同一个目录写，理论上 Maven 有并发控制，但被强杀进程打断留下半截文件的情况我遇到过，表现是某个依赖一直报校验失败，只能手工删掉重下。真要多用户共享，我会配只读的共享仓库 + 各自的私有仓库，而不是简单粗暴共用一个目录。

第二段：仓库镜像。把中央仓库指向一个访问更快的镜像站点，这是提速最明显的一招：

<mirrors> <mirror> <id>central-mirror</id> <name>internal-central-mirror</name> <url>https://mirror.example.internal/repository/maven-public/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors>

mirrorOf写central表示只镜像中央仓库；写*表示镜像一切仓库，包括项目自己声明的私有仓库，这个要慎用——它会把你项目里特意配置的仓库地址也一并劫持过去，导致某些内部依赖拉不到。写成external:*是另一个常见选择，意思是镜像所有外部仓库但保留本地文件仓库。

配完一定要测。删掉本地仓库里某个依赖的目录，重新跑一次构建，观察日志里下载地址是不是变成了你配的镜像域名。如果日志里还是原来的地址，说明settings.xml没被读到——最常见的原因是文件放错了位置，或者 XML 语法错误导致整段配置被忽略（可以用mvn help:effective-settings查看实际生效的配置，一目了然）。

第三段：编译级别。让 Maven 明确知道用哪个 Java 版本编译，避免不同机器上默认值不一致：

<profiles> <profile> <id>jdk-17</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <maven.compiler.release>17</maven.compiler.release> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> </profile> </profiles>

这里用maven.compiler.release而不是老的source/target组合。release参数会让编译器同时检查 API 使用是否符合目标版本，防止你不小心用了高版本才有的接口，在低版本运行时抛NoSuchMethodError。这个问题在老项目里特别隐蔽——编译时看着好好的，一上生产就炸。

project.build.sourceEncoding也建议显式写上。Windows 上默认编码和 Linux 不一样，同一个项目在两边编译，中文资源文件的表现会不同，加上这行就统一了。

3.4 首次构建验证与依赖拉取的观察方法

用一个最小项目验证整套环境：

mvn archetype:generate -DgroupId=com.example.demo \ -DartifactId=hello-maven -Dversion=1.0.0-SNAPSHOT \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DinteractiveMode=false cd hello-maven && mvn package

跑到BUILD SUCCESS就算通了。如果卡在依赖下载，看日志里的Downloading from那一行，地址对不对；如果是编译报错，看报的版本号和你预期是否一致。

我习惯在第一次构建后执行：

mvn help:system

这个命令会打印一堆环境信息，其中java.home、java.version、user.home、maven.home四项是排查问题的关键。以后遇到“为什么构建机上的结果和本地不一样”，第一反应就该是把这个输出和本地对比一下。

再补一个观察依赖拉取速度的技巧：构建时加-X会输出 debug 日志，太吵；加-Dorg.slf4j.simpleLogger.showDateTime=true可以在下载日志里带上时间戳，用来判断是哪个依赖拖慢的。这个参数不像-X那样淹没有用信息，实际排查效率更高。

4. 一台机器多个 JDK：共存与切换

4.1 update-alternatives 的工作机制

真实场景里，一台机器上跑三个不同 JDK 版本的项目是常事。老项目锁在 JDK 8，新项目要 JDK 17，中间还有个要 JDK 11 的。这时候怎么办？

update-alternatives是 Debian 系发行版提供的命令级多版本管理机制。它的原理不复杂：维护一个记录表，把每个“命令名”（比如java）对应的若干候选路径和优先级存起来，然后在/etc/alternatives/下建一个指向当前选中项的软链接，/usr/bin/java再指向那个链接。切换时只改一层链接，全局生效。

但要注意它的局限性：update-alternatives只管命令，不管JAVA_HOME。你把java切到了 17，JAVA_HOME还停在 11，那么java -version显示 17，Maven 却用 11 去编译。这就是很多人切换后依然报版本错的根因。

所以正确的做法是：命令切换用update-alternatives，JAVA_HOME单独管理，两者保持同步。

4.2 注册与切换实操

把现有的 JDK 加进去：

sudo update-alternatives --install /usr/bin/java java /opt/jdk-17.0.9/bin/java 1700 sudo update-alternatives --install /usr/bin/java java /opt/jdk-11.0.20/bin/java 1100 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk-17.0.9/bin/javac 1700 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk-11.0.20/bin/javac 1100

最后的数字是优先级，数字大的在自动模式下被选中。我习惯用版本号本身当优先级，1700 代表 17，1100 代表 11，一眼能看出来谁高谁低。

手动切换：

sudo update-alternatives --config java

会列出所有候选让你输入编号选择。javac同样要切一次，两个命令分开管理是这套机制的粗糙之处，但也只能这样。

切换后立刻同步JAVA_HOME：

sudo ln -sfn /opt/jdk-17.0.9 /opt/java

因为/etc/profile.d/java.sh里写的是/opt/java这个软链接路径，改软链接就等于改了JAVA_HOME。新开的终端会自动生效，当前终端需要重新source一次。

一个细节要提醒：图形界面或某些桌面环境下，系统可能还会维护一个/etc/environment文件，里面有静态的JAVA_HOME。这个文件在登录流程中的加载时机和 shell 脚本不一样，有时候会出现改了脚本不生效的情况。检查一下有没有，有就一并改掉。

4.3 项目级锁定：让构建不随全局变化

如果只是某个项目要用特定版本，根本没必要动全局配置。Maven 支持项目级的 JVM 参数和运行参数配置，在项目根目录建一个.mvn目录：

mkdir -p .mvn echo "-Dfile.encoding=UTF-8" > .mvn/jvm.config

jvm.config里的内容是直接传给 JVM 的启动参数。maven.config则是传给 Maven 本身的默认命令行参数，比如固定某个 profile、设置内存上限：

-T 1C -DskipTests

这套机制的好处是配置跟着代码走，谁拉下来都是同样的行为，不依赖他本机怎么装的。团队协作里，这比在 README 里写一段“请确保你装了 JDK 17”要可靠得多。

要做到真正的版本锁定，还有一招是在settings.xml里用<toolchains>配置多个 JDK 路径，然后项目里声明用哪个。这个配置稍微复杂，适合那种“构建机上有五个 JDK、每个项目指定用哪个”的大规模场景。小团队用目录软链接 + 环境变量已经足够。

5. 问题速查：我在装环境时踩过的那些坑

5.1 故障速查表

把常见问题按“现象 → 大概率原因 → 处理动作”整理成一张表，出问题先扫一遍，能跳过大部分无效排查：

表格里的“首次构建慢”这一条，很多人第一次遇到会以为是配置错了，反复折腾配置，其实只是依赖在下载。判断方法很简单：看日志有没有持续的Downloading from输出，有就是在正常拉取。

5.2 三个值得单独说的案例

案例一：解压到/tmp后重启消失。某次帮人看一台构建机的环境，脚本里写死了/tmp/jdk/bin/java。机器不重启时一切正常，一重启就全挂。原因是那个发行版把/tmp配置成 tmpfs 临时文件系统，另外还带了noexec挂载参数。教训是：任何要长期使用的软件，永远不要放在/tmp。排查这类问题可以用mount | grep /tmp看一眼挂载参数，一眼就能确认。

案例二：JAVA_HOME正确但 Maven 用的是别的 JDK。现象是echo $JAVA_HOME显示 17，java -version也显示 17，但mvn -v里 Java version 显示的是 11。查了半天发现mvn这个可执行文件本身是个 shell 脚本，它启动时会优先读JAVA_HOME，但如果JAVA_HOME没被正确导出（比如只在当前 shell 的局部变量里设置），就会回退到PATH里找java。解决办法是确保export确实生效，或者干脆在mvn命令前临时指定：JAVA_HOME=/opt/jdk-17.0.9 mvn package。这个临时指定的写法特别适合验证阶段的对比测试。

案例三：软链接套娃导致升级失败。用ln -s而不是ln -sfn更新软链接，当目标已经存在时，命令会在已有链接指向的目录内部再创建一个同名链接。表面上看/opt/java还在，实际结构已经乱掉了，指向的可能是/opt/jdk-17.0.9/jdk-17.0.9这种不存在的路径。检查方法：ls -l /opt/java看箭头，ls -l $(readlink -f /opt/java)逐层确认。修复就是把整个链接删掉重建，别试图在套娃结构上修补。

心得：这套环境安装完，我会把整个流程写成一份带版本号的脚本放在仓库里，包括下载地址、校验值、解压路径、软链接、环境变量、配置文件的完整内容。下次换机器直接跑，省掉所有回忆成本。环境这东西，第二次装比第一次装容易出错，因为你不会像第一次那样小心翼翼。

6. 非交互式环境：为什么脚本里找不到 java

6.1 交互 shell 与非交互 shell 的加载差异

这一节的坑我踩过两次，第二次才彻底搞明白。

现象：SSH 登录上去，mvn -v正常。写个 shell 脚本，用sh script.sh执行，脚本里调mvn，报 command not found。或者放到定时任务里跑，同样报错。

原因在 shell 的启动类型上。你登录时的 shell 是登录交互式 shell，它会依次读取/etc/profile、/etc/profile.d/*.sh、~/.bash_profile等文件。而sh script.sh启动的是非交互式 shell，它只读$BASH_ENV指向的文件，一般不读/etc/profile.d/。定时任务的执行环境更是精简到了极致，连 HOME 都可能不是你以为的那个。

所以/etc/profile.d/java.sh里的配置，对于非交互式进程来说根本不存在。

验证方法很简单：

sh -c 'echo $JAVA_HOME'

输出空行就说明没继承。这个命令是排查此类问题最快的手段，比直接去跑整个脚本快得多。

6.2 让环境变量在 CI 与服务里都生效的做法

针对不同场景，处理方式不一样：

脚本里，最直接的办法是在脚本开头显式 source 一次：

#!/usr/bin/env bash source /etc/profile.d/java.sh source /etc/profile.d/maven.sh

缺点是每个脚本都要写两行，容易被忘。更彻底的做法是把环境变量声明放在脚本头部，不依赖外部文件：

export JAVA_HOME=/opt/java export MAVEN_HOME=/opt/maven export PATH="$JAVA_HOME/bin:$MAVEN_HOME/bin:$PATH"

systemd 服务里，不要指望它能读到profile.d。正确写法是在 unit 文件里用Environment指令：

[Service] Environment="JAVA_HOME=/opt/java" Environment="PATH=/opt/java/bin:/opt/maven/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" ExecStart=/opt/maven/bin/mvn -f /srv/app/pom.xml package

ExecStart里用命令的绝对路径，比依赖 PATH 查找更稳妥。systemd 的 PATH 默认值本来就比你登录后的短，这是很多人服务启动失败的原因。

容器镜像里，用ENV指令设置，并且要注意基础镜像里有没有预装 JDK。如果有，你的路径可能被覆盖，或者PATH顺序不对，导致构建时用的是基础镜像自带的那个。构建完在容器里跑一次java -version确认，别等到运行时报错。

持续集成环境里，一般都有专门的 JDK 版本声明配置项，优先用平台提供的机制，而不是自己在脚本里塞 export。平台机制的好处是它会帮你处理缓存、切换、多版本并存这些事，自己塞 export 反而容易和平台逻辑打架。

最后分享一个我自己在用的小技巧：在机器的登录提示里加一行版本信息。把下面这段放进/etc/profile.d/java.sh末尾：

echo "[env] JAVA_HOME=$JAVA_HOME ($(java -version 2>&1 | head -n1))"

每次登录就能看到当前生效的 JDK，多台机器来回切的时候，不用每次手动查，少犯好几次“在错误的机器上跑构建”的迷糊。这个输出只在交互登录时出现，不影响脚本执行，代价几乎为零。