当前位置：首页 > news >正文

Ubuntu 18.04 apt安装Java：多版本共存与系统级环境配置

news 2026/6/22 1:50:22

1. 项目概述：为什么在 Ubuntu 18.04 上用`apt`装 Java 不是“随便点两下”的事

Java 这个词，现在几乎等于“企业级后端开发”“面试八股文”“环境变量配置失败的深夜崩溃现场”。但回到 Ubuntu 18.04 这个具体场景——它不是最新 LTS（20.04/22.04 才是），也不是古董（16.04 已停更），而是那个被大量生产服务器、教育实验室、嵌入式网关设备长期锁定的“稳态中间代”。很多人查到“Ubuntu 安装 Java”，一搜就是“下载 tar.gz 包 + 手动配 PATH + 修改 JAVA_HOME”，结果配完发现java -version显示的是 OpenJDK 11，而公司老项目只认 JDK 8；或者javac能用，javadoc却报 command not found；更常见的是，sudo apt install default-jdk装完，IDEA 里新建 Maven 项目却提示“source level 8 requires target level 8”，明明装了 JDK 8 却被识别成 11。这些都不是操作失误，而是 Ubuntu 18.04 的apt仓库对 Java 的版本管理逻辑，和开发者直觉存在根本错位。

核心矛盾就在这里：apt在 Ubuntu 18.04 中不是“一键安装 Java”的工具，而是一个多版本共存调度器。它默认不提供单一 JDK，而是通过default-jdk、openjdk-8-jdk、openjdk-11-jdk等多个独立包名，把不同 JDK 版本作为互不干扰的“软件实体”来维护。你执行sudo apt install openjdk-8-jdk，系统会把/usr/lib/jvm/java-8-openjdk-amd64/整个目录结构原样解压进去；执行sudo apt install openjdk-11-jdk，则新增/usr/lib/jvm/java-11-openjdk-amd64/；而default-jdk只是一个符号链接包，它本身不带任何二进制文件，只负责在安装时自动创建/usr/lib/jvm/default-java指向当前“默认”版本——这个默认值，由update-alternatives机制动态控制，不是写死的。所以，所谓“用 apt 安装 Java”，本质是三件事：第一，从官方源拉取指定版本的完整 JDK 套件（含 javac、javadoc、jdb、keytool 等全套工具）；第二，让系统知道这个新 JDK 的存在；第三，告诉系统“现在请用这个版本响应java和javac命令”。这三步缺一不可，且每一步都有隐藏参数、路径陷阱和版本冲突点。我试过不下二十次重装，最深的教训是：别信网上那些“三行命令搞定”的教程，它们省略的恰恰是最容易出问题的环节——比如update-alternatives --config java之后没同步--config javac，导致java -version显示 11，javac -version却报错说找不到；又比如JAVA_HOME写成/usr/lib/jvm/java-11-openjdk-amd64，但实际路径末尾是-amd64还是-arm64或-i386，取决于你的 CPU 架构，手敲一个字母错，整个环境就瘫痪。这篇文章不讲“怎么装”，而是带你拆开 Ubuntu 18.04 的aptJava 生态，看清每个命令背后到底在改什么文件、调什么脚本、触发什么钩子。你不需要背命令，只需要理解逻辑，就能在任何一台裸机上，5 分钟内精准部署 JDK 8 或 JDK 11，并确保 Maven、Gradle、IntelliJ 全部无缝识别。

2. 核心设计思路与方案选型解析：为什么不用 SDKMAN？为什么不用手动 tar.gz？

先说结论：在 Ubuntu 18.04 上，apt是唯一能兼顾安全性、可维护性、多用户支持和系统集成度的 Java 安装方式。这不是教条，而是踩坑后的真实判断。

有人会问：为什么不用 SDKMAN？SDKMAN 确实方便，一行curl -s "https://get.sdkman.io" | bash就能装，还能sdk install java 8.0.302-open切换版本。但它在 Ubuntu 18.04 上有三个硬伤：第一，SDKMAN 安装的 JDK 默认放在$HOME/.sdkman/candidates/java/下，属于用户私有目录，sudo权限进程（比如 Jenkins 构建脚本、systemd 服务）根本读不到；第二，它依赖 Bash 的~/.bashrc自动加载，如果你用的是 Zsh、Fish 或者非交互式 shell（如 cron job），SDKMAN 的环境变量根本不会生效；第三，也是最关键的——SDKMAN 不参与系统的update-alternatives机制，这意味着update-java-alternatives -l列不出它装的 JDK，dpkg -l | grep openjdk也查不到，系统级工具（如apt自身的依赖检查、某些安全扫描器）会认为“这台机器没装 Java”，造成合规审计失败。我曾经在一个金融客户现场，因为 SDKMAN 安装的 JDK 未被apt认可，导致自动化安全基线检测直接标红，整改耗时两天。

那为什么不用官网 tar.gz 手动安装？OpenJDK 官网确实提供.tar.gz包，解压后配JAVA_HOME也能用。但问题在于“可维护性”。手动安装的 JDK，没有.deb包的元数据，apt list --installed | grep java查不到，apt autoremove不会清理它，apt upgrade更不会为你升级它。更麻烦的是权限管理：你解压到/opt/java/，得手动chown -R root:root，还得chmod 755所有 bin 目录下的可执行文件，稍有疏忽，jps就可能因权限不足报Permission denied。而apt安装的 JDK，所有文件权限、属主、目录结构都由 Debian 包规范严格定义，/usr/lib/jvm/下每个 JDK 子目录的 owner 都是root:root，bin/下文件权限统一为755，jre/bin/下的java文件还额外设置了setuid位（用于jstack等需要 ptrace 的调试工具），这些细节，手动安装永远无法 100% 复现。

再看apt方案的优势：第一，版本明确可控。Ubuntu 18.04 的官方源中，openjdk-8-jdk固定指向8u292-b10-0ubuntu1~18.04.1，openjdk-11-jdk固定指向11.0.11+9-0ubuntu1~18.04.1，每次apt install下载的都是经过 Canonical 官方 QA 测试的确定版本，不存在“今天装的是 8u292，明天apt update后变成 8u302”的风险；第二，系统级集成。apt安装的 JDK 会自动注册到update-alternatives，java、javac、javadoc、jdb、keytool等所有命令都被统一管理，你只需sudo update-alternatives --config java一次，所有相关命令就同步切换；第三，多用户开箱即用。/usr/lib/jvm/是系统全局路径，任何用户只要没覆盖自己的JAVA_HOME，执行java -version就能拿到系统默认 JDK，无需每个用户单独配置；第四，安全更新直达。当 OpenJDK 发布关键安全补丁（如 CVE-2021-2341），Canonical 会在 24 小时内打包进ubuntu-security-updates源，你只需sudo apt update && sudo apt upgrade，所有openjdk-*包自动升级，比手动下载 patch、替换 jar 包可靠十倍。我维护过 37 台 Ubuntu 18.04 服务器，全部采用apt安装 JDK，过去三年零一次因 Java 漏洞被通报——这就是方案选型的底层逻辑：不追求“最酷”，只选择“最稳、最省心、最扛得住审计”。

3. 核心细节解析与实操要点：`apt`安装 Java 的四个不可跳过环节

很多教程把sudo apt install default-jdk当作终点，其实这只是起点。真正决定成败的，是接下来四个必须手动干预的环节：源更新验证、包名精确匹配、update-alternatives初始化、JAVA_HOME环境变量固化。漏掉任何一个，都会在后续开发中埋下深坑。

3.1 源更新验证：为什么`sudo apt update`后还要检查`openjdk`包是否存在？

sudo apt update的作用，是下载/etc/apt/sources.list和/etc/apt/sources.list.d/下所有源的Packages.gz索引文件，但它不保证这些索引里一定包含openjdk相关包。Ubuntu 18.04 默认启用的源是main、universe、restricted、multiverse四个组件，而openjdk-8-jdk和openjdk-11-jdk都位于universe组件中。如果某台机器的sources.list被误删了universe行，apt update会成功执行，但apt search openjdk将返回空结果。我遇到过最典型的案例：一台教育机构的 Ubuntu 18.04 虚拟机，管理员为了“精简系统”，手动注释掉了sources.list中所有universe开头的行，结果apt install default-jdk报错E: Package 'default-jdk' has no installation candidate。解决方法极其简单：sudo sed -i '/universe/s/^# //' /etc/apt/sources.list && sudo apt update，但前提是你要知道问题出在这里。

验证步骤必须严格执行：

grep -E "^(deb|deb-src).*universe" /etc/apt/sources.list—— 确保输出至少包含一行deb http://archive.ubuntu.com/ubuntu bionic universe；
apt-cache policy | grep -A 1 "http://archive.ubuntu.com"—— 查看universe组件是否在Candidate列表中；
apt-cache search openjdk-8-jdk | head -n 3—— 真正确认包名存在，而非只查default-jdk。

提示：apt-cache search比apt search更底层、更可靠。apt search是apt命令的封装，有时会因缓存异常返回空；而apt-cache search直接读取本地Packages索引，结果绝对真实。另外，openjdk-8-jdk在 Ubuntu 18.04 中的全名是openjdk-8-jdk-headless（无图形界面版）和openjdk-8-jdk（含 AWT/Swing 图形库），后者体积大 20MB，但如果你要运行 JavaFX 应用或 Swing GUI 工具（如 JConsole），必须装带 GUI 的完整版。

3.2 包名精确匹配：`default-jdk`、`openjdk-8-jdk`、`openjdk-11-jdk`到底该选哪个？

这是新手最容易混淆的点。default-jdk不是一个 JDK，而是一个“元包”（metapackage），它的作用仅仅是声明依赖关系并触发update-alternatives的初始配置。当你执行sudo apt install default-jdk，apt会根据系统策略自动选择一个“默认”版本（Ubuntu 18.04 默认选openjdk-11-jdk），然后安装它，并运行update-alternatives --install命令将该 JDK 注册为系统默认。但问题在于：这个“默认”是 Canonical 定义的，不是你定义的。如果你的项目强制要求 JDK 8，default-jdk就成了陷阱——它装的是 JDK 11，你得再手动卸载、重装 JDK 8，多走两倍弯路。

正确做法是跳过default-jdk，直击目标包名：

要 JDK 8：sudo apt install openjdk-8-jdk
要 JDK 11：sudo apt install openjdk-11-jdk

这两个包的区别远不止版本号：

openjdk-8-jdk安装后，会在/usr/lib/jvm/下创建java-8-openjdk-amd64/（x86_64 架构）或java-8-openjdk-arm64/（ARM64），其bin/目录包含完整的 JDK 工具链，包括javac（编译器）、javadoc（文档生成器）、jdb（调试器）、jar（归档工具）、jps（进程查看器）等；
openjdk-11-jdk同理，创建java-11-openjdk-amd64/，但注意：JDK 11 移除了java-rmi、javafx等模块，jjs（Nashorn JavaScript 引擎）也被废弃，如果你的项目依赖这些，JDK 11 会直接报NoClassDefFoundError；
两者都自带jre/子目录，即 JRE 运行时环境，所以装了 JDK 就不用额外装 JRE。

注意：不要尝试sudo apt install openjdk-8-jre（仅运行时）再单独装openjdk-8-jdk-headless（仅编译），因为openjdk-8-jdk-headless会自动依赖openjdk-8-jre，但openjdk-8-jre不会反向依赖headless。这种拆分安装会导致javac命令缺失，而java命令正常，形成“能跑不能编”的诡异状态。务必一步到位，装openjdk-8-jdk或openjdk-11-jdk。

3.3`update-alternatives`初始化：为什么装完 JDK 后`java -version`还是旧版本？

这是最常被忽略的致命环节。apt安装 JDK 包时，会在postinst脚本中自动执行update-alternatives --install命令，将新 JDK 的java、javac等命令注册进系统替代链。但这个注册只是“登记”，不是“激活”。系统默认的java替代项，是由/var/lib/dpkg/info/openjdk-*.list文件中的priority值决定的，而openjdk-8-jdk的 priority 是 1081，openjdk-11-jdk是 1101，数字越大优先级越高。所以如果你先装了 JDK 8，再装 JDK 11，java命令会自动切到 JDK 11；但如果你只装了 JDK 8，update-alternatives并不会自动把它设为默认——它会保持之前的状态（可能是系统自带的 OpenJDK 7，或者根本没有默认项）。

验证和修复步骤：

update-alternatives --list java—— 查看java是否已注册。如果报错no alternatives for java，说明注册失败，需手动注册；
sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081—— 手动注册 JDK 8 的java命令，1081是 priority 值，必须与包内定义一致（可通过apt show openjdk-8-jdk | grep Priority查看）；
sudo update-alternatives --config java—— 交互式选择，默认选项是*，按回车即可激活；
关键一步：sudo update-alternatives --config javac—— 必须同步配置javac！否则java -version显示 8，javac -version却显示 11，Maven 编译必然失败。

实操心得：我习惯在装完 JDK 后，立即执行sudo update-alternatives --config java && sudo update-alternatives --config javac && sudo update-alternatives --config javadoc，把所有 Java 相关命令都显式配置一遍。虽然javadoc很少用，但配置它能确保update-alternatives的状态一致性，避免某些 IDE（如 Eclipse）因javadoc未注册而报错。

3.4`JAVA_HOME`环境变量固化：为什么`/etc/environment`比`~/.bashrc`更可靠？

JAVA_HOME是 Java 生态的“心脏起搏器”，几乎所有构建工具（Maven、Gradle）、IDE（IntelliJ、Eclipse）、容器（Docker）都依赖它定位 JDK 根目录。但很多人把它写在~/.bashrc里，结果发现：sudo java -version正常，sudo mvn clean却报JAVA_HOME not set。这是因为sudo默认不继承普通用户的环境变量，~/.bashrc只对当前用户生效。

正确做法是写入系统级环境文件：

对所有用户生效：编辑/etc/environment，添加一行JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64"（注意：这里必须是绝对路径，且不能带$符号，/etc/environment不支持变量展开）；
对当前用户生效（推荐）：编辑/etc/profile.d/java.sh，添加export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64和export PATH=$JAVA_HOME/bin:$PATH。/etc/profile.d/下的.sh文件会被所有登录 shell 自动 source，且sudo执行时若加-i参数（sudo -i mvn clean），也会加载它。

注意事项：JAVA_HOME的路径必须精确到 JDK 主目录，即/usr/lib/jvm/java-8-openjdk-amd64，而不是/usr/lib/jvm/java-8-openjdk-amd64/jre（这是 JRE 路径，javac会找不到）。验证方法：echo $JAVA_HOME应输出路径，ls $JAVA_HOME/bin/javac应返回/usr/lib/jvm/java-8-openjdk-amd64/bin/javac。我曾因手误多打了一个/jre，导致 Maven 编译时javac命令始终找不到，排查了三小时才定位到这个斜杠。

4. 实操过程与核心环节实现：从裸机到可运行 Java 项目的完整流程

下面以一台全新安装的 Ubuntu 18.04 Server（无桌面环境）为例，演示从零开始，用apt部署 JDK 8 并验证 Maven 项目构建的全流程。所有命令均可直接复制粘贴，每一步都附带原理说明和预期输出。

4.1 环境初始化与源配置

首先确认系统版本和架构：

lsb_release -a # 输出应为：Description: Ubuntu 18.04.6 LTS uname -m # 输出应为：x86_64（或 aarch64）

检查并启用universe源（关键！）：

# 查看当前源配置 grep -E "^(deb|deb-src)" /etc/apt/sources.list | grep universe # 如果无输出，执行以下命令启用 sudo sed -i 's/^\(#\)\?\(deb.*universe\)/\2/' /etc/apt/sources.list sudo sed -i 's/^\(#\)\?\(deb-src.*universe\)/\2/' /etc/apt/sources.list # 更新源索引 sudo apt update

原理解析：sed -i命令中的正则^$#$\?$deb.*universe$表示“匹配以#开头（可选）后跟deb和universe的行”，\2表示只保留第二个捕获组（即去掉开头的#）。这样比手动编辑sources.list更可靠，避免因行号错误改错位置。

4.2 JDK 8 安装与`update-alternatives`注册

搜索并安装 JDK 8：

# 确认包存在 apt-cache search openjdk-8-jdk | head -n 2 # 输出示例：openjdk-8-jdk - OpenJDK Development Kit (JDK) # openjdk-8-jdk-headless - OpenJDK Development Kit (JDK) (headless) # 安装完整版（含 GUI 支持） sudo apt install -y openjdk-8-jdk

安装完成后，验证update-alternatives状态：

# 查看 java 是否已注册 update-alternatives --list java # 如果报错，手动注册（x86_64 架构） sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac 1081 sudo update-alternatives --install /usr/bin/javadoc javadoc /usr/lib/jvm/java-8-openjdk-amd64/bin/javadoc 1081 # 交互式选择默认版本 sudo update-alternatives --config java # 选择对应编号（通常为 0），回车 sudo update-alternatives --config javac sudo update-alternatives --config javadoc

实操记录：在一台 AMD64 机器上，update-alternatives --list java初始输出为空，执行手动注册后，--list返回：

/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java /usr/lib/jvm/java-11-openjdk-amd64/jre/bin/java

说明系统里可能已有 JDK 11（来自default-jdk），此时--config java会列出两个选项，选择 JDK 8 的编号即可。

4.3`JAVA_HOME`固化与全局生效

创建/etc/profile.d/java.sh：

echo 'export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64' | sudo tee /etc/profile.d/java.sh echo 'export PATH=$JAVA_HOME/bin:$PATH' | sudo tee -a /etc/profile.d/java.sh # 重新加载 profile source /etc/profile.d/java.sh

验证环境变量：

echo $JAVA_HOME # 输出：/usr/lib/jvm/java-8-openjdk-amd64 java -version # 输出：openjdk version "1.8.0_292" javac -version # 输出：javac 1.8.0_292

关键技巧：source /etc/profile.d/java.sh只对当前 shell 生效。要让新打开的终端也生效，需注销重登，或执行exec bash启动新 shell。但sudo用户环境仍需单独处理：sudo su -c 'echo $JAVA_HOME'应输出相同路径，否则sudo mvn会失败。解决方案是sudo visudo，在最后添加Defaults env_keep += "JAVA_HOME"，让sudo保留该变量。

4.4 Maven 项目构建验证

安装 Maven（Ubuntu 18.04 源中自带）：

sudo apt install -y maven mvn -v # 输出应包含 Java version: 1.8.0_292

创建测试项目：

mkdir ~/test-java && cd ~/test-java mvn archetype:generate -DgroupId=com.example -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false cd my-app # 修改 pom.xml，将 maven-compiler-plugin 的 source/target 设为 1.8 sed -i '/<plugin>/,/<\/plugin>/s/<source>1.7/<source>1.8/;s/<target>1.7/<target>1.8/' pom.xml # 构建 mvn clean package

验证构建结果：

# 检查 jar 包是否生成 ls target/my-app-1.0-SNAPSHOT.jar # 运行 java -cp target/my-app-1.0-SNAPSHOT.jar com.example.App # 输出：Hello World!

排查要点：如果mvn clean package报错Fatal error compiling: invalid target release: 1.8，说明pom.xml中的<source>和<target>未正确修改，或JAVA_HOME未被 Maven 读取。此时执行mvn -X clean package 2>&1 | grep -A 5 "JAVA_HOME"，可看到 Maven 实际读取的JAVA_HOME值，据此定位配置错误点。

5. 常见问题与排查技巧实录：那些让你抓狂的 Java 环境故障

在 Ubuntu 18.04 上用apt装 Java，90% 的问题都集中在环境变量、版本冲突和权限三方面。以下是我在 37 台服务器上积累的真实故障案例及秒级排查法。

5.1`command 'java' not found`：`apt`装了 JDK，但`java`命令不存在

现象：sudo apt install openjdk-8-jdk成功，ls /usr/lib/jvm/确实有java-8-openjdk-amd64/目录，但java -version报错command not found。

根因分析：/usr/bin/java是一个符号链接，指向/etc/alternatives/java，而后者又指向/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java。如果update-alternatives未注册，这个链条就断了。

秒级排查：

ls -l /usr/bin/java # 如果输出 "No such file or directory"，说明链接未创建 # 如果输出 "java -> /etc/alternatives/java"，继续查 ls -l /etc/alternatives/java # 如果报错，说明 alternatives 未注册；如果指向错误路径，说明注册错位

解决方案：

# 强制重建链接 sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 --slave /usr/bin/javac javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac --slave /usr/bin/javadoc javadoc /usr/lib/jvm/java-8-openjdk-amd64/bin/javadoc sudo update-alternatives --config java

独家技巧：--slave参数可一次性注册多个关联命令，避免分别执行三次--install。--slave的格式是--slave <link> <name> <path>，其中<link>是符号链接路径（如/usr/bin/javac），<name>是 alternatives 名称（如javac），<path>是实际可执行文件路径。

5.2`JAVA_HOME not set`：`sudo mvn`失败，但普通用户`mvn`正常

现象：普通用户执行mvn clean成功，sudo mvn clean却报The JAVA_HOME environment variable is not defined correctly。

根因分析：sudo默认以root用户身份执行，而root的~/.bashrc或/root/.profile中未设置JAVA_HOME，且/etc/environment未配置（或配置了但sudo未加载）。

秒级排查：

sudo echo $JAVA_HOME # 输出为空，证明 root 环境无此变量 sudo su -c 'echo $JAVA_HOME' # 如果输出为空，说明 `/etc/environment` 未生效

解决方案：

# 方法一：永久生效（推荐） echo 'JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64"' | sudo tee -a /etc/environment # 方法二：临时生效（调试用） sudo JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 mvn clean # 方法三：让 sudo 保留变量 sudo visudo # 在文件末尾添加：Defaults env_keep += "JAVA_HOME"

实操心得：我习惯在/etc/environment中同时设置JAVA_HOME和PATH，因为PATH也会影响sudo下的命令查找。/etc/environment是系统级配置，比~/.bashrc更底层，且被pam_env.so模块自动加载，所有用户（包括root）都适用。

5.3`java: outofmemoryerror: insufficient memory`：堆内存不足，但`free -h`显示内存充足

现象：运行大型 Java 应用（如 Tomcat、Spring Boot）时，JVM 启动报OutOfMemoryError: Java heap space，free -h显示还有 4GB 空闲内存。

根因分析：Ubuntu 18.04 的openjdk-8-jdk默认 JVM 参数中，-Xmx（最大堆）被设为物理内存的 1/4，但apt安装的 JDK 会读取/etc/java-8-openjdk/security/java.security中的securerandom.source设置，如果该值为file:/dev/random，在熵池不足时会导致SecureRandom初始化卡住，进而触发 JVM 的内存分配超时保护，表现为“假性内存不足”。

秒级排查：

# 查看 JVM 启动参数 ps aux | grep java | grep -v grep # 如果看到 -Djava.security.egd=file:/dev/random，就是它 # 检查熵池 cat /proc/sys/kernel/random/entropy_avail # 如果低于 100，说明熵不足

解决方案：

# 临时修复（重启前有效） sudo sysctl -w kernel.randomize_va_space=2 # 永久修复：修改 JDK 安全配置 sudo sed -i 's|securerandom.source=file:/dev/random|securerandom.source=file:/dev/urandom|' /etc/java-8-openjdk/security/java.security # 或在启动脚本中添加 JVM 参数 export JAVA_OPTS="-Djava.security.egd=file:/dev/urandom"

独家技巧：/dev/urandom是非阻塞随机数生成器，在熵池不足时仍能返回伪随机数，对安全性影响极小（现代密码学已证明其足够安全），但能彻底解决OutOfMemoryError的误报问题。这是 Ubuntu 18.04 上 Java 应用部署的必备优化项。

5.4`java: 错误: 不支持发行版本 5`：`javac`编译失败，版本号混乱

现象：javac -version显示1.8.0_292，但编译.java文件时却报错误: 不支持发行版本 5。

根因分析：javac的-source和-target参数默认为1.5（即 Java 5），而javac本身是 JDK 8，但编译器被强制降级。这通常发生在pom.xml或build.gradle中未显式指定 Java 版本，或JAVA_HOME指向了错误的 JDK（如指向了/usr/lib/jvm/java-8-openjdk-amd64/jre而非/usr/lib/jvm/java-8-openjdk-amd64）。

秒级排查：

# 查看 javac 实际路径 readlink -f $(which javac) # 如果输出包含 `/jre/bin/javac`，说明 JAVA_HOME 错了 # 查看 javac 默认参数 javac -help | grep "source" # 如果显示 "-source <release>"，说明是 JDK 8+，问题在构建工具配置

解决方案：

# 确保 JAVA_HOME 正确 export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 # Maven 项目：在 pom.xml 中添加 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin>