服务器 JDK 环境变量配置：一键安装和手动配置有什么区别？

在服务器上部署 Java 项目，第一步一般都是准备 JDK。

现在配置 JDK，常见有两种方式：

通过指令直接下载并一键安装
手动上传 JDK 压缩包，再配置环境变量

两种方式都可以，主要区别在于方便程度、版本控制和可控性。

什么是环境变量？

Linux 中的环境变量，可以简单理解为系统提前准备好的一些"环境信息"，程序运行时可以直接读取和使用。它有点像给程序提供的"快捷入口"，例如通过 JAVA_HOME 快速找到 JDK 的安装位置，通过 PATH 直接执行 java、javac 等命令。

例如：

复制代码

PATH
JAVA_HOME
HOME
USER
SHELL

其中比较常见的是 PATH。

执行：

bash 复制代码

echo $PATH

可能看到：

复制代码

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

当我们执行：

复制代码

java -version

Linux 会根据 PATH 中配置的目录去寻找 java 命令。

而 JAVA_HOME 一般用于指定 JDK 的安装目录，例如：

复制代码

JAVA_HOME=/opt/jdk-21

怎么查看服务器上的环境变量？

最简单的方法：

复制代码

env

会看到当前 Shell 中的环境变量，例如：

复制代码

PATH=/usr/local/bin:/usr/bin:/bin
HOME=/root
USER=root
SHELL=/bin/bash
JAVA_HOME=/opt/jdk-21

也可以：

bash 复制代码

printenv

如果只想查看某一个变量：

bash 复制代码

echo $JAVA_HOME

或者：

bash 复制代码

printenv JAVA_HOME

查看 PATH：

bash 复制代码

echo $PATH

如果只想检查 Java 相关环境变量：

bash 复制代码

env | grep -E 'JAVA|PATH'

一键下载并安装 JDK

如果服务器可以访问互联网，可以直接使用系统的软件包管理器安装 JDK。

例如 Ubuntu：

bash 复制代码

apt update
apt install openjdk-21-jdk -y

安装完成后：

复制代码

java -version

例如：

复制代码

openjdk version "21.0.x"

再检查 Java 在什么位置：

bash 复制代码

which java

可能得到：

复制代码

/usr/bin/java

这种方式最大的优点就是方便。

不需要自己下载 JDK，也不需要手动上传压缩包，安装过程基本由系统完成。

有些服务器还会使用专门的安装脚本，一条命令就可以完成：

复制代码

下载 JDK
↓
安装 JDK
↓
配置 JAVA_HOME
↓
配置 PATH
↓
检查 Java 版本

对于测试环境来说，这种方式非常省事。

手动上传 JDK 包进行配置

生产环境有时候并不方便直接在线下载 JDK。

比如：

服务器不能访问互联网
公司已经准备好了指定版本的 JDK
项目要求固定 JDK 版本
需要多个 JDK 同时存在
生产环境希望自己控制 JDK 文件

这时候可以手动上传。

假设本地准备好了：

复制代码

jdk-21.0.2_linux-x64.tar.gz

将压缩包上传到服务器：

复制代码

/opt/

进入目录：

复制代码

cd /opt

解压：

复制代码

tar -zxvf jdk-21.0.2_linux-x64.tar.gz

假设最终目录是：

复制代码

/opt/jdk-21.0.2

先不要急着配置环境变量，可以直接测试 JDK：

复制代码

/opt/jdk-21.0.2/bin/java -version

如果能够正常显示：

复制代码

openjdk version "21.0.2"

说明 JDK 本身没有问题。

手动配置 JAVA_HOME

确认 JDK 没问题之后，再配置环境变量。

复制代码

vim /etc/profile

在文件最后增加：

复制代码

export JAVA_HOME=/opt/jdk-21.0.2
export PATH=$JAVA_HOME/bin:$PATH

保存之后执行：

bash 复制代码

source /etc/profile

然后检查：

bash 复制代码

echo $JAVA_HOME

如果显示：

复制代码

/opt/jdk-21.0.2

说明 JAVA_HOME 已经生效。

再执行下面的检查 Java 版本：

bash 复制代码

java -version

source 是干什么的？

很多人第一次配置环境变量时，会遇到这样的情况。

复制代码

vim /etc/profile

增加：

复制代码

export JAVA_HOME=/opt/jdk-21.0.2
export PATH=$JAVA_HOME/bin:$PATH

然后直接执行：

bash 复制代码

echo $JAVA_HOME

发现没有变化。

这是因为修改配置文件，并不会自动修改当前已经存在的 Shell 环境。

所以需要：

复制代码

source /etc/profile

让当前 Shell 重新读取 /etc/profile。

也可以写成：

复制代码

. /etc/profile

两种方式效果基本一致。

当然，也可以直接退出 SSH，重新登录服务器。

临时配置和永久配置

环境变量配置又可以分成临时配置和永久配置。

1. 临时配置

直接执行：

复制代码

export JAVA_HOME=/opt/jdk-21.0.2
export PATH=$JAVA_HOME/bin:$PATH

然后：

bash 复制代码

java -version

当前终端可以正常使用。

但是退出当前 SSH：

复制代码

exit

重新登录后，之前的配置可能就不存在了。

所以临时配置比较适合：

测试某个 JDK
排查环境问题
临时切换 JDK
验证应用是否支持某个 Java 版本

2. 永久配置

如果希望以后重新登录服务器仍然存在，就需要将配置写入配置文件。

例如：

复制代码

vim /etc/profile

增加：

复制代码

export JAVA_HOME=/opt/jdk-21.0.2
export PATH=$JAVA_HOME/bin:$PATH

然后：

复制代码

source /etc/profile

重新登录服务器后，也会自动加载配置。

为什么一键配置了，还需要手动修改？

很多人会有一个疑问：

既然现在可以一条命令把 JDK 下载、安装、配置环境变量都做完，为什么还需要自己上传 JDK 包、修改配置文件？

原因很简单：

一键安装解决的是"快速安装"，手动配置解决的是"明确控制"。

比如服务器原来已经存在 JDK 8：

复制代码

/usr/lib/jvm/java-8

现在又通过一键方式安装 JDK 21：

复制代码

/usr/lib/jvm/java-21

服务器上就可能同时存在：

复制代码

JDK 8
JDK 21

这时候执行：

复制代码

java -version

到底使用的是哪个版本？

就需要进一步检查：

复制代码

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

不要只看 java -version

排查 Java 环境时，建议执行：

bash 复制代码

echo $JAVA_HOME

查看 JDK 环境变量。

然后：

复制代码

which java

例如：

复制代码

/usr/bin/java

继续查看它最终指向哪里：

复制代码

readlink -f $(which java)

可能得到：

复制代码

/opt/jdk-21.0.2/bin/java

最后：

复制代码

java -version

这样才能基本确认：

复制代码

JAVA_HOME
    ↓
/opt/jdk-21.0.2

which java
    ↓
/usr/bin/java

实际指向
    ↓
/opt/jdk-21.0.2/bin/java

Java版本
    ↓
21.0.2

如果发现 JAVA_HOME 是 JDK 21，但是 java 实际指向 JDK 17，就说明服务器上的 Java 环境没有完全对应起来。

生产环境为什么更喜欢手动配置？

假设项目明确要求：

复制代码

JDK 21.0.2

这时候自己准备：

复制代码

jdk-21.0.2_linux-x64.tar.gz

上传到：

复制代码

/opt/

然后解压：

复制代码

tar -zxvf jdk-21.0.2_linux-x64.tar.gz

配置：

复制代码

export JAVA_HOME=/opt/jdk-21.0.2
export PATH=$JAVA_HOME/bin:$PATH

JDK 的版本和安装位置就非常明确。

特别是生产环境，如果还存在：

复制代码

JDK 8
JDK 17
JDK 21

更需要明确指定每个应用使用哪个 JDK。

还有一个容易忽略的问题

你在 SSH 中执行：

复制代码

java -version

正常，并不一定代表 TongWeb、Tomcat、Spring Boot 等应用启动时使用的也是这个 JDK。

例如：

复制代码

SSH 登录
   ↓
Shell 环境变量
   ↓
java -version

和：

复制代码

systemd
   ↓
启动 Java 应用
   ↓
应用自己的运行环境

并不完全是一回事。

如果应用是通过 systemd服务启动，就需要检查它自己的服务配置。

（不了解 systemd服务启动的****可以简单看我这篇文章 👉👉👉使用 systemctl 管理 TongWeb 启停-CSDN博客）

例如：

复制代码

[Service]
Environment="JAVA_HOME=/opt/jdk-21.0.2"
Environment="PATH=/opt/jdk-21.0.2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"

所以生产环境排查 Java 问题时，不要只看：

复制代码

java -version

还要确认实际启动应用的进程到底使用了哪个 JDK。

一键安装还是手动上传？

可以简单这样选择：

场景	推荐方式
测试服务器	一键安装
可以访问互联网	一键安装
快速搭建环境	一键安装
服务器无法联网	手动上传
公司指定 JDK 版本	手动上传
生产环境	手动配置更可控
多个 JDK 共存	手动配置
需要固定 JDK 版本	手动配置

其实两种方式并不冲突。

一键安装追求效率，手动配置追求可控。

一键安装适合快速把环境跑起来；手动上传 JDK 包，更适合需要固定版本、离线部署、多 JDK 共存的服务器环境。

小结

以后在服务器上遇到 JDK 环境问题，可以按照下面的顺序检查：

bash 复制代码

env | grep -E 'JAVA|PATH'

echo $JAVA_HOME

which java

readlink -f $(which java)

java -version

手动安装 JDK，基本流程就是：

复制代码

准备 JDK 压缩包
      ↓
上传到服务器
      ↓
解压
      ↓
确认 JDK 可以运行
      ↓
配置 JAVA_HOME
      ↓
配置 PATH
      ↓
source /etc/profile
      ↓
检查环境变量
      ↓
检查 java 实际指向
      ↓
启动 Java 应用

一键安装的流程：

复制代码

执行安装命令
      ↓
自动下载/安装
      ↓
自动配置
      ↓
java -version
      ↓
检查实际使用的 JDK