Linux下JDK 1.8.0_211安装全攻略：RAR解压、环境变量与多版本配置

简介：一份面向 Linux x64 平台的 JDK 1.8.0_211 安装包，适合需要在 Ubuntu 等系统上搭建 Java 开发环境的开发者使用。压缩包内含完整 JDK/JRE 文件，省去 Oracle 官网注册与下载的繁琐流程，解压并配置环境变量后即可编译运行 Java 程序。包体共 1589 个文件，约 163.34MB，以 jar 库文件、xml 配置、properties 配置、so 动态库、png 图标等类型为主，结构清晰，便于直接放置到 /usr/lib/jvm 目录使用。目前已有 626 人浏览学习。该版本包含 javac、javadoc、jdb、jconsole 等完整工具链，支持 Lambda 表达式、Stream API 等 Java 8 特性，并优化了 JVM 与 G1 垃圾收集器，兼顾功能与性能，适合日常开发、课程实验或服务器部署。压缩包内还附有 man 手册、配置模板等辅助文件，目录组织与官方发行版一致，便于按需提取组件，也可作为长期维护项目的基线环境。

1. 直接上手 jdk1.8.0_211_linux_x64：这个版本为什么还有人在找

昨天刚帮一个同事排查完 jdk 环境变量配置失败的问题，折腾半天，最后定位到是 rar 解压后可执行权限丢了。都 2025 年了还在跟 jdk1.8.0_211_linux_x64 打交道的，多半不是图新鲜，而是被老项目捆住了。Spring Boot 2.3.x、Hadoop 生态、JMeter 压测脚本，还有一堆只认 Java 8 的国产中间件，用新 JDK 跑就是各种玄学报错。这个资源就是一个打包成 RAR 的 Linux x64 版 JDK 8，适合 x86_64 架构的 CentOS/RHEL 7、Ubuntu 16.04-20.04，以及那些不能直接连 Oracle 官网的内网服务器。

很多人在第一步就卡住了：从 Windows 上传的 .rar 文件，Linux 上不知道拿什么解；解压完又不知道往哪放；环境变量写错一个符号，java -version 永远输出旧版本。下面我把从解压、目录规划、环境变量配置到多 JDK 切换的完整流程走一遍，顺手把几个最常见的坑标出来。新手可以照着命令一步步复现，熟手重点看第 4、5 章的参数边界和排查思路。

2. 把 RAR 包在 Linux 上安置好：解压、校验与目录规划

2.1 先确认 CPU 架构和压缩包完整性

很多人拿到 rar 包后的第一反应是丢到 Linux 上用 tar 解，结果报Cannot open: No such file or directory或者gzip: stdin: not in gzip format。这不是文件损坏，而是系统里根本没有处理 RAR 格式的解压器。JDK 这个 rar 包通常四十到五十万字节级别，先做两个基础检查，确定包本身没问题再往下走。

# 查看压缩包真实格式，确认是 RAR 而不是改后缀的 zip file jdk1.8.0_211_linux_x64.rar # 确认当前系统架构，只有 x86_64 才能用这个包 uname -m # 查看文件大小，和下载页面标注对比一下 ls -lh jdk1.8.0_211_linux_x64.rar

file 命令输出RAR archive data, v5就说明是标准 RAR5 包；如果输出变成Zip archive data，那后缀是假的，解压方式完全不同。uname -m 输出 x86_64 才对应标题里的 x64，如果在 ARM 服务器上执行显示 aarch64，那这个包装了也没法用，得重新找 ARM 版。

这一步最好把 sha256 也记下来。内网传递的包经常被多手转存，发生过依赖文件被替换的情况。虽然没有官方校验值可以对比，但至少能在解压失败时判断是下载损坏还是工具问题。RAR5 格式自带 CRC 校验，unrar 解压时如果报CRC error，说明文件在传输中已经坏了，别浪费时间调环境变量，直接重新下载。

2.2 用 unrar 解压，不要硬借 7z 或 tar

RAR 格式在 Linux 上没有内置命令，需要单独装 unrar。CentOS 默认源里没有 unrar，要先配 EPEL 源；Ubuntu 上直接 apt 装就行。装完解压时注意 x 和 e 两个参数的区别。

# CentOS / RHEL 7 / 8 yum install -y epel-release yum install -y unrar # Ubuntu / Debian apt update && apt install -y unrar

# x 参数保留 RAR 包内的目录层级，推荐 unrar x jdk1.8.0_211_linux_x64.rar # e 参数会把所有文件平铺到当前目录，不推荐 # unrar e jdk1.8.0_211_linux_x64.rar

我用 unrar x 而不是 unrar e 的理由很直接：Oracle 官方 JDK 解压出来就是一个带版本号的顶层目录jdk1.8.0_211，里面是标准的 bin、lib、jre、include 结构。如果用了 e 参数，这些目录会被直接拆散到当前目录下，后续配置 JAVA_HOME 根本指不到正确路径。解压完成后看到当前目录多了一个jdk1.8.0_211文件夹，才算成功。

如果 unrar 报unknown option: x，先确认版本是不是太老。RAR5 格式需要 unrar 5.0 以上，RHEL 7 自带的 unrar 4.x 经常解不了。内网实在装不上 unrar，另一个实际可用的办法是：把 rar 包传回 Windows 用 WinRAR 解压，重新打包成 tar.gz 再传回 Linux。这个方法笨但很稳，离线环境救急常用。

2.3 目录规划：/opt/java/jdk1.8.0_211 还是 /usr/local

解压出来的目录不建议直接扔在 /root 或 /tmp，也不建议随手 mv 到 /usr/java。我一般放在 /opt/java 下面，原因有三：/usr/local 经常与其他软件冲突，/opt 是专门给第三方应用留的位置；升级 JDK 时只替换 /opt/java 下的目录，其他软链接不用动；CentOS 带 SELinux 时，/opt 默认上下文更宽松，不会莫名出现进程读不了 JDK 文件的问题。

把目录迁到 /opt/java 并验证：

mkdir -p /opt/java mv jdk1.8.0_211 /opt/java/ ls -l /opt/java/jdk1.8.0_211/bin/java

此时先不急着配环境变量，直接执行一次/opt/java/jdk1.8.0_211/bin/java -version。能输出版本信息，说明压缩包没问题，之后所有报错都集中在环境配置层面；如果这一步就报Permission denied，说明 rar 包里的可执行权限丢了，先chmod -R 755 /opt/java/jdk1.8.0_211/bin再继续。先验证再配置这个习惯，能帮你少踩一半坑。

3. 配置 JAVA_HOME 与 PATH：一次写对，别再靠 echo 确认

3.1 全局配置还是单用户配置

配置 Java 环境变量，第一步先决定作用域。生产服务器的服务由 systemd 或 shell 脚本拉起，环境变量需要全局可见，习惯写法是塞进 /etc/profile；开发机上只有自己用，写进 ~/.bashrc 就够了，不会污染系统。

我的建议是，无论哪种场景，都优先在 /etc/profile.d/ 下新建一个 java.sh，而不是直接往 /etc/profile 尾部追加。/etc/profile 被太多软件改过，写错一行所有登录 shell 都受影响，排查时定位困难。而 /etc/profile.d/java.sh 是独立文件，哪天要改 JDK 版本，删掉再新建一个就行，不影响系统其他配置。

如果服务是 systemd 直接管理的，还要单独处理。systemd 默认不读取 /etc/profile，服务进程通过Environment=参数拿到环境变量。常见做法是在 service 文件里加一行：

Environment=JAVA_HOME=/opt/java/jdk1.8.0_211 Environment=PATH=/opt/java/jdk1.8.0_211/bin:/usr/bin:/bin

这段看清了：systemd 服务里配的是Environment=，不是 export。很多人在生产环境里明明手动执行 java 正常，一用 systemctl 启动的 Spring Boot 就报找不到 java，就是因为漏了这一步。

3.2 环境变量持久化的标准写法

在 /etc/profile.d/java.sh 里写入以下内容：

# /etc/profile.d/java.sh # Oracle JDK 1.8.0_211 环境变量 export JAVA_HOME=/opt/java/jdk1.8.0_211 export PATH=$JAVA_HOME/bin:$PATH export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

写好后让配置在当前 shell 生效：

source /etc/profile.d/java.sh java -version echo $JAVA_HOME

这段配置有三个容易出问题的细节。第一，PATH 一定要写成$JAVA_HOME/bin:$PATH，把 JDK 的 bin 目录放在原有 PATH 前面。很多服务器上 /usr/bin 里已经软链了系统自带 OpenJDK，如果顺序写反，java 命令仍然命中旧版本，你以为是配置没生效，其实是顺序问题。

第二，export 语句行尾不能有空格，JAVA_HOME 值后面也不能有斜杠。执行echo $JAVA_HOME | cat -A看到结尾有^M或者空格，所有工具拼接路径时都会报.../bin不存在。第三，CLASSPATH 里的开头点号不能省，它表示当前目录。JDK 8 编译时默认会找当前目录下的类文件，这个点丢了，老项目的javac经常编译通过但运行时找不到自己写的类。

3.3 让 IDEA、Maven、JMeter 都认到这个 JDK

环境变量配好后，IDEA、Maven、JMeter、DBeaver 这类工具还要单独指认，因为它们不一定读 /etc/profile。JMeter 打开$JMETER_HOME/bin/jmeter脚本，顶部变量定义区有JAVA_HOME，直接改成/opt/java/jdk1.8.0_211。JMeter 启动时只读自己的启动脚本，不读系统 profile，这是最容易踩的坑。

DBeaver 这类基于 Eclipse 的工具，在安装目录的 dbeaver.ini 里加一行-vm /opt/java/jdk1.8.0_211/bin/java，注意必须放在 -vmargs 前面，否则不生效。IDEA 的配置在 Project Structure -> SDKs -> 添加 JDK，路径指到 /opt/java/jdk1.8.0_211 后，还要确认 Language Level 是 8。很多人只设置了 JDK 路径，Language Level 还停留在旧项目设置，编译行为还是按更低版本来。

Maven 更特殊，mvn 命令本身是个 shell 脚本，它读取当前 shell 的 JAVA_HOME。如果mvn -v报错，先单独跑java -version，java 正常 mvn 报错，八成是 mvn 脚本拿到的 JAVA_HOME 不对。执行前显式指定一次：

export JAVA_HOME=/opt/java/jdk1.8.0_211 mvn -v

注意这里的 export 只在当前 shell 生效，关掉终端就没了。想让 Maven 长期可用，还是得回到 3.2 节那个 profile 文件，把 JAVA_HOME 持久化。工具配置的这条路走下来你会发现，所有指向最终都落到同一个路径，所以第 2 章的目录规划才那么重要，路径越稳定，后续工具配置越省事。

4. 多 JDK 切换：别在系统里养出"找不到 JDK"的病根

4.1 update-alternatives：RHEL 系官方方案

生产服务器上经常同时躺着 JDK 8 和 JDK 17。老业务要 8，新服务要 17，切换是刚需。CentOS 自带的 alternatives 机制可以管理 java、javac、jar 这些命令的默认指向，避免手动改软链接满天飞。

把 JDK 8 注册进去，同时把 javac 作为附属命令绑定：

# 注册 java 和 javac，优先级设为 1800 update-alternatives --install /usr/bin/java java /opt/java/jdk1.8.0_211/bin/java 1800 \ --slave /usr/bin/javac javac /opt/java/jdk1.8.0_211/bin/javac

切换时执行：

update-alternatives --config java

它会列出一张表，输入对应数字切换。如果你在注册时加了 --slave，java 和 javac 会一起切换，不会出现 java 是 8 但 javac 还是旧版本的分裂状态。优先级这个数字 1800 不是乱填的，它决定多个候选版本共存时谁默认生效。数字越大优先级越高，一般比自己机器上已有的 OpenJDK 高 200 以上比较安全。

这里有个细节：update-alternatives 只管理 /usr/bin/java 这一个路径，如果你的工具根本不走 /usr/bin/java，而是直接写死/opt/java/jdk1.8.0_211/bin/java，那切了 alternatives 也没用。工具侧写的路径什么时候都要和实际版本变更同步改。

4.2 软链接方案：更简单但更隐蔽

觉得 alternatives 的交互式列表不够直观，可以走软链接方案。建一个 /opt/java/default 链接，把 PATH 统一指到 default/bin：

ln -sfn /opt/java/jdk1.8.0_211 /opt/java/default export JAVA_HOME=/opt/java/default export PATH=$JAVA_HOME/bin:$PATH

切换版本时改一个链接：

ln -sfn /opt/java/jdk-17 /opt/java/default

这个方案的好处是只动一个链接，所有 JAVA_HOME 指向 /opt/java/default 的工具瞬间完成切换。缺点是隐患更隐蔽：如果有人直接删了旧 JDK 目录，default 会变成悬空链接，java 命令报No such file or directory，连个像样的提示都没有，排查时容易误判为环境变量配置错误。

4.3 潜在坑：JAVA_HOME 和 alternatives 指向不一致

多 JDK 环境最容易出现的问题，是 JAVA_HOME 和 which java 指向的不是同一个版本。比如 JAVA_HOME 写的是 JDK 17，/usr/bin/java 被 alternatives 切到了 JDK 8，就会发生 shell 里 java -version 是 8，但 Maven 起来是 17 的诡异现象。

检查当前实际生效链路的三个命令：

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

第一条看 PATH 命中的 java 在哪，第二条看最终真实路径，第三条看 JAVA_HOME 变量。如果 which java 的结果不在 $JAVA_HOME/bin 下，说明要么 PATH 顺序有问题，要么 alternatives 接管了 /usr/bin/java 而这个软链和 JAVA_HOME 不一致。把这三个命令的执行结果拼在一起，就能看出是哪一层漂移了。

我还见过一个更极端的案例：一台机器上同时存在 /etc/alternatives/java、/usr/local/java、/root/jdk1.8.0_211 三个 JDK 路径，Java、Maven、IDEA 各指一处，最后花了半天时间才理顺。每装一个新 JDK，就把旧的从 PATH 里移除，不要因为"留着备用"就堆着。版本太多不是能力问题，是给自己埋雷。

5. 环境变量配置失败的常见问题与排查

5.1 现象：java -version 没变，重启后配置失效

先说最常见的两种翻车现场。第一种是java -version输出的还是旧版本号，或者提示command not found。原因基本是 PATH 里 JDK 的 bin 目录顺序靠后，或者没写进当前 shell 的加载路径。检查 /etc/profile.d/java.sh 是否写成$JAVA_HOME/bin:$PATH，然后执行which java看实际命中路径。如果 which 结果指向 /usr/bin/java，再readlink -f /usr/bin/java看最终落到哪个目录。

第二种是 source 之后 java 正常，重启 shell 又找不到 Java。原因在于登录 shell 读取 /etc/profile，而脚本执行场景或新开终端时不一定会重新加载所有 profile 文件。解决办法是把配置同时放进 ~/.bashrc，或者在 systemd service 里显式设置 Environment。这个问题在 CI 流水线和开机自启服务里尤其常见，调的时候别只盯着终端窗口。

5.2 现象：JAVA_HOME 已配置但 mvn 报目录无效

Maven 报JAVA_HOME is set to an invalid directory，但 echo 出来的路径明明存在。这类问题多半出在不可见字符上。从 Windows 编辑后上传的 profile 文件，行尾通常会带\r，在 Linux 下显示为$结尾的脏数据。

# 检查每行结尾是否有多余的 ^M cat -A /etc/profile.d/java.sh

有^M就清掉：

sed -i 's/\r$//' /etc/profile.d/java.sh source /etc/profile.d/java.sh

另外 JAVA_HOME 末尾不要加斜杠。Maven 校验时会拿 JAVA_HOME 拼接/bin，写成/opt/java/jdk1.8.0_211/会让拼接结果变成双斜杠，某些版本会判断为非法目录。这个细节看起来很小，实际排查时干扰很大。

5.3 现象：解压后 java 报 Permission denied

RAR 在 Windows 下打包时经常丢失可执行位，传到 Linux 解压后 bin 目录文件权限是 644，没有 x 权限。表现是Permission denied，很多人会误以为是环境变量或系统问题，其实只是文件权限不对。

chmod -R 755 /opt/java/jdk1.8.0_211/bin

如果 jre 目录下也有独立 bin，一并处理：

chmod -R 755 /opt/java/jdk1.8.0_211/jre/bin

我每次解压完先统一执行一次，再开始配环境变量。这个习惯帮我省了后面所有边角报错。

5.4 现象：切换 alternatives 后 Spring Boot 服务仍是旧版本

原因在于正在运行的 JVM 启动时就固定了 java 路径，切换默认版本只对后续启动的进程生效。另外 systemd service 里如果写死了ExecStart=/usr/bin/java -jar app.jar，它会一直走 /usr/bin/java 的软链。如果这个软链被其他包管理器改过，服务跑的就不是你以为的 JDK。

排查顺序是先停服务，再确认当前 java 指向，最后看进程实际路径：

systemctl stop your-service readlink -f $(which java) ps -ef | grep java | grep -v grep

如果 ps 里显示的启动路径还是旧版本，说明 ExecStart 或 Environment 里写死了绝对路径。改完 unit 文件后别忘systemctl daemon-reload，这一步漏掉，改了配置也不会生效。

5.5 现象：java 正常但 idea、jmeter 识别不到 JDK

这类工具属于"不读系统环境变量"的例外。IDEA 通过 Project Structure 手动指认 SDK，JMeter 通过 bin/jmeter 脚本顶部 JAVA_HOME 变量读取，DBeaver 通过 .ini 文件里的 -vm 参数。配置完仍然找不到，多数是因为指认路径时写到了 jdk 目录本身，而工具要求指到 bin 下的 java 文件。

解决办法是按工具各自的配置入口重设，IDEA 选到 /opt/java/jdk1.8.0_211 目录即可，JMeter 和 DBeaver 明确写到 java 可执行文件。记住这个区分："系统命令读 PATH，开发工具读自己的配置"，能减少一半这类排查。

6. 部署前的一分钟体检：让 JDK 8 的真实配置现形

装了这么多东西，最后必须有个验证手段。我不信"我配好了"这句话，只信命令输出的实际结果。部署前花一分钟做三轮体检，确认 JAVA_HOME、PATH、运行时版本三者一致。

先用java -XshowSettings:vm -version这条命令，让 JVM 自己把生效的配置打出来。对 JDK 8 来说，可以看到默认堆大小、Java Home 路径、类加载器设置。诊断目标集中在 java.home 这个属性上：

java -XshowSettings:vm -version 2>&1 | grep -i "java.home"

如果输出的路径不是 /opt/java/jdk1.8.0_211，说明有更高优先级的变量抢先注入了环境。比如_JAVA_OPTIONS或JDK_JAVA_OPTIONS这类全局注入变量，它们会覆盖 JAVA_HOME 指定的运行时。这时用env | grep -i java把所有 Java 相关环境变量拉出来看，直接定位是谁在拦截。

然后是编译功能验证。JDK 环境只看 java 命令是看不全的，javac 也必须工作。写一个最简单的小程序从头编译运行：

cd /tmp mkdir -p jdk-check cd jdk-check cat > HelloJdk.java <<'EOF' public class HelloJdk { public static void main(String[] args) { System.out.println("java.version=" + System.getProperty("java.version")); System.out.println("java.home=" + System.getProperty("java.home")); } } EOF javac HelloJdk.java java HelloJdk

输出里 java.version 必须是 1.8.0_211，java.home 必须是 /opt/java/jdk1.8.0_211 或它软链接后的真实路径。如果输出显示 1.8.0_201 或者路径变成系统的 OpenJDK 目录，说明有旧版本抢先占位，回去查 PATH 顺序。

整套体检下来不到一分钟。最后把关键输出和我们的配置对比一下，就能判断是哪一层出了问题。

这个流程我到现在都保留着。每次帮别人排查完 JDK 问题，最后一句话都是："跑一遍这个，把输出发我。"因为环境变量这种黑匣子问题，光靠"我觉得配了"是没用的，实际生效的路径和版本才能说明一切。从那以后，我每次部署完都强制走一遍这三轮体检，确认 java.home、java.version、javac 输出都对得上，才敢把终端关掉。这套习惯救了很多次场，希望帮到你。

本文还有配套的精品资源，点击获取