Linux下JDK安装配置全指南：从下载到环境变量与多版本切换

做 Java 开发这些年，我几乎每次换服务器、搭新环境，都要在 Linux 上重新折腾一遍 JDK 的下载和安装。这活儿说简单是真简单，说恶心也是真恶心：Oracle 官网的下单入口藏得深、下载慢，版本选错了装完启动就报错，环境变量配好了新开一个窗口又失效……我身边不少同事都在这些地方反复栽跟头。

这篇文章我就把 Linux 下 JDK 下载、安装、环境变量配置、多版本切换、常见报错排查这一整条链路，按我的实际操作经验完整梳理一遍。你不需要再去翻十几篇碎片化教程拼答案，照着这篇走基本能一次过。适合刚入门的 Java 开发、要批量给服务器出环境的运维，以及被各种“JDK no found”折磨的测试同学。

1. 装 JDK 之前先想清楚：版本选型与平台判断

很多人的第一反应是直接去官网下载最新版本，这恰恰是后面出问题的根源。JDK 不像普通软件那样“越新越好”，它在 Linux 上涉及发行版授权、LTS 生命周期、CPU 架构匹配三个问题，任何一个搞错，后面全白搭。

1.1 OpenJDK 与 Oracle JDK 怎么选

先说结论：绝大多数场景下，直接用 OpenJDK 发行版就够了，别一上来就盯着 Oracle JDK。

Oracle JDK 从 JDK 8 的某个 update 开始，就对商用场景收费了。它提供长期支持和商业授权，适合有合规要求、需要 Oracle 官方技术支持的企业。而 OpenJDK 是完全开源免费的，两者在 API 层面基本兼容，源码同源，绝大多数普通项目跑在 OpenJDK 上完全没有问题。

实际开发中常见的 OpenJDK 发行版有几个：

• Eclipse Temurin（Adoptium 项目维护，社区最活跃，推荐）
• Amazon Corretto（AWS 维护，云环境里用得很多）
• Microsoft Build of OpenJDK（微软维护）
• Liberica JDK（BellSoft 维护，兼容性测试比较全）

我自己的习惯是：生产服务器优先用 Temurin 或者 Corretto，安全补丁跟得勤，文档也多。除非项目有硬性合规要求，否则不建议为了“Oracle 官方”四个字去付费。

1.2 版本号别乱跟风：LTS 才是生产环境的底线

Java 的版本节奏是每半年出一个新版本，但只有 LTS（长期支持）版本才是生产环境该待的地方。目前大家用得最多的 LTS 就这几个：

• JDK 8：老项目的绝对主力，很多遗留系统还在上面跑
• JDK 11：Spring Boot 2.x 时代的常见选择
• JDK 17：Spring Boot 3.x 的硬性要求，当前最主流
• JDK 21：新一代 LTS，新项目可以考虑

怎么判断自己该装哪个版本？三步走：

1. 看项目配置文件，Maven 项目看pom.xml里的<java.version>，Gradle 项目看build.gradle里的sourceCompatibility
2. 看运行环境要求，比如 Spring Boot 3 强制 JDK 17 及以上
3. 实在没要求，就选 JDK 17，兼容性和性能都足够稳妥

还有一类比较特殊的场景，比如 JMeter 5.x，官方文档写的是支持 JDK 8/11/17，很多人为了省事装了最新版 JDK 21，反而出现奇怪的插件兼容问题。这类工具型软件，建议严格按它的要求走。网上经常有人问“jdk降级到17怎么弄”，多半就是一开始装了太高版本，后面又被迫切回来。所以开头选稳一点，后面就少折腾。

1.3 先确认 CPU 架构，再谈下载

这一步最容易被忽略，但错一步整个包就白下了。Linux 服务器的 CPU 架构常见两种：

• x86_64 / amd64：绝大多数云服务器和物理机
• aarch64 / arm64：ARM 架构服务器、部分国产芯片设备

判断命令很简单：

uname -m

输出x86_64就下 x64 的包，输出aarch64就下 aarch64 的包。Oracle 官网下载页会把 Linux x64、Linux aarch64 分成两个下载项，Adoptium 网站也有类似区分。选错了安装包，装的时候不一定报错，但运行 Java 程序时很可能直接抛“bad ELF interpreter”或者“cannot execute binary file”，那时候再排查只会浪费时间。

2. JDK 下载渠道全对比：官网直下、镜像源、包管理器

JDK 的下载渠道五花八门，我整理下来主要就三类：Oracle 官网直接下载、开源项目官网或镜像站下载、系统包管理器安装。各有各的适用场景，下面挨个说清楚。

2.1 Oracle 官网下载流程与注意事项

Oracle 官网是所有 JDK 版本最全的源头，地址是https://www.oracle.com/java/technologies/downloads/。页面默认展示 JDK 21 等较新版本，想下老的 8u 系列需要往下翻找存档入口。

在 Linux 服务器上操作，基本流程是这样的：

1. 找到对应版本的下载区域，选择 Linux 标签页
2. 根据uname -m的结果选 x64 或 aarch64 的 tar.gz 包
3. 点击下载，浏览器会自动弹出许可协议确认，需要勾选接受
4. 拿到下载链接后，用 wget 直接在服务器上下载

wget https://download.oracle.com/java/17/latest/jdk-17_linux-x64_bin.tar.gz

有一点要注意：Oracle 网站对部分旧版本的 tar.gz 下载做了登录墙，尤其是 JDK 8u 的老版本和部分中间版本，必须注册 Oracle 账号并登录后才能下载。如果服务器上没有图形界面，建议在本地浏览器登录后获取直链，再传到服务器上，或者直接用下面的开源发行版，没有这么多限制。

2.2 Adoptium / Eclipse Temurin：开源社区主力

我觉得对于绝大多数开发者，Adoptium 才是更好的下载入口，地址是https://adoptium.net/。它把 JDK 版本、操作系统、架构、包格式都做成下拉选项，选完直接给直链，不需要登录。

它的下载链接还可以直接用命令拼接，方便在服务器上拉包。比如下载 Temurin 17 的 Linux x64 tar.gz：

wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.10%2B7/OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz

这里的%2B是 URL 编码里的加号，因为 Adoptium 的版本号格式是17.0.10+7，加号放到 URL 里必须编码，直接复制带加号的链接往往下载失败。这个细节坑过不少人。

2.3 用 apt/yum 包管理器安装，最省事但有版本限制

如果对版本没有特殊要求，用系统自带的包管理器安装是最省事的方案，环境变量和软链接系统都帮你处理好了。

Debian/Ubuntu 系：

sudo apt update sudo apt install openjdk-17-jdk

RHEL/CentOS 系：

sudo yum install java-17-openjdk-devel

装完默认安装在/usr/lib/jvm/目录下，java -version直接就能用。但缺点也很明显：软件源里有什么版本，你才能装什么版本。CentOS 7 的默认源只有 JDK 8，想装 17 还得换源或者手动解压；Ubuntu 22.04 默认源里有 JDK 17 和 21，还算够用。如果项目对版本有新要求，大概率还是得走 tar.gz 手动安装这条路。

2.4 下载完必须做的事：校验 SHA-256

这一步我强烈建议所有人都不要跳过，尤其是从非官网渠道或镜像站下载的包。下载过程中网络中断、CDN 节点异常，都可能导致文件损坏，解压到一半报错还算好的，怕的是文件被篡改后你浑然不觉，把带问题的 JDK 装进生产环境。

官网每个下载项旁边都会给出一串 SHA-256 校验值，下载完比对一下：

sha256sum jdk-17_linux-x64_bin.tar.gz

拿输出的哈希值和官网公布的对照，一致再解压。不一致就重新下载，别心存侥幸用损坏的包继续装。实测下载大文件时出错的概率真不低，这个习惯能帮你省去后面一整晚的排查时间。

3. Linux 下 JDK 安装全流程：从解压到环境变量生效

下载环节解决之后，安装就进入正题了。我把最常用的 tar.gz 手动安装和 rpm/deb 包安装两条路都讲一遍，你按自己的发行版和习惯选一条走。

3.1 tar.gz 手动安装：目录规划和解压细节

tar.gz 手动安装的好处是版本完全可控，装几个版本共存都没问题。关键是要先规划好安装目录，别随手解压到/tmp或者家目录，最后自己都找不到。

我习惯统一放到/usr/local/java/下，结构清晰，一看就知道机器上有哪些 JDK 版本：

cd /tmp wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.10%2B7/OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz sudo mkdir -p /usr/local/java sudo tar -xzf OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz -C /usr/local/java/

解压完成后，目录结构是/usr/local/java/jdk-17.0.10+7/。这里有个推荐做法：解压后建一个不带版本号的软链接，比如/usr/local/java/current指向当前要用的版本，这样以后升级版本只需要改软链接指向，环境变量路径不用动。我自己的服务器就一直是这个格局：

sudo ln -s /usr/local/java/jdk-17.0.10+7 /usr/local/java/current

另外建议确认一下解压出来的目录归属，如果是 root 权限下载解压的，其他用户可能会在读写上有问题：

sudo chown -R root:root /usr/local/java/jdk-17.0.10+7

3.2 环境变量配置：/etc/profile、/etc/profile.d 与 ~/.bashrc 的区别

解压完不等于装完，Linux 不认识 JDK 在哪，必须配置环境变量。这一步是翻车重灾区。

先理解三个配置文件的分工：

• /etc/profile：系统级登录脚本，所有用户登录时都会执行
• /etc/profile.d/下的脚本：登录时会被/etc/profile自动引用，按文件名排序执行
• ~/.bashrc：当前用户的 Bash 非登录交互式 Shell 配置

最佳实践是不要直接改/etc/profile，而是新建一个独立的/etc/profile.d/jdk.sh，这样职责单一，出了问题也容易回退：

sudo vim /etc/profile.d/jdk.sh

写入以下内容：

export JAVA_HOME=/usr/local/java/current export PATH=$JAVA_HOME/bin:$PATH

然后执行：

source /etc/profile.d/jdk.sh

为什么用$JAVA_HOME/bin而不是直接写死路径？因为以后切版本只要改软链接，这一行不用动。为什么 PATH 要把$JAVA_HOME/bin放在最前面？因为如果机器上存在其他版本的 Java（比如系统自带的 openjdk 在/usr/bin/java），放在前面才能确保优先使用你自己指定的版本，放在后面会被系统版本抢先，Java 命令执行的还是旧的。

关于 CLASSPATH，现在的新版 JDK 根本不需要手动配置，编译器会自动处理类路径。网上很多老教程还在教export CLASSPATH=.:$JAVA_HOME/lib，那是 JDK 8 之前的老黄历了，加上反而可能引发诡异问题，我不建议配。

3.3 验证安装与常见配置误区

配置完环境变量，验证环节别只敲一条命令就完事。我一般按顺序检查这几条：

echo $JAVA_HOME java -version javac -version which java

正常输出应该类似：

/usr/local/java/current openjdk version "17.0.10" ... javac 17.0.10 /usr/local/java/current/bin/java

java -version能跑、javac -version报错的情况很常见，一般是 PATH 只加了$JAVA_HOME/bin但 JAVA_HOME 写错了，导致 Java 命令靠系统路径找到旧版本。所以 JAVA_HOME 和 PATH 两行要一起配。

还有个细节：which java返回的路径不在你指定的目录里，说明 PATH 顺序有问题，回去检查第 3.2 节说的那个顺序原则。另外，java第一次执行时会在用户家目录下生成一个hsperfdata_xxx之类的性能数据目录，这是正常现象，不是垃圾文件，别手抖删掉。

3.4 rpm/deb 包安装与 update-alternatives 多版本切换

如果下载的是 rpm 包，安装命令直接：

sudo rpm -ivh jdk-17_linux-x64_bin.rpm

rpm 包会安装到/usr/java/jdk-17.x.x/，并且自动注册到系统的alternatives机制里，java -version默认就能用。deb 包同理：

sudo dpkg -i jdk-17_linux-x64_bin.deb

多版本共存的管理，推荐用update-alternatives，这是 Linux 系统的标准方案。手动安装的 tar.gz 包也可以注册进去：

sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk-17.0.10/bin/java 100 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk-17.0.10/bin/javac 100

切换版本：

sudo update-alternatives --config java

这是我在有多套 JDK 的机器上最常用的命令，比手动改软链接安全得多。如果你遇到某个图形工具比如 DBeaver 启动用的还是旧 JDK，那多半是它自己的启动脚本里写死了-vm参数，去它的dbeaver.ini里改指向新版本就行，和系统环境变量是两回事。

4. 环境变量配置失败与“找不到 JDK”的排查实录

“jdk环境变量配置失败”“找不到jdk”这类问题，是 Linux 下 Java 环境最经典的拦路虎。我把真正高频的几个故障场景和一个完整的排查套路放这里，你遇到问题对着查就行。

4.1 为什么 source 之后还是 java: command not found

这类问题的典型状态是：明明配置了环境变量，也执行了source，但开新窗口或者重启后，java命令还是找不到。

顺着这个顺序排查：

echo $JAVA_HOME echo $PATH

如果JAVA_HOME为空，说明配置文件没生效。常见原因如下：

• 配置文件放到了~/.bashrc，但你是通过 SSH 登录的非交互式方式执行命令，根本没加载它
• 配置文件里有空格，比如export JAVA_HOME = /usr/local/java，这行代码在 shell 里是“执行一个叫 JAVA_HOME 的命令”，当然不会成功
• 执行source的时候不是同一个终端会话，或者source后没重新打开窗口，而 GUI 环境里的新终端默认不加载/etc/profile
• 系统默认 shell 不是 bash，用户的~/.zshrc里没有同样配置

我自己的排查经验是：先打印 JAVA_HOME 和 PATH，为空大概率是文件放错位置或引号问题，直接看配置文件内容就能定位。不为空但 java 找不到，基本就是 PATH 里没有$JAVA_HOME/bin，或者该路径不存在（软链接断链）。

还有一个生产环境经常踩的坑：服务是用 systemd 管理的，你手动在 shell 里配好了环境变量，但服务进程的Environment=里没配，重启服务后它用的还是系统默认路径，表现也是“找不到jdk”。这种情况需要把Environment="JAVA_HOME=..."和Environment="PATH=..."写进 service 文件里。

4.2 /etc/profile 配置坏了导致登录异常怎么办

如果直接改/etc/profile时手滑写错了语法，比如少个引号、括号不匹配，会导致整个系统登录流程卡住，新 SSH 会话都无法正常建立。这个问题我处理过不止一次，每次都有同事紧张得不行。

正确的应急办法是：Linux 默认登录时如果 profile 执行失败，会退回到一个基础环境，你仍然能通过新开一个 SSH 窗口执行命令，只是 PATH 是个很精简的版本。此时用绝对路径调用编辑器，进去把错误改回来：

/usr/bin/vim /etc/profile

如果连编辑器都进不去，可以这样启动一个干净的 shell：

/bin/sh -c "/usr/bin/vim /etc/profile"

改完语法，建议先做一个语法检查再继续用：

bash -n /etc/profile

没有输出就是语法没问题。这也是我坚持让大家用/etc/profile.d/jdk.sh独立文件的原因：出了问题删掉这个文件就能恢复，不需要跟整个/etc/profile挤在一起。

4.3 PATH 顺序、软链接冲突与多 JDK 并存问题

机器上多套 JDK 并存时，最常见的怪现象是java -version显示 17，但javac -version显示 1.8，两边版本对不上。

原因很简单：java和javac两个命令各自找到了不同 JDK 的路径。java走的是你 PATH 里指定的$JAVA_HOME/bin，而javac可能被/usr/bin/javac的软链接先劫持了，或者反过来。

排查可以用：

type -a java type -a javac ls -l /usr/bin/java /usr/bin/javac update-alternatives --display java

ls -l看/usr/bin/java是个什么样的软链接，指向哪里的 alternatives，再逐层往里跟，直到找到真实路径。大多数这类问题都能通过update-alternatives --config把 java 和 javac 统一指到同一套 JDK 解决。

还有种情况是/usr/bin/java这个软链接直接失效，显示红色断链状态。这时候用 update-alternatives 重新安装对应条目就行：

sudo update-alternatives --install /usr/bin/java java /usr/local/java/current/bin/java 100

4.4 卸载旧 JDK：rpm -e、apt remove 的正确姿势

卸载这个东西，很多人上来就是rm -rf一顿乱删，结果系统里残留了一堆软链接，连锁反应把其他工具搞崩。按安装方式分三类处理：

tar.gz 手动安装的，删目录加清配置：

sudo rm -rf /usr/local/java/jdk-17.0.10 sudo rm -f /etc/profile.d/jdk.sh

rpm 安装的，先查包名再卸载：

rpm -qa | grep -i jdk sudo rpm -e <包名>

deb 安装的（Ubuntu 系）：

dpkg -l | grep -i openjdk sudo apt remove --purge openjdk-17-jdk

注意apt remove --purge会连配置文件一起删，如果之后还要重装同版本，建议保留配置用apt remove openjdk-17-jdk即可。装新版本前把update-alternatives里旧的注册条目也清一下，避免残留下面的软链接：

sudo update-alternatives --remove java /usr/local/java/jdk-8/bin/java

5. 高频问题速查：面试题、常用命令与避坑清单

最后这部分，我把 Linux 下 JDK 相关的面试考点、常用命令和一张速查表整理出来。这些内容既是面试官爱问的，也是平时运维排查真正会用的，放到一起讲。

5.1 面试常问的 JDK/JRE/JVM 区别与 Linux 环境考察点

三者的关系是所有 Java 面试的第一题：JDK 是 Java Development Kit，包含 JRE 和开发工具（javac、jdb、jpackage 等）；JRE 是 Java Runtime Environment，包含 JVM 和核心类库，只能运行不能开发；JVM 是 Java Virtual Machine，负责把字节码解释或编译成机器码执行。

在 Linux 场景下，面试官更爱问的是实操层面的问题，比如：

• 如何在 Linux 上查看当前 Java 进程的堆使用情况？答：jstat -gc <pid>，或者jmap -heap <pid>
• 怎么定位 Java 进程占用 CPU 过高的问题？答：top找到 PID，jstack <pid>导出线程栈，再配合top -H -p <pid>看线程级占用
• 如何设置 JVM 启动参数跑一个 jar？答：java -Xms512m -Xmx1024m -jar app.jar

这些命令都属于 JDK 自带的工具，都在$JAVA_HOME/bin目录下。所以你配置好 PATH 之后，jps、jstack、jmap、jstat这些命令也应该能直接用，如果某个工具命令找不到，先检查 PATH 配置是不是被搞乱了。

5.2 JDK 相关 Linux 常用命令清单

我在给服务器配 Java 环境时用得最多的命令，整理成一个清单：

对运维来说，经常还会配合ps -ef | grep java看进程启动参数，配合nohup java -jar app.jar > app.log 2>&1 &做后台启动。这些命令组合起来，处理生产环境 Java 服务的基本问题就够了。

5.3 高频故障速查表

延续前面几个章节的排查思路，我按问题现象、常见原因、解决办法三个维度做了一张速查表，可以直接对照着用：

这一套流程走下来，我不敢说你从此再也不碰 JDK 安装问题，但至少再遇到类似报错，你能按图索骥，而不是靠猜。

最后再分享一个我个人的习惯：把 JDK 的安装过程写成一条 Shell 脚本，以后新机器一跑脚本就完事。核心就是把下载、解压、建软链接、写/etc/profile.d/jdk.sh、source这几步串起来，版本号用变量传参。这样不管是帮同事救急还是给新服务器出环境，都只是敲一行命令的事。我有好几台服务器就是靠这个脚本批量搞定的，省下的时间足够再喝一杯咖啡。