企业官网建设流程全解析

简介：一份适用于 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/jdk

2.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 java

which 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 o+x /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.encoding=UTF-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 后找不到 java，sudo默认会重置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 路上少花一个下午。

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