Linux手动安装OpenJDK：从环境变量到多版本管理

我这几年的工作里有大量时间都在跟 Linux 服务器打交道。不管是给客户部署业务系统、在公司内部搭测试环境还是自己研究新框架几乎每到一个新环境都要先解决 JDK 的问题。很多人觉得装个 Java 环境有什么好讲的直接 apt install 或者 yum install 不就行了但实际工作中你一定会遇到需要手动安装 OpenJDK 的场景系统自带的软件源版本太旧、客户指定的 JDK 版本源里根本没有、服务器没外网不能走包管理器、或者你需要在同一台机器上共存多个 JDK 版本做演示和测试。这时候老老实实手动下载、解压、配环境变量反而是最稳妥、最可控的一条路。这篇文章我不讲那些花里胡哨的自动化脚本就专心把 Linux 手动安装 OpenJDK 这件事从头到尾掰开揉碎。从为什么需要手动装、装之前要确认哪些信息到真正的下载解压、环境变量配置、验证排错再到多版本共存的管理技巧全部用我实际踩过的坑和验证过的命令来讲。无论你用的是 CentOS 7、Ubuntu 22.04、Debian还是 Kylin、统信这类国产 Linux只要底层是 Linux 内核这套手动安装的思路和方法就都适用。1. 先搞清楚为什么非得手动装 OpenJDK1.1 包管理器安装和手动安装的差别包管理器确实香。在 Ubuntu/Debian 上一条apt install openjdk-17-jdk在 CentOS/RHEL 上一条yum install java-17-openjdk-devel装完java -version就能看到输出全程不超过两分钟不用理解任何底层原理。但方便的背后藏着几个实际工作中很要命的问题。第一个问题是版本滞后。apt 和 yum 软件源里的 OpenJDK 版本往往比官方发布的版本慢好几个小版本有些发行版甚至会一直停留在某个 LTS 版本上不更新。比如 CentOS 7 默认源里的 OpenJDK 最高就到 1.8 和 11想装 17 就非常费劲。第二个问题是定制性差。包管理器是按照发行版维护者的意图打包的有些版本的 JDK 会自带一些额外的配置文件或者限制你没法完全掌控安装路径和各组件。第三个问题也是我最常遇到的就是多版本共存。用 apt 或 yum 同时装 OpenJDK 8 和 OpenJDK 17切换起来比较绕虽然可以通过 alternatives 机制管理但很多人并不熟悉这套配置。相比之下手动安装就是纯解压一个 tar.gz放在哪个目录、用哪个版本、怎么切换全部由自己说了算。为了让大家更直观地感受区别我整理了一个对比表格对比项包管理器安装手动安装安装速度快取决于源速度中取决于下载速度版本灵活性依赖软件源维护节奏完全自由选择多版本共存支持但配置复杂天然适合切换依赖环境变量对系统的侵入性修改系统级配置不影响系统其他组件离线环境支持需要本地源或离线包一个 tar.gz 就能搞定卸载方式命令卸载即可删目录、删配置适合场景快速环境、不折腾生产服务器、定制化要求高1.2 什么时候你大概率需要手动装根据我这几年在项目里摸爬滚打的经验下面这几种场景你迟早会遇到到时候就明白手动安装 OpenJDK 有多重要了。第一种是客户内网服务器。很多政企客户的生产环境是隔离网不能访问外网但是机器上有安装好的 Linux 系统。这时候你没法执行 apt install 或者 yum install唯一可行的办法就是把 OpenJDK 的 tar 包拷到内网然后手动解压配置。第二种是指定版本部署。现在很多新的 Java 项目要求跑在 JDK 17 甚至 21 上但你的服务器操作系统是 CentOS 7 或者 Ubuntu 18.04软件源里根本没有这么新的 JDK。这时候手动下载官方编译好的版本是最直接、最不会引入额外问题的方案。第三种是无 root 权限的服务器。我在一些共享的开发机上遇到过这种情况自己没有 root 密码但又需要跑 Java 程序。包管理器安装需要 sudo而手动安装只需要把 JDK 解压到自己的家目录然后改自己的 ~/.bashrc 就行完全不需要 root。第四种是容器镜像内的运行环境。比如你要基于openjdk:17-jdk-slim这类镜像来构建业务镜像但需要在一个精简的 Linux 系统里临时用一个特定版本的 JDK 来执行某些编译或打包操作。在一个纯净系统里手动装一遍 JDK能让你对容器构建过程中的依赖关系理解得更清楚。所以不要觉得手动安装是“原始人”的做法。恰恰相反在真实的生产环境中手动安装往往是排查问题最少、最可控、最不容易踩坑的方案。2. 动手之前环境确认与下载准备2.1 先确认系统架构和位数我第一次给一台 ARM 服务器装 JDK 的时候没看架构就直接下载了 x86_64 的包结果解压完一执行就报 “cannot execute binary file”折腾了半天才反应过来是架构不匹配。所以无论你多熟悉 Linux动手前一定要先确认两件事操作系统发行版版本、CPU 架构。查看架构最常用的命令就是uname -m。如果是 x86_64 或者 amd64说明是 Intel/AMD 的 64 位架构下载 x64 版本如果是 aarch64 或者 arm64说明是 ARM 的 64 位架构下载 aarch64 版本。还有一个小众的指令集架构是 riscv64部分国产深度适配的机器上可能遇到下载时也要对应选择。# 查看系统架构x86_64 对应 x64aarch64 对应 ARM64 uname -m # 查看 Linux 发行版信息 cat /etc/os-release # 查看系统位数64 或 32 getconf LONG_BIT另外我建议顺手看一下cat /etc/os-release确认一下你的系统是 CentOS、Ubuntu、Debian 还是 Kylin 这类国产系统。虽然手动安装 OpenJDK 的命令在各 Linux 发行版上是通用的但后面配置环境变量时不同系统的文件路径和 shell 配置文件的加载机制会有一点点差别。比如 Ubuntu 默认 shell 可能是 bash也有用户在用 zsh配置文件就不一样。2.2 选下载源和版本靠谱的渠道就这几个OpenJDK 的下载渠道五花八门但真正靠谱的我只推荐几个。官方网站是https://jdk.java.net/这里是 OpenJDK 官方发布的 GA 版本一般是 tar.gz 格式也是最干净、最纯粹的选择。你可以在这里找到 JDK 21、JDK 17、JDK 11 等版本的通用 Linux 包。另一个很常用的渠道是 Adoptium也就是 Eclipse Temurin 项目地址是https://adoptium.net/。Temurin 是社区里口碑最好的 OpenJDK 发行版之一它提供了非常规范的下载页面和 API版本全、更新及时还提供校验和文件生产环境用得非常广。对于国内网络环境我建议直接用清华大学的镜像站地址是https://mirrors.tuna.tsinghua.edu.cn/Adoptium/。在里面按版本、操作系统、架构一层层进去找就行下载速度和稳定性都有保障比在 GitHub 上下载快得多。还有一个渠道是华为云镜像https://repo.huaweicloud.com/openjdk/也提供了多个版本的 OpenJDK 二进制包速度也不错。这里要特别提醒一句绝对不要去一些来路不明的第三方网站下载所谓“绿色版”或者“破解版”JDK。JVM 是运行你业务代码的核心组件如果被植入恶意代码后果非常严重。我见过有人图省事从非官网下载 JDK结果解压后运行就弹出可疑的提示这种包存在安全隐患直接丢弃才是最正确的选择。版本选择上我的建议很明确新项目无脑上 17 或 21老项目乖乖用 8。JDK 8 在 2026 年之后不会再发布免费的公共更新JDK 17 是目前覆盖面最广的 LTS 版本JDK 21 是当前最新的 LTS性能和安全都有明显提升。16 和 18 这种非 LTS 版本除非有特殊原因否则不建议在生产环境使用。2.3 把文件放到哪里先规划好目录手动安装最见基本功的地方就是文件放得整不整齐。目录规划得清晰后面管理和排查问题都省心。我个人的习惯是统一放在/usr/local/java下面然后按版本号区分目录。比如/usr/local/java/jdk-17.0.10 /usr/local/java/jdk-1.8.0_402如果只是想给某个用户使用不需要系统级全局生效那就放在用户家目录下比如~/jdk/jdk-17.0.10。另一种做法是放在/opt/java下面。/opt是专门给第三方软件用的目录语义上更清晰。总之不管是/usr/local/java还是/opt/java只要你固定在一个路径下并且在环境变量里配置好怎么放都行。不过在正式下载之前我建议先创建目录避免下载完才发现没有地方放。创建目录和后续解压操作需要用到 root 权限时用sudo或者切换到 root 用户执行sudo mkdir -p /usr/local/java顺便说一句如果是在云服务器上操作很多云平台的安全组策略默认限制了 HTTP 和 HTTPS 出方向但下载 JDK 这种 HTTPS 请求一般不受影响。万一遇到下载超时或者 Connection refused可以先检查一下服务器的 DNS 配置和网络连通性不要一上来就怀疑是 JDK 的问题。3. 核心实操解压、环境变量、验证一条龙3.1 解压与移动tar 命令的几个细节下载下来的 OpenJDK 包通常是.tar.gz格式。解压命令很固定但我还是要提醒几个细节。# 进入你存放安装包的目录 cd /usr/local/src # 解压 tar.gz 包 tar -zxvf jdk-17_linux-x64_bin.tar.gz如果你下载的文件是.tar.xz结尾需要把参数里的z去掉换成tar -xvf jdk-17_linux-x64_bin.tar.xz解压完成后当前目录下会多出一个类似jdk-17.0.10的目录。这个目录就是完整的 JDK 根目录里面有bin、conf、include、jmods、legal、lib这些子目录。接下来把它移动到之前规划好的目录里sudo mv jdk-17.0.10 /usr/local/java/有些教程会建议解压后直接在/usr/local下建一个名为jdk的软链接指向特定版本这样以后升级版本只需要换软链接不用改环境变量。这个思路很好后面讲多版本管理时会展开说。我记得有个朋友在 Windows 上用解压软件把 tar.gz 解压了然后把解压后的文件夹传到 Linux 服务器里用。结果出现了权限乱掉、符号链接丢失、文件执行权限缺失等各种莫名其妙的问题。我后来给的建议是在 Linux 上解压 Linux 的包在 Windows 上解压只会引入不必要的麻烦。如果你没有命令行环境访问服务器至少也要用支持 tar 格式的工具并且保留符号链接和权限再进行传输。另外热词里有个“linux 解压文件乱码”这里顺便提一嘴tar.gz 包本身不太会乱码乱码问题通常出现在 zip 包上原因主要是 Windows 和 Linux 默认编码不同。但 OpenJDK 官方提供的都是 tar.gz 包你基本不会碰到乱码。真遇到解压后乱码优先检查的是你的终端编码而不是文件本身。3.2 环境变量配置的三种方式这是手动安装 OpenJDK 的核心环节。解压只是把文件放到磁盘上想让系统找到java和javac命令必须配置JAVA_HOME和PATH环境变量。JAVA_HOME指向的就是 JDK 的根目录很多 Java 程序比如 Maven、Tomcat、Spring Boot 应用启动的时候都会读取这个变量。PATH则需要在原有路径的基础上追加${JAVA_HOME}/bin这样在终端里输入java时就能找到对应命令。第一种方式系统级全局配置修改/etc/profile或者/etc/environment。这种方式适合一台机器上只有一个统一的 Java 环境所有用户都能用sudo vim /etc/profile在文件末尾加上export JAVA_HOME/usr/local/java/jdk-17.0.10 export PATH$JAVA_HOME/bin:$PATH保存退出后执行source /etc/profile让配置立即生效。第二种方式用户级配置修改当前用户家目录下的~/.bashrc。这种方式最灵活不会影响系统里其他用户。尤其是你没有 root 权限的时候这是唯一的方案vim ~/.bashrc # 在文件末尾追加 export JAVA_HOME/home/myuser/jdk/jdk-17.0.10 export PATH$JAVA_HOME/bin:$PATH # 保存后生效 source ~/.bashrc第三种方式会话级临时配置直接在终端执行 export 命令。这种只对当前终端窗口有效终端关了或者重新登录就失效了适合快速测试某个 JDK 版本不做持久化export JAVA_HOME/tmp/jdk-17 export PATH$JAVA_HOME/bin:$PATH三种方式按需选择。我个人的习惯是生产服务器用第一种全局统一开发机或者多版本测试用第二种按用户隔离临时看效果用第三种。这里有一个特别容易踩的坑PATH的写法必须是export PATH$JAVA_HOME/bin:$PATH把现有的 PATH 追加在后面而不是export PATH$JAVA_HOME/bin。我之前见过一个新手把 PATH 覆盖了结果连ls和vim都执行不了因为系统命令的路径全丢了。如果真的遇到这种情况可以用绝对路径/usr/bin/vim或者/bin/ls来挽回颜面然后把配置修好。另外JAVA_HOME的路径不要写到bin这一层有人习惯写成/usr/local/java/jdk-17/bin结果后面很多依赖 JAVA_HOME 的工具反而找不到 JDK 了。JAVA_HOME 永远是 JDK 的根目录。3.3 验证安装别只看 java -version配置完环境变量最关键的一步就是验证。很多人敲一条java -version看到版本号就收工了但这远远不够。# 先看版本 java -version # 再看编译器很多场景下 javac 比 java 更重要 javac -version # 确认 JAVA_HOME 变量是否生效 echo $JAVA_HOME # 确认 java 命令实际被解析到了哪里 which java which javac我建议四步都跑一遍。java -version能正常运行说明 JRE 部分没问题javac -version正常说明 JDK 的编译功能没问题echo $JAVA_HOME能输出正确路径说明变量配置成功which java能输出/usr/local/java/jdk-17.0.10/bin/java而不是系统自带的/usr/bin/java说明 PATH 优先级正确。如果你输入java -version后看到的是系统预装的 OpenJDK 老版本说明/usr/bin/java在 PATH 里的位置比你的$JAVA_HOME/bin更靠前。解决办法就是重新确认/etc/profile里 PATH 的赋值顺序或者用后续会讲到的 alternatives 命令来调整系统默认的 java 命令指向。验证时还有一个小技巧如果新开的终端窗口里java -version没有生效而你明明source过了先别急着怀疑配置写错。在终端里执行一下echo $JAVA_HOME如果输出是空或者路径不对再检查是哪个配置文件优先级的问题。有些用户同时配置了/etc/profile、~/.bashrc、~/.bash_profile后加载的文件可能会覆盖前面的变量。4. 常见问题与排查技巧实录4.1 解压后没有 bin 目录或者执行报错有一次我在一台 CentOS 7 上手动装 OpenJDK解压完发现目录里根本没有bin/java。排查了半天发现是我下错了包下载的是 JRE 包而不是 JDK 包。JRE 只提供运行环境没有javac也没有完整的开发工具链。虽然现在 OpenJDK 官方已经不怎么单独发 JRE 包了但一些发行版和第三方源还是会有下载时一定看清名字里是jdk还是jre。还有一种情况文件确实解压出来了但执行./java -version提示cannot execute binary file。这种情况十有八九是架构不匹配。你在 x86_64 机器上装了 ARM64 版本或者反过来。解决办法就是回到第 2 节开头用uname -m确认架构重新下载对应的包。如果提示的是Permission denied那就是执行权限问题。解压出来的文件默认是没有可执行权限的但通常tar解压会保留归档内的权限位。老版本 tar 或者某些传输方式下可能会丢失。直接补一下权限chmod x /usr/local/java/jdk-17/bin/java不过一般来说正常从官方 tar.gz 解压都不用手动改权限这个问题更多出现在 Windows 解压再上传的场景。4.2 环境变量配了就是不生效这类问题在群里几乎每周都有人问。我总结下来主要有三个原因。第一个原因是配置写错了文件。你往~/.bashrc里写了但是当前用户的默认 shell 是 zsh那加载的就是~/.zshrc你的配置自然不会生效。检查一下echo $SHELL然后去对应的配置文件里加。第二个原因是 export 语句格式不对。bash 的变量赋值等号两边绝对不能有空格。export JAVA_HOME /usr/local/java/jdk-17这种写法就是错误的等于号两侧有空格会被解析成多个命令报错command not found。正确写法是export JAVA_HOME/usr/local/java/jdk-17。第三个原因是变量引用的时机问题。如果你在/etc/profile里写了export PATH$JAVA_HOME/bin:$PATH但 JAVA_HOME 的定义在 PATH 的下面那么 source 的时候 JAVA_HOME 还是空的PATH 也就会变成/bin:这种残缺路径。记住先定义 JAVA_HOME再定义 PATH。还有一种常见情况是你明明 source 成功了重新开一个终端窗口又失效了。这是因为非登录 shell 和登录 shell 加载的配置文件不同。Ubuntu 下~/.bashrc是在非登录交互式 shell 里加载的而/etc/profile是在登录 shell 里加载的。如果你的配置写在/etc/profile但你的终端窗口打开方式不会加载它就会表现为“重新登录有效新开窗口无效”。解决思路很简单要么统一写进/etc/profile要么写进~/.bashrc不要两边都写导致混乱。4.3 下载慢、下载失败以及校验技巧国内下载 Adoptium 或者 Oracle 的包有时候会很慢甚至超时。我常用的办法就是上清华镜像。速度差距非常明显一个几百 MB 的包官方源可能要下十几分钟清华镜像几秒钟就能完成。如果下载的过程中断了可以使用wget -c断点续传避免从头再来wget -c https://mirrors.tuna.tsinghua.edu.cn/Adoptium/17/jdk/x64/linux/OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz下载完成之后非常建议做一下校验和比对。不要小看这一步文件损坏或传输错误会导致解压失败或者运行异常。官方页面一般会同时提供 SHA256 校验值。sha256sum jdk-17_linux-x64_bin.tar.gz把输出的哈希值和官方给的值对比一致就说明文件完整不一致就要重新下载。这个步骤在离线环境通过 U 盘拷文件进内网时尤其重要U 盘拷贝中途可能出错很多诡异问题都是源文件损坏引起的。4.4 和系统自带的 JDK 打架Linux 很多发行版会预装 OpenJDK尤其是一些图形化的桌面版比如 Ubuntu Desktop 就默认带了一个。这时你手动安装了新的 JDK 并配置好环境变量java -version显示的可能还是系统自带的老版本。排查步骤如下# 查看系统默认的 java 命令指向哪里 which java # 查看 alternatives 注册的 JDK update-alternatives --list java # 注意CentOS 7 上命令是 alternatives --list java如果/usr/bin/java是一个指向/etc/alternatives/java的软链接说明系统通过 alternatives 机制管理 java 命令。你可以把它切换到你手动安装的 JDK 上sudo update-alternatives --config java然后根据提示输入对应的编号选择你要用的版本。如果你觉得系统自带的 JDK 实在碍事也可以直接卸载掉。Ubuntu 上sudo apt remove openjdk-*CentOS 7 上sudo yum remove java-*不过我还是建议不要轻易卸载系统自带的 JDK因为有些系统级工具可能依赖它。手动配好环境变量让用户自己的 JAVA_HOME 先生效反而是更安全的方式。5. 进阶多版本共存、软链管理与彻底卸载5.1 用 alternatives 管理多 JDK 版本实际工作中你经常会遇到这种需求手上有两个 Java 项目一个是用 JDK 8 编译的老项目另一个是 JDK 17 的新项目。两个项目不能同时跑在一个 JVM 参数下但你又不想来回装系统。这时候手动安装的优势就体现出来了。你把 JDK 8 和 JDK 17 分别解压到/usr/local/java/jdk-1.8.0_402和/usr/local/java/jdk-17.0.10然后用 alternatives 注册sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk-1.8.0_402/bin/java 1 sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk-17.0.10/bin/java 2 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk-1.8.0_402/bin/javac 1 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk-17.0.10/bin/javac 2这样注册后你随时可以通过下面这条命令交互式地选择系统默认的 java 版本sudo update-alternatives --config java sudo update-alternatives --config javac1和2是优先级数字越大优先级越高。当你不指定版本的时候系统会优先使用优先级更高的那个。还有一个更简洁的手法就是用一个统一的软链接来管理。这个方法我在生产环境用得最多。做法是建一个/usr/local/java/current软链接指向当前要用的 JDK 版本。环境变量里只配置JAVA_HOME/usr/local/java/current升级或切换版本时只需要把软链接改一下无需反复修改/etc/profile。# 创建软链接指向当前要用的版本 sudo ln -s /usr/local/java/jdk-17.0.10 /usr/local/java/current # 以后切换版本 sudo rm -f /usr/local/java/current sudo ln -s /usr/local/java/jdk-1.8.0_402 /usr/local/java/current这种方式简单粗暴在只有一两个 JDK 版本的情况下比 alternatives 更直观。配合脚本用起来尤其顺手。5.2 彻底卸载/移除手动安装的 JDK手动安装的卸载本质上是三步删目录、删环境变量配置、删软链接如果有。手动安装的 JDK 不会像包管理器安装的那样在系统里注册一堆东西所以卸载相当干净。先删除 JDK 目录sudo rm -rf /usr/local/java/jdk-17.0.10然后编辑/etc/profile或者~/.bashrc删掉你之前追加的两行 export 配置。如果你配置了/usr/local/java/current软链接也要删掉sudo rm -f /usr/local/java/current最后执行source /etc/profile让环境变量刷新再执行java -version确认系统里已经找不到这个版本了。这里我特别想说一下不要在卸载的时候顺手把/usr/local/java整个目录都删了。如果你在同一个目录下还放了其他版本的 JDK那就会被一起删掉。先ls看清楚目录内容再动手。如果你是通过 alternatives 注册过的注销命令也一样sudo update-alternatives --remove java /usr/local/java/jdk-17.0.10/bin/java sudo update-alternatives --remove javac /usr/local/java/jdk-17.0.10/bin/javac个人经验是手动装 JDK 到一个固定目录并配合软链接管理这个方法我从毕业用到今天稳定、可控、不操心。比起每次都要查包管理器的源里有没有对应版本手动安装给了我最直接的控制力。最后再分享一个小技巧不管你是装 JDK 8、11 还是 17都建议把下载的 tar.gz 包保留一份。放在/usr/local/src或者自己的备份目录里就行。因为有些内网环境以后要再装一台机器手上有个本地包就不用到处找下载源了。安装步骤熟了以后从下载到配好环境变量三分钟搞定这比临时查各种教程要快得多。