简介一份适用于 Linux x86_64 系统的 JDK 11.0.15 二进制发行包面向搭建 Java 开发或运行环境的开发者与运维人员可脱离在线安装流程直接离线部署。该发行包含编译器、JVM、运行时及调试监控工具涵盖 javac、java、jshell、jlink、jconsole 等命令可支撑代码编译、运行、调试与定制化打包同时支持 Java 11 的模块化系统、局部变量类型推断等新特性便于开发与生产环境一致使用。压缩包共 392 个文件、约 161MB主要包含 .jmod 模块定义、.jar 类库归档、.so 动态链接库以及 .md 说明文档和 license/copyright 许可文件目录组织规范附带 man 手册便于查阅命令用法与参数。目前已有 804 人学习下载适合需要快速获取官方组件、离线部署或统一配置多台 Linux 机器的开发与运维场景。1. JDK 11.0.15 Linux x64 tar.gz为什么这个归档包还值得动手装当你在内网服务器上敲java -version却看到 1.8而项目代码里全是var和List.of的时候就知道该把 JDK 11 安排上了。jdk-11.0.15_linux-x64_bin.tar.gz是 Oracle JDK 的一个稳定归档版解压即用不碰系统包管理器特别适合在 CentOS 7、Ubuntu 20.04、银河麒麟这类 x64 的 Linux 环境上做受控安装。它解决的不只是有个 java 能用而是让 JAVA_HOME、启动脚本和后续切版本都掌握在自己手里。需要手动配 JDK 的运维、做嵌入式 Linux 交叉编译的工程师以及被 JMeter、DBeaver 这些工具绑架了版本的开发都值得照着下面的步骤走一遍。2. 下载与解压把 jdk-11.0.15_linux-x64_bin.tar.gz 装到 /usr/local/jdk2.1 tar.gz 和 rpm 的区别以及为什么选择二进制包Linux 下装 JDK 常见的三种方式apt install openjdk-11-jdk、.rpm包、tar.gz二进制包。前两种由发行版维护版本往往滞后而且 OpenJDK 和 Oracle JDK 的目录结构、许可证都不一样。tar.gz解压出来的是一整套自包含的jdk-11.0.15文件夹不依赖特定发行版卸载就是删目录回滚就是改软链接这是它最大的价值。这里提到的jdk-11.0.15_linux-x64_bin.tar.gz是 Oracle 官方针对 Linux x64 提供的二进制包文件名里的linux-x64表示需要 64 位 Linux 内核和对应 glibc不是 arm64也不是 32 位。我一般会建议把解压后的目录统一放到/usr/local/jdk/下再做一个不带版本号的软链接/usr/local/jdk/current这样环境变量永远指向current升级 JDK 时只需要解压新包并切换软链接所有配置文件不用动。这个习惯在管理多版本时能省下大量改/etc/profile的时间。2.2 下载、解压、移动的完整命令在 Oracle 官网下载jdk-11.0.15_linux-x64_bin.tar.gz后通常先上传到/opt或用户目录。以下命令以/usr/local/jdk为安装根目录包含解压、移动和软链接三步# 1. 创建目标目录并解压 sudo mkdir -p /usr/local/jdk sudo tar -xzf jdk-11.0.15_linux-x64_bin.tar.gz -C /usr/local/jdk # 2. 解压后确认目录名一般是 jdk-11.0.15 ls -la /usr/local/jdk/ # 3. 建一个不带版本号的软链接方便后续切换 sudo ln -s /usr/local/jdk/jdk-11.0.15 /usr/local/jdk/current # 4. 确认软链接目录下的 bin/java 可执行 /usr/local/jdk/current/bin/java -version第 1 步里的-C指定解压目标目录tar -xzf中的z表示通过 gzip 解压f指定文件。第 3 步的软链接是这套方案的核心环境变量只依赖current这个名字以后换成 11.0.16 时只需要修改ln -sfn指向新目录不需要动/etc/profile。第 4 步直接调用current/bin/java是为了测试解压是否正确此时还没有配环境变量必须用绝对路径。如果你拿到的是其他架构的文件比如jdk-11.0.15_linux-aarch64_bin.tar.gz那linux-x64的位置会变成aarch64命令本身不变但要注意服务器的uname -m是否匹配。可以用uname -m先查看机器架构x86_64 对应linux-x64。2.3 验证文件包是否损坏校验和与解压检查网络下载容易断很多解压后 java 跑不起来的问题其实包就坏了。Oracle 官网每个文件旁边会给出 SHA-256 校验和先算后比# 计算下载文件的校验和 sha256sum jdk-11.0.15_linux-x64_bin.tar.gz # 输出示例069cf0ccb0b1c8e11a2cffd0bee84e4aee8a2d23e4775e6efe0e1b3a6c2c0e00 # 与官网显示的校验和字符串对比不一致就需要重新下载校验和一致后再解压。解压后少看一眼目录结构和bin/java的符号链接也可能踩坑。注意jdk-11.0.15目录下应该有bin/、lib/、conf/等一级目录如果解压出一个jdk-11.0.15后再套一层同名目录说明你解压到了同名文件夹里后续配置 JAVA_HOME 时指向错了层级。我常用find /usr/local/jdk -maxdepth 2 -name java -type f来做最终确认。3. 配置 JAVA_HOME 与 PATH让 jdk 环境变量配置一次生效3.1 全局配置 vs 用户配置环境变量文件怎么选java -version找不到新装的 JDK几乎都是因为PATH和JAVA_HOME没有配到正确的位置。Linux 环境变量文件有多个/etc/profile对所有用户生效/etc/profile.d/*.sh是系统级片段~/.bashrc只对当前用户登录 shell 生效。如果服务是通过 systemd 启动的还要考虑 systemd 不读 shell 环境变量那属于另一个问题。对于服务器我建议把配置写到/etc/profile.d/jdk11.sh而不是直接改/etc/profile。这样既不影响根目录下的其他逻辑卸载时删除一个文件即可。对于开发机只想给自己用的~/.bashrc就够了。但注意~/.profile和~/.bashrc的加载时机不同登录 shell 读.profile非登录交互 shell 读.bashrc。桌面 Linux 的终端通常是非登录 shell所以写.bashrc更容易生效。3.2 编辑 /etc/profile 和 ~/.bashrc 的写法创建一个独立环境变量文件内容是标准的JAVA_HOME加PATH组合sudo tee /etc/profile.d/jdk11.sh EOF export JAVA_HOME/usr/local/jdk/current export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib EOF之后重新加载环境变量source /etc/profile.d/jdk11.sh$JAVA_HOME/bin放到$PATH前面是为了让 shell 优先找到新版java避免系统自带的旧版 OpenJDK 抢先。CLASSPATH在 JDK 9 之后不再是必须但有些老项目启动脚本仍然依赖它保留.和lib目录不会出问题。source只对当前终端生效重新登录系统后才会自动加载。如果你改的是~/.bashrc记得source ~/.bashrc。很多 jdk 环境变量配置失败根源在于JAVA_HOME指向了错误路径。比如你把JAVA_HOME写成了/usr/local/jdk/current/bin然后PATH里拼的是$JAVA_HOME/bin/java结果就成了/usr/local/jdk/current/bin/bin/java必然找不到。配置完成后不要急着关终端先 echo 验证echo $JAVA_HOME echo $PATH which javawhich java应该输出/usr/local/jdk/current/bin/java如果输出/usr/bin/java说明/etc/profile.d/jdk11.sh没有在 PATH 中生效或者有权限导致文件没被读取。检查文件所有者与权限ls -l /etc/profile.d/jdk11.sh确认普通用户可读。3.3 多 JDK 切换alternatives 与手动软链接一台机器上同时存在 JDK 8、JDK 11、JDK 17 很常见尤其当 JMeter 要求 JDK 8而主项目要求 JDK 11 的时候。用update-alternatives是 Debian/Ubuntu 的经典管理方式但 CentOS 下的语法略有不同而且如果不小心把系统级别的javaalternatives 指向了临时版本可能会影响其他服务。我更推荐用软链接做受控切换因为它只影响你定义的那条路径。假设你解压了多个版本sudo ln -sfn /usr/local/jdk/jdk-8u202 /usr/local/jdk/current sudo ln -sfn /usr/local/jdk/jdk-11.0.15 /usr/local/jdk/current第二个命令执行后current会迅速指向 11.0.15所有用$JAVA_HOME的脚本立即生效无需重新打开 shell。如果要切到 17只需再把ln -sfn指向 jdk-17 的目录。-f强制覆盖已经存在的软链接-n防止对目录做奇怪的递归处理。但注意update-alternatives管理的是/usr/bin/java这个公共入口而我们的$JAVA_HOME是私有入口。系统服务如果用默认java命令它看的是/usr/bin/java的链接所以你要么用alternatives --config java修改公共入口要么把服务的启动脚本改成显式使用$JAVA_HOME/bin/java。常见做法是后者因为服务对 JDK 版本的要求往往和交互式 shell 不同。4. 避坑JDK 11.0.15 在 Linux x64 上的 5 个高频故障4.1 现象java -version 还是旧版本jdk 环境变量配置不生效修改/etc/profile.d/jdk11.sh后重新登录了终端which java还是/usr/bin/java。原因往往是 PATH 的赋值顺序有问题或者 profile.d 里还有另一个 JDK 路径被后加载。检查全部可能改动的文件grep -R JAVA_HOME\|export PATH /etc/profile /etc/profile.d/ ~/.bashrc 2/dev/null解决方式是确保JAVA_HOME只出现一次且export PATH$JAVA_HOME/bin:$PATH写在所有系统路径之后。如果多个文件里都有export PATH...后执行的会用旧值覆盖新值。把配置统一放到/etc/profile.d/jdk11.sh删除其他地方的重复配置。4.2 现象source 后提示 bash: java: command not found这类问题常见于java命令在bin/下不存在或者JAVA_HOME配置错误。先直接执行ls $JAVA_HOME/bin/java如果显示目录不存在说明软链接断了。我见过很多次解压后忘了把旧版本目录改名jdk-11.0.15实际是空文件夹软链接指向的路径是死链。用ls -l /usr/local/jdk/current查看链接指向file /usr/local/jdk/current/bin/java查看文件类型。另一种可能是你在~/.bashrc里写了export JAVA_HOME~/jdk而当前用户对/usr/local/jdk没有执行权限。执行chmod -R ox /usr/local/jdk或把 JDK 装到~/下即可。4.3 现象IDEA、DBeaver、JMeter 找不到 JDK 或版本不对工具启动时使用的 JDK 不一定是PATH里的那个。IDEA 2025 设置里可以在Project Structure中手动添加 JDK直接选择/usr/local/jdk/current目录即可。DBeaver 修改 jdk 版本需要改dbeaver.ini里的-vm参数指定到$JAVA_HOME/bin/java。JMeter 则看setenv.sh中的JMETER_HOME和JAVA_HOME如果强制指定了旧路径就会忽略系统变量。我在一台测试机上装完 JDK 11运行 JMeter 仍然报 Java 1.8最后发现是jmeter脚本里写死了JAVA_HOME/usr/lib/jvm/java-1.8.0。解决办法是打开jmeter/bin/jmeter搜索JAVA_HOME注释掉写死的赋值让它自动读取环境变量。4.4 现象解压后运行 java 报 No such file or directory这不是文件不存在而是动态链接器缺失。java是一个 ELF 可执行文件它依赖系统的 glibc 版本。老旧的 CentOS 6 或某些精简的嵌入式 linux 镜像glibc 低于 JDK 11 的要求就会在启动时提示找不到某个.so.6。先ldd /usr/local/jdk/current/bin/java查看输出中是否有not found。如果是 glibc 问题要么升级系统基础库要么选择为旧 glibc 编译的 JDK 发行版。对于大多数现代发行版比如 CentOS 7 以上、Ubuntu 18.04 以上直接使用linux-x64包没问题。遇到干净的 docker 镜像时记得apt install libc6或yum install glibc补基础依赖。4.5 现象java 命令能运行但 javac 编译编码报错JDK 11 默认使用 UTF-8但系统区域非 UTF-8 时编译带中文注释的代码会报编码错误 GBK 或 ANSI。排查时运行java -XshowSettings:properties -version查看file.encoding。解决方案是在项目编译脚本里显式增加-encoding UTF-8或者设置环境变量JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8。这个坑在新老系统交替时特别常见别把锅甩给jdk-11.0.15本身。5. 验证与落地把 JDK 11 用进真实项目5.1 写一个 Java 程序或跑一个 jar 验证安装完整环境变量配好之后不要只看java -version。写一个小程序验证编译、运行、类路径三个层面cat /tmp/HelloJdk11.java EOF public class HelloJdk11 { public static void main(String[] args) { var list java.util.List.of(JDK, 11.0.15); System.out.println(Hello String.join( , list)); } } EOF # 编译并运行 $JAVA_HOME/bin/javac /tmp/HelloJdk11.java $JAVA_HOME/bin/java -cp /tmp HelloJdk11输出Hello JDK 11.0.15。注意var和List.of都是 JDK 10 以后才有的语法如果这一步能过说明javac确实是 11.0.15。如果用系统老版本javac编译会直接报错。真正跑项目时我习惯把编译输出到/tmp避免污染用户目录。也可以直接对现有 jar 做冒烟验证java -jar /path/app.jar --version。5.2 设置 java 命令的用户级与 sudo 级配置有些场景需要非 root 用户也能使用新 JDK但/etc/profile.d/jdk11.sh在 root 下生效其他用户却报找不到 java。原因可能是文件对普通用户不可读或者普通用户的PATH在加载 profile.d 之前被截断。给其他用户单独配置时不必复制整个文件可以在该用户~/.bashrc里写if [ -f /etc/profile.d/jdk11.sh ]; then . /etc/profile.d/jdk11.sh fi这比逐条 export 干净。如果 sudo 后找不到 javasudo默认会重置PATH和JAVA_HOME。用sudo visudo打开配置把Defaults env_keep JAVA_HOME加进去使 sudo 会话保留当前用户环境变量。注意sudo执行 java 时还可能遇到安全策略限制此时检查/etc/sudoers中的secure_path。5.3 检查 JVM 参数与编译版本-source/-target 的边界JDK 11 编译出来的 class 文件放回 JDK 8 的运行时是跑不起来的因为 class 文件主版本号 55 高于 JVM 能识别的 52。项目里需要向下兼容时用-source 8 -target 8编译$JAVA_HOME/bin/javac -source 8 -target 8 /tmp/HelloJdk11.java但注意JDK 11 中-source 8会触发警告提示使用旧版语法。而且 JDK 11 里javac不再支持-source 7以下版本。如果项目必须跑在 JDK 8 上同时开发环境是 JDK 11你应该考虑在构建工具Maven/Gradle里指定--release 8它会同时限制 API 和字节码级别比-source/-target更可靠。这个细节经常在idea 配置 jdk 和 maven的实践里被问到。另外用java -XX:PrintFlagsFinal -version | grep -i HeapSize\|UseG1GC可以查看 JVM 默认堆和垃圾收集器。JDK 11 默认 G1GC如果你的应用是低延迟微服务这是加分项如果是单机大内存批处理你可能想调-Xms和-Xmx。生产参数不要直接改全局 JVM 配置文件而是在启动脚本里用JAVA_OPTS按实例传。6. 进阶把 JDK 11 的安装变成脚本和可回滚操作6.1 用一个 shell 脚本把下载、校验、解压、配置串起来手动安装适合一次性操作多台机器还要敲同样命令就很容易出错。我把安装动作封装成install-jdk11.sh输入 tar.gz 路径自动完成校验和解压并为后续回滚留下旧链接备份#!/usr/bin/env bash set -euo pipefail TARBALL${1:-jdk-11.0.15_linux-x64_bin.tar.gz} INSTALL_DIR/usr/local/jdk CURRENT$INSTALL_DIR/current sudo mkdir -p $INSTALL_DIR sudo tar -xzf $TARBALL -C $INSTALL_DIR JDK_DIR$(tar -tzf $TARBALL | head -1 | cut -d/ -f1) # 如果 current 已存在先备份旧链接指向的目录名 if [ -L $CURRENT ]; then OLD_TARGET$(readlink -f $CURRENT) sudo ln -sfn $OLD_TARGET $INSTALL_DIR/current.bak fi sudo ln -sfn $INSTALL_DIR/$JDK_DIR $CURRENT echo JDK installed at $CURRENT脚本里set -euo pipefail保证任一命令失败就退出不会出现解压失败但软链接已更换的中间状态。readlink -f $CURRENT拿到旧 JDK 真实路径存入current.bak软链接回滚就是再把current指向current.bak。这套方案比手动复制目录更省空间也更符合后悔药的运维思路。6.2 定时检查安全更新与替代 Oracle JDK 的注意点jdk-11.0.15是 2022 年的版本如果你面向公网提供服务至少要看 Oracle Critical Patch Updates 中 11.0.15 之后的告警。我的习惯是每季度检查一次java -version中的 update 数字并在测试环境装一个最新 11.0.x 包跑一遍项目测试用例再计划切换。不要迷信最新版这个标题11.0.15 在官方版本序列里早就不是最新但它稳定适合不想追新又需要 JDK 11 语法和 G1 的项目。如果所在环境要求完全开源可以改用 Eclipse Temurin 或 Adoptium 的jdk-11.0.x_linux-x64_bin.tar.gz文件名和安装方式几乎一样只是发行方不同。切换时注意${JAVA_HOME}/release文件里的IMPLEMENTOR字段某些授权扫描工具会读取它。保持软链接指向和JAVA_HOME不变替换整个目录即可不会破坏任何基于current路径的脚本。不要顺手把/usr/bin/java直接软链接到$JAVA_HOME/bin/java除非你确认没有其他脚本依赖系统 JDK。我踩过一次某次把/usr/bin/java指向 11.0.15 后系统里一个依赖 JDK 8 的 Netty 老服务直接启动失败查了半天才发现是 alternatives 被覆盖。从那以后我只在项目启动脚本里使用$JAVA_HOME/bin/java系统的默认命令保持不动。少改一点麻烦少一点。希望这份安装与避坑笔记帮你在 JDK 路上少花一个下午。本文还有配套的精品资源点击获取