JDK 11.0.15 Linux 安装配置完整指南：从下载到环境变量

简介Linux x86_64平台的JDK 11.0.15二进制安装包供需要在Linux系统上编译、运行或调试Java应用的开发者使用也是搭建服务器端Java运行时的基础物料。压缩包采用tar.gz格式共392个文件大小约161MB文件类型涵盖71个jmod模块、38个so动态库、36个Markdown说明文档、70组license/copyright许可声明以及properties配置、policy策略、jar工具包等完整保留JDK标准目录与工具链。目前已有803人学习下载。解压并配置JAVA_HOME与PATH后可直接获取javac、java、javadoc、jlink等核心命令既能用于日常编码调试也能借助jlink构建定制化精简运行时并配合自带文档理解Java 11的var局部变量推断、模块化系统等新特性。 最近刚给一台全新服务器配环境装的就是标题里这个jdk-11.0.15_linux-x64_bin.tar.gz。群里好几个朋友问我新版本 JDK 在 Linux 下怎么装、配置时总提示找不到 java 怎么办。我想干脆把整个流程从下载、解压、配置到验证完整写一遍重点讲讲那些最容易翻车的地方。这篇文章适合刚接触 Linux 的开发者也适合需要给多台服务器批量部署 JDK 的运维同学跟着操作就能装出一个干净、可回滚的 Java 环境。1. 先搞懂版本号与适用场景JDK 11.0.15 到底新在哪1.1 从 11.0.15 这个版本号能读出什么很多新手看到jdk-11.0.15_linux-x64_bin.tar.gz这串名字第一反应是这不就是一个安装包嘛。其实这个文件名已经把版本策略、操作系统架构、打包方式全告诉你了。11.0.15是 Java 11 系列下的第 15 个安全更新版本数字越靠后说明累积的安全补丁和 bug 修复越多。生产环境里我从来不推荐追求最新大版本而应该选一个已经经过多轮维护的稳定小版本11.0.15 就属于这种状态既不是刚发布的冒头版本也不是已经停止公开更新的老版本处在安全性和稳定性最平衡的位置。linux-x64表示这是给 64 位 Linux 系统准备的编译产物。现在绝大多数云服务器和物理机都是 x86_64 架构如果你拿的是 ARM 服务器比如华为鲲鹏或者 AWS Graviton这个包就装不了得去找linux-aarch64的对应版本。bin表示它是二进制发布包解压即可使用不需要额外编译。tar.gz是打包压缩格式在 Linux 下用一条tar命令就能解开这也是我下面要详细说的。1.2 选 JDK 11 而不是 8 或 17 的考量每次聊 JDK 版本总有人纠结到底是装 8、11 还是 17。我的判断标准很简单看项目实际运行环境。如果你手上的 Spring Boot 应用还在用 javax 命名空间或者依赖的老库没有升级到 jakartaJDK 8 可能更合适如果你的微服务体系已经全面容器化并且用上了 GraalVM 或者虚拟线程这些新特性那直接上 17 甚至 21 都没问题。JDK 11 处在中间位置它是 Oracle 官方宣布的长期支持版本而且从 11 开始Java 引入了很多现代化特性比如局部变量类型推断、HttpClient 正式转正、ZGC 垃圾收集器初步可用。我这次选择 11.0.15还有一个实际原因是团队现有项目的编译目标就是 Java 11。用高版本 JDK 编译出来的 class 文件如果字节码版本超过 55低版本运行时直接报UnsupportedClassVersionError。反过来用低版本编译高版本跑又会遇到各种 API 缺失的问题。所以生产环境里最保险的做法是让编译 JDK 和运行 JDK 保持同一大版本小版本尽量往新了走。11.0.15 在 11 系列里属于较新的维护版本正好满足这个需求。2. 下载与校验官网入口、tar.gz 与 rpm/deb 怎么选2.1 认准下载入口与文件名JDK 的下载渠道其实有讲究。Oracle 官方把 JDK 分成两种一种是 Oracle JDK需要登录 Oracle 账号才能下载商用要遵守 Oracle 的许可协议另一种是 OpenJDK开源免费可以直接从官网或者镜像站拿。对于大多数开发测试场景OpenJDK 和 Oracle JDK 在运行普通 Java 程序时几乎没有区别但如果你要用到 Java Flight Recorder、Java Mission Control 这些商业特性或者需要 Oracle 的原厂技术支持就得老老实实走 Oracle 官方渠道。下载的时候文件名一定要看仔细。jdk-11.0.15_linux-x64_bin.tar.gz对应的就是 Linux x64 平台的压缩包。Oracle 官方下载页面里同一版本通常提供 rpm、deb、tar.gz 三种格式分别对应不同的安装方式。常见的一个坑是手滑下载了linux-aarch64的包在 x86 机器上解压后java -version会直接报Exec format error这个问题我后面排查章节会专门讲。2.2 为什么我推荐 tar.gz 而不是包管理器如果你用的是 CentOS、Ubuntu 这类发行版系统自带的 yum 或者 apt 也能装 OpenJDK一条命令搞定省去手动解压配置的麻烦。但我不建议在需要精确控制版本的环境里这样做。原因有三点第一软件源里的 JDK 版本往往滞后。yum install java-11-openjdk装出来的可能是 11.0.18 之前的某个旧维护版本小版本落后会错过安全补丁。第二包管理器安装的 JDK 路径分散/usr/lib/jvm下的目录命名每个发行版还不一样给脚本自动化部署带来麻烦。第三rpm 和 deb 安装包会把 JDK 的文件散落到系统多个目录卸载时容易留残留想回滚到之前的 JDK 版本非常困难。tar.gz 包的好处是一个目录即一个版本。你解压到哪个目录JDK 就在哪个目录删掉目录就等于卸载完毕切换版本只需要改环境变量指向。对于运维人员来说这种文件即服务的管理方式最直观也最容易集成到 Ansible、Shell 脚本里去。所以我个人在所有 Linux 服务器上部署 JDK 时都坚定选择 tar.gz。2.3 下载后的 checksum 校验下载完成不等于文件可靠。网络传输过程中可能发生文件损坏或者更严重的情况是下载到了被篡改的安装包。Oracle 官网每个版本都会提供对应的 SHA256 校验值下载页面里能找到jdk-11.0.15_linux-x64_bin.tar.gz.sha256文件。拿到安装包后在 Terminal 里执行sha256sum jdk-11.0.15_linux-x64_bin.tar.gz把输出的一长串十六进制字符和官网公示的校验值对比完全一致才说明文件完整。这步虽然多花 10 秒钟但能避免后面排查一堆莫名其妙的编译错误。我见过有人跳过校验解压后 javac 一直报invalid flag最后发现是压缩包在传输中损坏白折腾了一个下午。3. 解压安装目录规划、权限设置与全局 java 命令3.1 目录规划别随手解压到 home很多新手习惯把 JDK 解压到~/jdk-11.0.15自己电脑上这么干没问题但服务器上不建议。生产环境一般遵循 FHS文件系统层次标准第三方软件统一放在/opt或者/usr/local下。我习惯的布局是这样的/opt/java/ ├── jdk-11.0.15 # 实际解压出来的目录 └── current - jdk-11.0.15 # 软链接指向当前使用的版本为什么加一层current软链接因为升级 JDK 时只需要把新版本解压到/opt/java然后把软链接从旧版本指向新版本再修改一下环境变量或者重新执行一次alternatives配置即可所有依赖/opt/java/current的脚本都不用改。这对微服务部署尤其重要因为你不可能每次升级 JDK 都去改所有服务的启动脚本。3.2 解压与软链让版本升级更省心具体操作分几步。先把安装包放到服务器上推荐用scp或wget直接传到目标目录然后执行解压mkdir -p /opt/java tar -zxvf jdk-11.0.15_linux-x64_bin.tar.gz -C /opt/java cd /opt/java ln -sfn jdk-11.0.15 current解压完成后目录结构已经是可运行的。-C参数指定了解压目标目录如果省略JDK 会散落在当前目录下后面管理会很难受。创建软链接时我用的是ln -sfn-f表示如果current已存在则强制覆盖-n是防止软链接指向目录时出现多层链接问题。这样即使你反复安装多个 JDK 版本/opt/java/current永远指向你想要的那个。3.3 设置可执行权限与验证解压结果tar.gz 解压出来的文件权限一般是正确的但在某些传输场景下可执行位可能丢失。保险起见执行下面命令chmod -R ux /opt/java/jdk-11.0.15/bin这里我刻意没有用chmod -R 755全目录授权因为 JDK 的lib目录下有大量模块文件有些只需要读权限全部改成 755 虽然问题不大但不是最小权限原则。只给bin目录加执行权限就够了。接着验证解压结果ls -l /opt/java/current /opt/java/current/bin/java -version如果能看到openjdk version 11.0.15之类的输出说明解压没问题。如果提示No such file or directory大概率是文件类型不匹配或者架构选错了。4. JAVA_HOME 与 PATH 配置最容易被卡住的环节4.1 全局配置还是当前用户配置解压之后系统还不知道去哪儿找java命令需要我们手动配置环境变量。这里有两个层级全局配置所有用户生效和用户配置当前用户生效。如果这台机器是专用开发机或者测试服务器直接改全局配置如果是多人共用的机器最好只改自己的~/.bashrc免得影响别人已有的环境。全局配置一般有以下几种可选方案配置文件说明/etc/profile登录时加载影响所有用户适合集中管理/etc/profile.d/java.sh更推荐的写法模块化配置系统升级不会覆盖/etc/environment系统级环境变量但不建议放 PATH 依赖~/.bashrc当前用户每次打开终端时加载我倾向于在/etc/profile.d/下新建一个java.sh文件而不是直接改/etc/profile。这样配置独立成文件后续要调整只改一个地方而且系统发行版升级时不会和系统自带配置产生冲突。4.2 修改配置文件的正确姿势创建/etc/profile.d/java.sh内容如下export JAVA_HOME/opt/java/current export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar保存后执行source /etc/profile.d/java.sh java -version如果你用的是/etc/profile改完也要执行source /etc/profile。这里提醒一下CLASSPATH在 Java 9 之后其实不太需要手动设置了因为模块化之后dt.jar和tools.jar已经不存在于lib目录写了反而可能引起奇怪的问题。我更推荐只设置JAVA_HOME和PATHCLASSPATH用默认值就好。如果你确实需要设置把需要引入的 jar 包路径写进去即可格式依然是冒号分隔。4.3 为什么 source 之后还是找不到 java常见翻车点接下来说重点也是我看到的私信问题里出现频率最高的明明已经导出了JAVA_HOME也source了配置文件但执行java -version还是报command not found。这里的原因通常有几种。第一种配置文件里的变量引用了错误的路径。有人把JAVA_HOME写成了/opt/java/jdk-11.0.15/末尾多了一个斜杠这在大部分情况下没问题但如果后续脚本做字符串拼接时没注意就会出现双斜杠的路径可能导致某些脚本判断异常。建议统一不带末尾斜杠。第二种PATH覆盖顺序问题。如果服务器之前装过 OpenJDK/usr/bin/java已经存在而你新配置的路径在PATH中的位置靠后系统会优先执行旧的java。解决办法是确保$JAVA_HOME/bin在PATH最前面export PATH$JAVA_HOME/bin:$PATH就是这个意思。第三种也是最隐蔽的你source了但当前 Shell 环境里还有缓存。执行hash -r清空命令哈希表或者干脆重新登录一次终端。我排查过的案例里超过一半是这种原因不是配置错了而是 Shell 缓存了旧路径。第四种/etc/profile.d/java.sh没有执行权限。某些系统对/etc/profile.d下的脚本有权限要求如果文件不可读登录时就不会自动加载。检查一下文件权限确保是644。5. 安装后的验证与清理从 java -version 到编译运行5.1 第一步命令版本验证配置完环境变量第一步永远是用java -version验证。如果你看到类似下面的输出openjdk version 11.0.15 2022-04-19 OpenJDK Runtime Environment (build 11.0.1510-36) OpenJDK 64-Bit Server VM (build 11.0.1510-36, mixed mode, sharing)说明安装成功了一半。注意这里有个容易忽略的细节如果输出里带Oracle JDK字样而你装的是 OpenJDK别慌两个发行版命令行的输出格式略有差异关键看版本号和构建号是否对得上。接着执行which java readlink -f $(which java)which java会显示当前java命令的实际路径readlink -f会告诉你在软链接场景下最终指向的真实文件路径。正常情况下应该指向/opt/java/jdk-11.0.15/bin/java。如果这里显示的是/usr/bin/java说明你的PATH配置被系统自带的 Java 抢占了回到上一节的第二种情况排查。5.2 第二步javac 与编译 HelloWorld光有java命令还不够很多开发环境还需要javac编译器。写一个最简单的测试文件验证编译链路mkdir -p /tmp/java-test cd /tmp/java-test cat Hello.java EOF public class Hello { public static void main(String[] args) { System.out.println(JDK 11.0.15 works!); } } EOF javac Hello.java java Hello如果输出JDK 11.0.15 works!说明JAVA_HOME、PATH、CLASSPATH三件套全部正常JDK 可以投入使用了。我见过一些能运行但编译不了的情况多半是只配了JRE路径或者解压的是 JRE 包而不是 JDK 包这种在javac阶段就会暴露出来。所以安装完一定别只验证java -version要把javac和实际编译运行都测一遍。5.3 第三步检查残留 JDK 版本与卸载思路一个很容易被忽略的问题是系统里可能已经装过其他版本的 JDK你配置的新环境变量并没有把它干掉只是让它暂时靠后了。最稳妥的做法是检查一下全局有哪些 Java 相关文件which -a java find /usr -name java -type f 2/dev/null如果发现有多个java建议用alternatives统一管理。CentOS/RHEL 系列可以用alternatives --install /usr/bin/java java /opt/java/current/bin/java 1 alternatives --config javaUbuntu/Debian 系列则用update-alternatives命令格式类似。这个工具的价值在于它会维护一个系统级的命令符号链接你只需要执行一次alternatives --config就能在已安装的多个 JDK 版本之间随时切换不需要反复修改环境变量。对于生产环境我强烈推荐这个方案因为它把多版本共存变成了一个可操作的标准化动作。如果确定不需要旧版本了删除方式就是移除对应目录再清理它可能写入/etc/profile.d/或~/.bashrc的环境变量行。tar.gz 安装方式的卸载就是这么干净这也是我坚持不用 rpm 的原因之一。5.4 补充其他发行版的小差异不同 Linux 发行版的细节差异值得提一下。CentOS 8 默认没有安装alternatives时需要先yum install java-11-openjdk-headless之类的包来引入 alternatives 框架吗不一定直接安装chkconfig或者alternatives包即可。Ubuntu 上则要注意/etc/profile.d/java.sh可能在系统升级时被清理掉服务器重启后突然发现 java 找不到先检查这个文件还在不在。还有一个与标题直接相关的注意点jdk-11.0.15_linux-x64_bin.tar.gz解压后的目录名是jdk-11.0.15但不同小版本解压后的目录名格式可能略有不同比如早期 11.0.14 解压出来是jdk-11.0.14而带建号的版本目录里会有类似jdk-11.0.1510的格式。解压后第一时间ls /opt/java看一眼实际目录名再创建软链接别想当然用固定目录名做链接。最后分享一个自动化部署的小技巧把下载、校验、解压、配置、验证这几个步骤写成一个 shell 脚本配合 Ansible 的模板功能三十台服务器几分钟就能全部搞定。脚本里多用变量控制版本号和安装路径下次升级一个参数就够了。这套流程我跑了三年从 JDK 8 到 11 再到 17每次都是改个版本号重跑一遍稳定可靠。本文还有配套的精品资源点击获取