Java环境变量配置不生效的常见原因是环境变量未加载进当前Shell会话或配置位置错误；需正确设置/etc/profile或/etc/profile.d/java.sh并source生效，systemd服务须显式声明Environment，多版本切换推荐update-alternatives但需手动同步JAVA_HOME。
Java环境变量配置不生效的常见原因
在Linux服务器上配置JAVA_HOME后，java -version仍显示旧版本或报错，大概率是环境变量没加载进当前Shell会话，或配置位置不对。
- 别只改
~/.bashrc——如果用sudo su切换到root或以服务方式启动（如systemd），实际读的是/etc/profile或/etc/environment -
export JAVA_HOME=/opt/jdk-17.0.1必须写在export PATH=$JAVA_HOME/bin:$PATH之前，否则$JAVA_HOME在PATH里展开为空 - 改完别忘了执行
source /etc/profile（或对应文件），仅export命令只对当前终端临时生效 - 检查
which java和readlink -f $(which java)，确认实际调用的是你配的JDK路径，不是系统自带的OpenJDK或/usr/bin/java软链
使用tar.gz手动安装JDK比rpm更可控
CentOS/RHEL系用yum install java-17-openjdk-devel看似省事，但常导致JAVA_HOME指向/usr/lib/jvm/java-17-openjdk-*这种带时间戳的路径，升级后自动变更；生产环境建议直接下载Oracle或Eclipse Temurin的tar.gz包解压部署。
- 下载后解压到固定路径，如
/opt/jdk-17.0.1，避免路径含空格或特殊字符 - 用
chown -R root:root /opt/jdk-17.0.1 && chmod -R 755 /opt/jdk-17.0.1保证权限干净 - 在
/etc/profile.d/java.sh中写入环境变量（比直接改/etc/profile更模块化），并确保该文件有执行权限：chmod +x /etc/profile.d/java.sh
systemd服务里Java进程找不到JAVA_HOME
用systemctl start myapp.service启动Java应用时抛java: command not found，不是JDK没装，而是systemd默认不读用户级Shell配置，环境变量需显式声明。
- 在service文件的
[Service]段加Environment="JAVA_HOME=/opt/jdk-17.0.1"和Environment="PATH=/opt/jdk-17.0.1/bin:/usr/local/bin:/usr/bin:/bin" - 不要依赖
ExecStart=/path/to/start.sh让脚本自己source环境——脚本里的source ~/.bashrc在非交互式Shell下可能失效 - 验证方式：
systemctl daemon-reload && systemctl show myapp.service | grep Environment，确认变量已注入
多版本共存时如何安全切换
测试环境需同时跑Java 8和Java 17，又不想每次改JAVA_HOME，用update-alternatives是Linux原生方案，比手写shell函数更可靠。
立即学习“Java免费学习笔记（深入）”；
- 先注册两个版本：
update-alternatives --install /usr/bin/java java /opt/jdk-8u361/bin/java 100和update-alternatives --install /usr/bin/java java /opt/jdk-17.0.1/bin/java 200 - 交互式切换：
update-alternatives --config java，选编号即可 - 注意：此命令只改
/usr/bin/java软链，JAVA_HOME仍需单独配置——它不自动同步，得自己维护一致 - 若应用强依赖
JAVA_HOME（如Tomcat、Spring Boot fat jar），建议还是用独立JAVA_HOME配置，而非依赖update-alternatives
echo $JAVA_HOME在终端里有，在systemd里没有，往往就卡在这类隐性加载逻辑上。 
