Linux下JDK 1.8解压安装与环境变量配置完整指南

简介jdk1.8.0_211_linux_x64.rar 是一份针对 Linux x64 平台的 Java 开发工具包压缩文件内置了 Java 运行环境、编译器、文档生成器、调试器等开发所需的完整组件尤其适合在 Ubuntu 这类系统上快速准备 Java 8 编程环境。压缩包内共收录 1589 个文件主要包含 jar 类库文件、xml 配置文件、properties 属性文件、png 图片以及 so 动态库等其中 jar 文件是程序运行的核心依赖xml 与 properties 用于框架与系统配置图片和 html 则多见于界面组件与本地文档整体体积约 163.34 MB。该资源已吸引 625 人下载学习。JDK 1.8 在语言特性上加入了 Lambda 表达式、Stream 流式处理、函数式接口等新语法并对垃圾回收器进行了优化稳定性和生态兼容性都很好。解压后的目录结构完整bin 目录存放常用命令行工具lib 目录保留核心类库用户只需配置环境变量即可直接使用既适合维护基于 Java 8 的旧项目也适合开发者系统学习和体验这一经典版本的高效编程方式同时附带的监控与诊断工具也能帮助排查运行问题。 每次看到jdk1.8.0_211_linux_x64.rar这个文件名被传到群里后面通常跟着一句“到底怎么装啊”。这个版本是 2019 年 4 月发布的 Java 8 Update 211也就是 Java 8 生命周期里被广泛使用的一个更新配合 Linux x64 平台几乎是国内服务器上最常见的 JDK 8 形态。但请注意Oracle 官方发布的 Linux x64 JDK 格式是 tar.gz不是 rar。看到 .rar 后缀说明这是第三方在 Windows 上重新打包过的可能来自网盘、QQ 群或者各种“一键安装包”。这篇文章就把整个流程彻底讲透怎么判断包能不能用、怎么解压、怎么配环境变量、怎么验证、怎么和生产环境里的 Tomcat、IDEA、Maven 共存也把我在服务器上踩过的各种环境变量坑一并说清楚。不管是刚入门的 Linux 运维还是被老项目绑定的 Java 开发都可以照着操作。1. 拆解文件名从 jdk1.8.0_211_linux_x64.rar 你能读出什么很多人拿到文件名就直接tar -zxvf去解压发现报错又一脸懵。这不能怪你因为文件名里的信息量其实很大只是没有系统拆解过。搞清楚每一段的含义后面所有操作都会顺理成章。1.1 每一段都在说什么我们把这个文件名拆成几段来看文件名片段含义jdkJava Development Kit完整开发工具包包含 JRE、编译器 javac、调试器 jdb 等1.8.0_211Java 8 的第 211 个更新版本通常写作 8u211linux目标操作系统是 Linux不是 Windows、macOS、Solarisx64面向 64 位 x86 架构也就是 amd64对应 Intel 和 AMD 的主流服务器 CPU.rar第三方用 WinRAR 等工具打包的压缩格式Oracle 官方不发布这种格式看到 jdk 而不是 jre说明这个包里应该有 javac。很多初学者下载了一个只有 jre 的包配完环境变量后发现javac -version报 command not found就是因为包选错了。看到 x64 而不是 i586 或 arm64说明你的系统必须是 64 位 x86 架构否则装了也没法运行。至于 .rar 后缀是我每次看到都会皱眉的地方。Oracle 官方在 Linux 平台只提供 .tar.gz 格式任何一个 .rar 格式的 JDK 包都意味着它被某个第三方重新打包过。重新打包本身不一定有问题但没人能保证里面有没有多放东西、有没有改过 release 文件、有没有顺手塞一个脚本进去。生产环境里我建议直接去 Oracle Archive 或 Adoptium 下载官方 tar.gz安全第一。1.2 为什么 8u211 这个版本至今还有人装Java 8 的更新版本号从 8u20 一路走到 8u202、8u211、8u221再往后还有 8u231 等。8u211 是 2019 年 4 月发布的正好处在 Oracle JDK 商用授权策略调整的节点上所以很多存量项目和企业内部规范都把 8u211 作为一个约定俗成的基线版本。从技术角度看8u211 之后的 Java 8 更新并没有在语法或 JVM 架构上做出颠覆性改动对于跑着 Spring Boot 2.x、Hadoop、Kafka、Tomcat 8/9 的老项目来说8u211 完全够用。而且 JDK 8 的 GC 参数、JVM 调优经验、ClassLoader 行为在这些年已经被无数团队验证过生产环境求稳没人愿意为了“升级而升级”。再加上网上大量教程和依赖库都基于 Java 8 编写新人入行接触的第一个 JDK 版本也往往是 8所以它仍然是服务器上的常青树。理解了版本背景再往下操作就不会有“为什么我都装好了还提示版本不对”的疑惑。2. 解压 .rar 之前先检查系统并确认包是否干净不要急着解压。服务器上的一个原则是先看环境再动手。很多环境变量配置不上、java -version 显示的还是旧版本问题往往出在“系统里原本就有其他 JDK”或者“架构不匹配”。2.1 环境自检四条命令登录服务器后先执行下面四条命令uname -m cat /etc/os-release which java java -versionuname -m输出 x86_64 就代表系统是 64 位 x86 架构和文件名里的 x64 匹配。如果输出 aarch64说明是 ARM 架构这个 x64 包装了也跑不了。cat /etc/os-release用来确认发行版和版本CentOS 7、Ubuntu 18.04、openEuler 等系统在后续依赖安装上会有区别。which java和java -version则是检查机器上是不是已经装了 Java这一点太重要了。我在实际排查中发现很多服务器默认带了 OpenJDK可能是系统安装时装上的也可能是某个业务组件依赖自动拉进来的。如果不先查清楚等会儿你配置的 JAVA_HOME 指向新装的 JDK但输入 java 时用的还是 /usr/bin/java 里的系统版本怎么排查都查不明白。2.2 rar 包的处理unrar 安装、SHA256 校验和官方 tar.gz 替代如果已经确定就是要用这个 rar 包那第一步是安装解压工具 unrar。CentOS/RHEL 系列可以这样装yum install -y epel-release yum install -y unrarUbuntu/Debian 系列用apt update apt install -y unrar安装完成后解压unrar x jdk1.8.0_211_linux_x64.rar这里有个小细节unrar x会保留压缩包内的目录结构而unrar e会把所有文件直接解压到当前目录容易把文件打散。安装 JDK 这种目录结构很关键的场景一定用x。解压之前强烈建议做一次完整性校验sha256sum jdk1.8.0_211_linux_x64.rar把输出的哈希值和下载源提供的官方哈希值对比。问题是第三方 rar 包往往没有官方哈希来源所以这步很多时候只能用来确认文件没有在传输过程中损坏无法证明内容是干净的。这也是我不推荐在生成环境用 rar 包的核心原因。如果你手头有条件我建议直接换成官方 tar.gz 包地址可以用 Oracle Archive 或者清华 Adoptium 镜像。包名大概是jdk-8u211-linux-x64.tar.gz下载后用 sha256sum 校验一次解压命令是tar -zxvf jdk-8u211-linux-x64.tar.gz看到目录jdk1.8.0_211和官方 release 文件心里才踏实。2.3 清理系统已有 JDK避免与 OpenJDK 打架如果自检时发现系统里有旧 JDK我建议先清理干净。CentOS 上常见的包名是java-1.8.0-openjdk或java-11-openjdk先查再删rpm -qa | grep -i jdk yum remove -y java-1.8.0-openjdk java-1.8.0-openjdk-develUbuntu 上可以用dpkg -l | grep openjdk查询再用apt purge卸载。有些场景下系统自带的 OpenJDK 是某个应用依赖的不能随便卸载那也要用update-alternatives --config java把默认 Java 切到新装的 JDK。这个命令会列出系统里所有注册过的 java 路径让你选择默认值。很多人忽略了这个机制结果 PATH 里的 /usr/bin/java 始终指向旧版本java -version怎么看都还是旧号。清理完旧版本之后再进入安装配置阶段环境就干净多了。3. JAVA_HOME、PATH、CLASSPATH环境变量到底该怎么写配置环境变量是整个安装过程中最容易出问题的一步。很多教程直接让你复制一段配置也不解释含义导致一行写错就全部不生效。所以我先讲目录规划再逐行拆解配置最后说清楚那些“配了也没用”的原因。3.1 目录规划与软链接的设计解压后的目录通常叫jdk1.8.0_211问题是你不知道它会被解压到哪里。我见过有人直接解压到/root/Downloads、/home/ubuntu/然后 JAVA_HOME 一路上都是临时路径一换用户或者重启进程就找不到 JDK。正规做法是统一放到/usr/local/java下面mkdir -p /usr/local/java tar -zxvf jdk-8u211-linux-x64.tar.gz -C /usr/local/java如果从 rar 里解压出来的目录不在这个路径就移动一下mv jdk1.8.0_211 /usr/local/java/然后建一个软链接ln -s /usr/local/java/jdk1.8.0_211 /usr/local/java/current为什么要多此一举做一个 current 软链接因为以后你很可能还会装 JDK 17、JDK 21如果脚本和配置文件里全部写死/usr/local/java/jdk1.8.0_211每次切版本都要去改一堆配置。指向 current 之后切换版本只需要把软链接重新指一下所有引用 current 的地方自动跟着变。这里的/usr/local/java/current/bin/java就相当于一个稳定的入口。顺带说一句不要把 JDK 解压到/opt之外的个人目录。多用户服务器上其他服务账号可能没有权限进入/home/ubuntu导致 Tomcat 或 systemd 服务启动时直接 Permission denied。3.2 环境变量配置文件逐行讲解环境变量有两种常见配置位置全局的/etc/profile和目录级的/etc/profile.d/java.sh。我更推荐后者因为它按功能拆文件不会把 /etc/profile 改得乱七八糟。不过为了兼容旧习惯下面统一写到/etc/profile效果一样。export JAVA_HOME/usr/local/java/current export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar三行配置逐行解释JAVA_HOME告诉系统和应用 JDK 安装根目录在哪。Tomcat、Maven、Gradle、Jenkins 都会读取这个变量。PATH$JAVA_HOME/bin:$PATH把 JDK 的 bin 目录加到系统命令搜索路径的最前面并且是放在原来的 $PATH 之前确保执行java、javac时优先命中新装的 JDK。CLASSPATHJava 类搜索路径。老项目经常需要依赖dt.jar和tools.jar虽然 Java 9 开始模块化后不再需要手动设置但 JDK 8 场景下保留这一行可以避免很多奇怪问题。开头的.表示当前目录非常重要否则java HelloWorld可能找不到同一个目录下的 class 文件。写完之后让配置生效source /etc/profile然后验证echo $JAVA_HOME这里必须多说一句source只对当前 shell 会话生效。你新开一个终端窗口或者用 Xshell 重新连接一次还是要再读一次 profile。所以安装完成后最好直接退出重新登录让整个用户会话都带上新变量。3.3 环境变量不生效的高频原因我在群里看到太多人问“我明明配了 JAVA_HOME为什么 java -version 还是旧版本”问题的根源绝大多数是下面这几类第一大小写错误或目录写错。JAVA_HOME/usr/local/java/current里的 current 是一个软链接如果软链接没建好或者把current写成了Current那 echo 出来的路径就是空的。第二PATH 顺序不对。如果你把$PATH放在了$JAVA_HOME/bin前面比如写成export PATH$PATH:$JAVA_HOME/bin系统还是会先找到/usr/bin/java也就是旧版本。这属于低级错误但出现频率极高。第三应用层不加载 /etc/profile。这是最坑的一种。Tomcat 通过 systemd 启动时systemd 环境里没有/etc/profile的变量Tomcat 自然拿不到 JAVA_HOME。crontab 里执行任务也一样它不会读取你的交互式 shell 配置。后面我会单独讲生产环境怎么给这类场景设置变量。4. 安装验证和生产环境中的问题排查配置完成不代表真的能用了。我习惯用一套固定命令验证 JDK 安装是否完整也建议大家养成这个习惯。毕竟java -version能出来不代表 javac 就能出来更不代表应用能正常跑。4.1 一套验证命令证明 JDK 真的能用配置完环境变量后依次执行java -version javac -version jps -l echo $JAVA_HOME which java正常情况下java -version第一行会显示java version 1.8.0_211 Java(TM) SE Runtime Environment (build 1.8.0_211-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)javac -version会显示javac 1.8.0_211jps -l会列出当前正在运行的 Java 进程哪怕只有一个 JVM 进程也能证明 JVM 启动正常。which java应该指向/usr/local/java/current/bin/java而不是/usr/bin/java。如果java -version正常但javac -version报 command not found说明你装的是 JRE 而不是 JDK或者 bin 目录里真的没有 javac。这种包不值得再折腾直接换官方 tar.gz。jps这个东西是很多人忽略的但排查线上问题时非常好用装了 JDK 却没有它基本可以判断包不完整。4.2 高频报错与完整排查链路配置阶段最让人头疼的是各种报错。我按实际出现频率整理了一张排查表每一类我都在服务器上真实遇到过。报错现象可能原因排查处理bash: java: command not foundPATH 没生效或 bin 目录不对先执行/usr/local/java/current/bin/java -version如果正常说明环境变量配置有问题找不到或无法加载主类 HelloWorldCLASSPATH 没包含当前目录或 class 文件不在此目录检查 CLASSPATH 开头是否有.或直接java -cp . HelloWorldjavac: command not found装的是 JRE 而不是 JDK查看解压目录里有没有 javac没有就得换完整 JDKError: Could not create the Java Virtual Machine启动参数里有 JVM 不认识的选项如 -d64检查脚本里的 JVM 参数删除多余参数UnsupportedClassVersionError编译用的 JDK 版本比运行用的 JDK 高class 文件主版本号和当前 JVM 不匹配需要切换 JDK 或重新编译Permission denied目录或文件没有执行权限chmod -R 755 /usr/local/java/jdk1.8.0_211举一个真实场景有人写了 HelloWorld.javajavac 编译成功但java HelloWorld报“找不到或无法加载主类”。他第一反应是 JDK 装坏了重装了三次还是一样。实际上只是因为他把/usr/local/java/current/lib/dt.jar前面的.漏了类加载器根本没把当前目录加入搜索路径。所以配置 CLASSPATH 时千万别省.否则就是给自己埋雷。4.3 Tomcat、systemd、crontab 里找不到 Java 的坑这个问题非常典型你在终端里配好环境变量Tomcat 手动启动也正常但注册成系统服务后怎么都起不来要么报“Cannot find /usr/bin/java”要么报 JAVA_HOME 没有设置。原因是 systemd 服务不会加载/etc/profile它只有自己的一套环境。解决办法是直接在服务配置里写明 JAVA_HOME。编辑 Tomcat 的 service 文件[Service] EnvironmentJAVA_HOME/usr/local/java/current或者在 Tomcat 的 bin/setenv.sh 里显式设置export JAVA_HOME/usr/local/java/current export CATALINA_HOME/opt/apache-tomcat-8.5.xxcrontab 也一样。你可以在 crontab 里写10 * * * * /opt/scripts/backup.sh但这个脚本读不到 /etc/profile 里配置的 JAVA_HOME脚本一执行就报 command not found。所以凡是在 cron 里跑的需要 Java 的脚本第一行就要写上export JAVA_HOME/usr/local/java/current export PATH$JAVA_HOME/bin:$PATH不要嫌重复这是最稳定的做法。4.4 与 JDK 17 共存和切换的思路现在新项目越来越多的在用 JDK 17但老项目还不能立刻迁移所以服务器上同时装两个 JDK 是非常正常的场景。JDK 8 和 JDK 17 可以共存前提是各自目录独立、环境变量统一通过软链接管理。我习惯在/usr/local/java下同时保留/usr/local/java/jdk1.8.0_211 /usr/local/java/jdk-17.0.12 /usr/local/java/current - jdk-17.0.12当前项目需要 JDK 17 时软链接指向 jdk-17需要切回 JDK 8 时执行ln -sfn /usr/local/java/jdk1.8.0_211 /usr/local/java/current注意-n参数它会在 current 本身是软链接时先移除它再重建避免出现current/current这种嵌套路径。切换之后重新登录或者 source 一下 profilejava -version就变了。日常使用中唯一需要留意的是如果手上有用 JDK 17 编译好的 .class 文件切到 JDK 8 运行时会报 UnsupportedClassVersionError这是因为 class 文件主版本号 61 超过了 JDK 8 支持的 52。反过来没问题JDK 8 编译的旧 class 基本都能在 JDK 17 上运行但部分依赖反射或者模块限制的老代码可能会出问题。我个人的经验是生产环境能不混用就不混用同一个服务固定用一个 JDK 版本避免“本地能跑、服务器跑不了”这种经典问题。如果实在要共存务必用软链接 显式导出环境的组合不要在多个地方反复写死绝对路径。最后再分享一个小技巧安装完 JDK 后把这套配置命令整理成一个脚本放到你的个人服务器工具箱里新机器上线时直接改版本号跑一遍比手动敲命令省心得多也不容易漏掉软链接或者环境变量。本文还有配套的精品资源点击获取