★ FEATURED ARTICLE 简介一份面向 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.rarfile 命令输出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 或 tarRAR 格式在 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/jdk1.8.0_211内网生产、多版本并存需要手动创建 /opt/java/usr/local/java单机开发机容易与 /usr/local/bin 下已有命令混淆/usr/lib/jvmRHEL 系统级管理惯例权限敏感普通用户写入容易失败保留在解压目录临时测试重装系统后所有配置失效把目录迁到 /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 文件里加一行EnvironmentJAVA_HOME/opt/java/jdk1.8.0_211 EnvironmentPATH/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 -versionjava 正常 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-alternativesRHEL 系官方方案生产服务器上经常同时躺着 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它会列出一张表输入对应数字切换。如果你在注册时加了 --slavejava 和 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/binln -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 deniedRAR 在 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 手动指认 SDKJMeter 通过 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 21 | 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_211java.home 必须是 /opt/java/jdk1.8.0_211 或它软链接后的真实路径。如果输出显示 1.8.0_201 或者路径变成系统的 OpenJDK 目录说明有旧版本抢先占位回去查 PATH 顺序。整套体检下来不到一分钟。最后把关键输出和我们的配置对比一下就能判断是哪一层出了问题。这个流程我到现在都保留着。每次帮别人排查完 JDK 问题最后一句话都是跑一遍这个把输出发我。因为环境变量这种黑匣子问题光靠我觉得配了是没用的实际生效的路径和版本才能说明一切。从那以后我每次部署完都强制走一遍这三轮体检确认 java.home、java.version、javac 输出都对得上才敢把终端关掉。这套习惯救了很多次场希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
