需确认系统架构与JDK版本匹配，先用uname -m查x86_64或aarch64等，再下载对应Eclipse Temurin JDK包；手动解压至/opt，配置/etc/profile.d/java.sh并生效；systemd服务需显式声明JAVA_HOME和PATH，cron或脚本开头需source该文件；清理旧JDK软链避免冲突。
确认系统架构和JDK版本是否匹配
Linux服务器上装错JDK最常见原因就是架构不匹配，比如在 aarch64（ARM）机器上下载了 x86_64 的 JDK 包，解压后执行 java -version 会直接报 cannot execute binary file: Exec format error。
- 先运行
uname -m查架构：输出x86_64或aarch64是主流；armv7l则需找旧版 JDK 8 带 ARMv7 支持的包 - 去 Eclipse Temurin 或 jdk.java.net 下载对应
tar.gz包（推荐 Temurin，长期维护、无商业限制） - 避免用
.rpm或.deb包——除非你确定用yum/apt管理且不需要多版本共存
解压并配置 JAVA_HOME 和 PATH
手动解压是最可控的方式，尤其在生产环境。别依赖系统包管理器自动注册环境变量，容易和已有 JDK 冲突。
- 解压到统一目录，例如：
sudo tar -zxf OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8.tar.gz -C /opt/ - 重命名便于识别：
sudo mv /opt/jdk-17.0.2+8 /opt/java-17 - 编辑
/etc/profile.d/java.sh（新建），写入：
export JAVA_HOME=/opt/java-17 export PATH=$JAVA_HOME/bin:$PATH
- 生效：运行
source /etc/profile.d/java.sh，再验证java -version和echo $JAVA_HOME - 注意：不要写进
/etc/profile主文件——升级时易被覆盖；也不要只写进个人~/.bashrc——服务启动常以 root 或专用用户运行，读不到
验证 Java 可被 systemd 服务或脚本正确调用
很多 Java 应用（如 Spring Boot jar、Tomcat）由 systemd 托管，但默认环境下 systemd 不读取 /etc/profile 或 /etc/profile.d/，导致 java: command not found。
- 在 service 文件中显式指定
Environment=JAVA_HOME=/opt/java-17和Environment=PATH=/opt/java-17/bin:/usr/local/bin:/usr/bin:/bin - 或者用
ExecStartPre=/bin/sh -c 'source /etc/profile.d/java.sh && java -version'做前置校验（可选） - 重启服务后检查：运行
systemctl show --property=Environment myapp.service，确认变量已注入 - 若用
nohup或 cron 启动脚本，也需在脚本开头source /etc/profile.d/java.sh，不能只靠交互式 shell
卸载旧 JDK 或清理冲突路径
有些服务器预装了 OpenJDK（如 CentOS 7 自带 java-1.8.0-openjdk），即使你设置了新 JAVA_HOME，which java 仍可能指向 /usr/bin/java ——这是 alternatives 或软链造成的假象。
立即学习“Java免费学习笔记（深入）”；
- 运行
which java和readlink -f $(which java)，看真实路径是否指向旧 JDK - 若想彻底清除系统自带 JDK：
sudo yum remove java-1.8.0-openjdk*（CentOS/RHEL）或sudo apt purge openjdk-8-jre（Ubuntu/Debian） - 更稳妥的做法是保留旧包，但用
update-alternatives --install注册新 JDK，并设为默认（适合需多版本切换的场景） - 检查
/usr/bin/java是否是软链，误删可能导致yum等工具异常——它依赖/usr/bin/python类似的底层 Java 工具链
