JDK 17 RPM安装后`java -version`仍显示旧版本？

Question

JDK 17通过RPM安装（如`rpm -ivh java-17-openjdk-17.0.1-2.1.el9.x86_64.rpm`）后执行`java -version`仍显示旧版本（如JDK 8或11），是典型环境路径冲突问题。根本原因在于：RPM虽将JDK 17安装至`/usr/lib/jvm/java-17-openjdk-*`，但系统默认`/usr/bin/java`仍为旧版软链接（常指向`/etc/alternatives/java`），而`alternatives`未自动切换或优先级设置不足；同时用户级`$PATH`中可能前置了旧JDK的`bin`目录（如`/opt/java/jdk8/bin`），导致shell优先调用旧版`java`。此外，部分发行版（如RHEL/CentOS Stream 9）的RPM包不自动触发`alternatives --config java`交互配置，需手动执行。验证需检查`which java`、`readlink -f $(which java)`及`/usr/sbin/alternatives --display java`输出。该问题非安装失败，而是Java多版本共存下的路径仲裁失效，属运维配置类高频故障。

Answer 1

```html

一、现象层：命令行输出与预期严重偏离

执行 java -version 仍显示 JDK 8 或 JDK 11，而 rpm -qa | grep java-17 明确返回已安装 java-17-openjdk-17.0.1-2.1.el9.x86_64 —— 表明安装成功但未生效。这是典型的“安装即完成”认知误区引发的第一层误判。

二、路径层：Shell 解析链的三重跳转失效

• which java → 指向 /usr/bin/java
• readlink -f /usr/bin/java → 解析为 /etc/alternatives/java
• readlink -f /etc/alternatives/java → 最终指向旧版 JDK（如 /usr/lib/jvm/java-11-openjdk-11.0.20.0.8-2.el9.x86_64/bin/java）

该链路揭示：RPM 安装仅注册了新 JDK 到 /usr/lib/jvm/，但未将其注入 alternatives 系统仲裁池，导致路径解析始终绕过 JDK 17。

三、机制层：alternatives 系统的优先级博弈模型

RHEL/CentOS Stream 9 中，alternatives 是多版本共存的核心仲裁器。每个 Java 提供者需满足两个条件才可参与竞争：

1. 在 /var/lib/alternatives/java 中注册条目（含路径、优先级、标签）
2. 其优先级（priority）必须高于当前选中项（默认 JDK 11 常设为 1091，JDK 8 为 1081）

OpenJDK 17 RPM 包虽含 %post 脚本调用 alternatives --install，但若旧版本优先级更高或存在残留锁文件（/var/lib/alternatives/.java.lock），则注册失败且静默忽略。

四、环境层：用户态 PATH 的隐式劫持

变量来源	典型值	风险等级
/etc/profile.d/java.sh	export PATH="/opt/java/jdk8/bin:$PATH"	★★★★☆
~/.bashrc	export JAVA_HOME=/usr/lib/jvm/java-11-openjdk	★★★☆☆
/etc/environment	JAVA_HOME="/usr/lib/jvm/java-8-openjdk"	★★★☆☆

当 $PATH 前置了任意旧 JDK 的 bin 目录时，shell 将跳过 /usr/bin/java 而直接命中该目录下 java 可执行文件——此时 alternatives 完全失效。

五、验证层：四维诊断法（CLI + alternatives + JVM + 进程）

# 维度1：Shell路径溯源
$ which java
/usr/bin/java
$ readlink -f $(which java)
/usr/lib/jvm/java-11-openjdk-11.0.20.0.8-2.el9.x86_64/bin/java

# 维度2：alternatives状态快照
$ alternatives --display java | grep -E "(status|priority|link)"
status: manual
link: /usr/bin/java
priority: 1091   # ← 当前选中项优先级
slave jre_openjdk: /usr/lib/jvm/jre-11-openjdk-11.0.20.0.8-2.el9.x86_64

# 维度3：JDK 17是否已注册？
$ alternatives --list | grep java
java    auto    /usr/lib/jvm/java-11-openjdk-11.0.20.0.8-2.el9.x86_64/bin/java

# 维度4：进程级确认（排除IDE/容器干扰）
$ ps aux | grep java | grep -v grep | xargs -I{} sh -c 'echo {}; readlink -f {}/bin/java 2>/dev/null'

六、解决层：三阶修复策略（推荐按序执行）

1. 强制注册 JDK 17 到 alternatives：
   sudo alternatives --install /usr/bin/java java /usr/lib/jvm/java-17-openjdk-17.0.1.0.12-2.1.el9.x86_64/bin/java 1170 --family java-17-openjdk --slave /usr/bin/javadoc javadoc /usr/lib/jvm/java-17-openjdk-17.0.1.0.12-2.1.el9.x86_64/bin/javadoc
2. 交互式切换并设为自动模式：
   sudo alternatives --config java → 选择 JDK 17 对应编号 → 再执行 sudo alternatives --auto java
3. 清理用户级 PATH 干扰：
   检查 /etc/profile.d/*.sh、~/.bashrc、/etc/environment，注释或删除所有硬编码旧 JDK 的 PATH 和 JAVA_HOME 行。

七、防御层：构建可审计的 Java 版本治理规范

graph LR
  A[新JDK RPM安装] --> B{检查alternatives注册}
  B -->|未注册| C[执行alternatives --install]
  B -->|已注册| D[检查priority是否最高]
  D -->|否| E[调整priority或--remove旧项]
  D -->|是| F[执行--auto java]
  C --> G[验证which/readlink/alternatives]
  E --> G
  F --> G
  G --> H[写入CMDB资产表]

建议将 JDK 版本、安装路径、alternatives priority、生效时间、操作人写入配置管理数据库（CMDB），并纳入 Ansible Playbook 自动化巡检任务（每周扫描 alternatives --list | grep java 与 java -version 是否一致）。

八、延伸思考：容器化与云原生场景下的版本漂移

即使宿主机 JDK 17 已正确配置，Docker 构建阶段若使用 FROM openjdk:11-jre-slim 或 Maven 镜像未升级，仍将导致构建产物绑定旧 JVM 字节码版本；Kubernetes Pod 中 env.JAVA_HOME 若硬编码为 /opt/java/jdk11，亦会覆盖节点全局设置。因此，JDK 版本治理必须贯穿 CI/CD 全链路，而非仅限于 OS 层。

```