在Linux上安装JDK这件事，说简单真简单，一条yum install java-17-openjdk就能装完；但说麻烦也麻烦，光是“装哪个版本”“用包管理器还是解压包”“环境变量写进哪个文件”“为什么明明装好了java -version还是报错”这几个问题，就能让不少刚接触服务器的Java开发者和运维新手卡上半天。我最早部署Java应用时也在这上面栽过跟头，后来在CentOS、Ubuntu、Debian、统信UOS这些系统上都反复装过好几轮，才把整套流程和背后的原理彻底捋顺。这篇就把我从版本选型到安装落地的完整思路写出来，覆盖最常用场景，也把那些容易踩的坑一并说清。
这篇文章适合谁？刚入行需要搭开发环境的Java程序员、要在服务器上部署Java应用的全栈或运维同学，以及正在准备Linux相关面试、想把JDK安装这类基础操作真正搞懂的人。读完你不仅会敲命令，还能明白每条命令为什么这么写、出了问题该往哪个方向排查。
1. 版本选择和安装方式，先想清楚再动手
1.1 JDK版本怎么选：8、11、17还是21
很多新手上来就问“装哪个JDK版本”，其实这个问题没有标准答案，关键看你的业务场景和项目要求。目前主流的选择集中在三个LTS版本：JDK 8、JDK 11和JDK 17（JDK 21也已经LTS了，但生产环境普及度还没跟上）。
JDK 8可以说是Java界的“常青树”，大量老项目、金融系统和传统企业应用都跑在8上面，如果你接手的是一个运行了三五年的老系统，装8基本不会错。JDK 11是8之后第一个值得关注的LTS版本，中间经历了9和10的模块化调整，到11才算稳定下来，很多中大型互联网公司在这个版本上完成了技术栈升级。JDK 17则是目前增量最快的版本，Spring Boot 3.x和Spring Framework 6.x直接要求JDK 17起步，新的项目建议直接选它。
我的建议是：新项目无脑奔JDK 17，老项目看项目依赖的Spring版本、构建工具兼容性和历史包袱。比如项目里用了很老的第三方库，它在JDK 17下可能因为强封装和模块系统直接起不来，这时候强行升版本只会给自己找麻烦。另外，不少人在网上搜“jdk降级到17”，就是因为装了更高版本后某些框架不兼容，又切回到17。所以选版本这件事，千万别追求最新，追求“项目能稳定跑”才是第一原则。
顺带把JDK、JRE、JVM这三个概念理一理，这也是面试高频题。JVM是Java虚拟机，负责把字节码翻译成机器码并执行；JRE是Java运行时环境，包含JVM和运行Java程序所需要的核心类库；JDK是Java开发工具包，包含JRE，还额外提供了javac编译器、jar打包工具、jstack诊断工具等。简单说：你要运行Java程序，装JRE就够了；你要开发Java程序，必须装JDK。这也是为什么生产服务器如果只跑编译好的jar包，有些人会只装JRE节省空间，但日常开发机必须装完整JDK。
1.2 不同安装方式怎么选：包管理器、压缩包还是源码编译
Linux下安装JDK的主力方式有三种：用发行版自带的包管理器安装、从官方下载tar.gz压缩包手动安装、以及源码编译安装。三者的定位差别很大。
包管理器安装是最省心的一种，比如CentOS、Rocky Linux上的yum/dnf，Ubuntu、Debian上的apt，输入一行命令就能装上OpenJDK，依赖自动处理，升级也方便。但缺点是版本往往不是最新的，而且不同发行版仓库里提供的JDK版本和构建方不太一样，你没法精确控制JDK的小版本号。另外，如果你需要Oracle JDK，包管理器默认源里通常没有，得额外配源或者手动装。
tar.gz压缩包手动安装是我个人在生产环境中用得最多的方式。它的核心优势是“自包含”，把JVM和所有文件放在一个目录里，不污染系统其他位置，想换版本就解压一个新目录、切换软链接，想卸就删目录，干净利落；缺点是要自己配置环境变量、自己管升级，稍微麻烦一点点，但理解了之后一劳永逸。
源码编译安装基本属于折腾型选手的选择，需要先装gcc、make这些编译工具链，然后配置--with-boot-jdk等参数，编译一次耗时二十分钟起步。生产环境和普通开发机完全没必要这么搞，除非你在做嵌入式系统、特定架构交叉编译，或者需要给某个定制系统做特殊优化，否则这条直接跳过。
用一张表把这几种方式说清楚：
| 安装方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 包管理器（yum/apt） | 命令简单、依赖自动处理、升级方便 | 版本可能较旧、不可精确控制小版本 | 快速搭建开发环境、系统自带即可 |
| tar.gz 手动安装 | 版本可控、目录隔离、卸载干净 | 需手动配环境变量、升级靠自己 | 生产环境、多版本并存、精确控制 |
| rpm/deb包安装 | 能注册系统服务、可用alternatives管理 | 不同包格式不通用、卸载有时留残留 | 企业内统一管理、批量部署 |
| 源码编译 | 可定制化程度高、优化空间大 | 编译耗时、依赖复杂、维护成本高 | 嵌入式、交叉编译、定制系统 |
我建议个人开发机图省事用第一条，生产服务器和需要严格控制版本的环境用第二种。后面整个实操过程也以tar.gz手动安装为主，因为这个过程把“JDK到底装到了哪里”“环境变量是怎么生效的”这些底层链路全部走了一遍，理解透了，其他安装方式都是小菜。
2. 手动安装JDK 17的完整步骤，每一步都讲透
2.1 先确认系统架构和位数，别下错包
下载JDK之前必须先搞清楚服务器的CPU架构。常见的输出有两种：x86_64代表Intel或AMD的64位架构，绝大多数云服务器和PC服务器都是这个；aarch64代表ARM架构，现在很多ARM云主机、国产化服务器（比如鲲鹏、飞腾）都是这种。如果你下载了不对应的包，装好后运行java -version大概率会报“cannot execute binary file”之类的错误。
确认架构用这一条命令：
uname -m也可以看更详细的系统信息：
lscpu | grep Architecturelscpu的输出里除了架构，还能看到CPU型号、核心数、虚拟化支持等信息，排查其他问题时也经常用到，建议养成先看系统信息的习惯。
拿到架构信息后，再去下载对应架构的JDK 17压缩包。这里提醒一句：尽量从官方渠道或可信的开源发行版下载，避免使用来路不明的第三方打包版本——你永远不知道别人在JDK里塞了什么额外“惊喜”。下载时可以先把包放到/tmp目录下，安装完成后再清理，避免污染正式目录。
2.2 解压安装和目录规划，建议按这个规范来
生产环境装JDK，目录规划很讲究。我习惯把JDK放在/usr/local/java目录下面，每一个版本单独一个子目录，例如：
/usr/local/java/jdk-17.0.12 /usr/local/java/jdk-8u202这样做的理由有三个：一是/usr/local是Linux系统约定的本地安装软件目录，用户自己编译或手动安装的程序放这里符合惯例；二是所有JDK版本集中在一个父目录下，切换版本时只用改环境变量和软链接；三是后续要安装Tomcat、Maven，它们默认会找JAVA_HOME，目录结构清晰能省很多排查时间。
具体操作步骤：
# 1. 创建统一目录 mkdir -p /usr/local/java # 2. 解压到当前目录（我一般先解压到/tmp，再移动过去） tar -zxvf jdk-17_linux-x64_bin.tar.gz -C /tmp # 3. 移动到统一目录，顺便把目录名改简洁一点 mv /tmp/jdk-17.0.12 /usr/local/java/jdk-17.0.12 # 4. 创建软链接，方便切换版本 ln -s /usr/local/java/jdk-17.0.12 /usr/local/java/latest这里解释一下tar -zxvf的各个参数：z表示用gzip解压，x表示解压，v表示显示解压过程（不想看一堆文件名可以去掉），f表示后面跟的是文件名。-C /tmp指定了解压的目标目录，这是很多新手容易漏掉的参数，不加的话文件会直接解到当前工作目录。
第4步创建软链接是我个人强烈推荐的操作。软链接类似于Windows里的快捷方式，后续环境变量只指向latest，以后升级JDK时把新版本解压进来，改一下软链接指向，其他配置完全不用动。这个技巧在用alternatives切换版本时同样适用。
2.3 环境变量配置：JAVA_HOME、PATH和CLASSPATH
解压完JDK之后还差最后一步：让系统知道JDK装在哪里。这里就要配置环境变量了。环境变量的配置文件有几个，作用范围不同：/etc/profile是系统级配置，对所有用户生效；~/.bashrc是当前用户的个人配置，只对当前用户生效；/etc/profile.d/目录下的脚本会在用户登录时被加载，适合放一些独立的模块配置。
生产环境我建议配置在/etc/profile.d/java.sh里，而不是直接改/etc/profile。这样做的原因是/etc/profile.d下的脚本本身就是被/etc/profile加载的，而且独立文件管理起来清晰，以后卸载JDK时直接删这个文件就行，不影响系统其他配置。
创建配置文件：
vim /etc/profile.d/java.sh写入以下内容：
export JAVA_HOME=/usr/local/java/latest export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib逐行解释一下。JAVA_HOME是JDK的安装根目录，很多框架（Tomcat、Maven、Gradle、IDEA）会通过这个变量找到JDK，所以必须配。PATH把$JAVA_HOME/bin加到了原有PATH的前面，这样系统在终端里执行java、javac命令时，会优先在JDK的bin目录里找到对应的可执行文件；注意$PATH一定要写在后面，不然会覆盖掉系统原有的PATH，导致ls、vim这些基础命令都找不到。CLASSPATH表示类搜索路径，.代表当前目录，$JAVA_HOME/lib是JDK自带库；新版本JDK其实不强制要求配CLASSPATH了，但配上能兼容一些老项目的脚本，无伤大雅。
配置完成后，让环境变量立即生效：
source /etc/profile.d/java.sh这里有个很容易踩的坑：很多新手用source /etc/profile的方式重新加载，有些发行版的/etc/profile里可能没有包含/etc/profile.d的加载逻辑，或者因为Shell类型不同（bash、zsh、sh）导致加载时机不一样，结果环境变量怎么都不生效。因此我一般直接source具体文件，简单直接，不绕弯。
验证安装结果：
java -version javac -version echo $JAVA_HOME如果输出类似下面这种，说明安装成功：
java version "17.0.12" 2024-07-16 LTS Java(TM) SE Runtime Environment (build 17.0.12+8-262) Java HotSpot(TM) 64-Bit Server VM (build 17.0.12+8-262, mixed mode, sharing)java -version验证的是JVM运行时，javac -version验证的是编译器和完整JDK环境。如果java能执行但javac找不到，说明你装的可能只是JRE而不是完整JDK，或者PATH没有指向正确的bin目录，这是排查时很重要的一个判断依据。
3. 多版本JDK并存与切换，用alternatives统一管理
3.1 update-alternatives的原理和操作
实际开发中经常遇到这种情况：手上管着好几个Java项目，一个要求JDK 8，另一个要求JDK 17，如果每次都手动改环境变量再重新登录，效率太低，而且容易出错。Linux提供了一个系统级的多版本管理工具：update-alternatives。
这个工具的管理对象是“命令别名”，原理其实很简单：系统在/usr/bin/java这个路径放了一个软链接，指向/etc/alternatives/java，而/etc/alternatives/java又指向真正的JDK可执行文件。update-alternatives就是用来维护这层软链接指向的工具。
先把当前手动安装的JDK注册到alternatives里：
update-alternatives --install /usr/bin/java java /usr/local/java/jdk-17.0.12/bin/java 17 update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk-17.0.12/bin/javac 17注册命令里的几个参数分别是：/usr/bin/java是链接将被创建的路径，java是这个组的名称，/usr/local/java/jdk-17.0.12/bin/java是实际的JDK路径，最后的数字是优先级——当存在多个候选时，优先级高的会被自动选中。
如果你还有另外一个JDK 8，用同样的方式注册，然后切换：
update-alternatives --config java执行后会看到类似这样的交互界面，列出所有已注册的JDK编号，输入对应数字回车即可切换：
There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- * 1 /usr/local/java/jdk-17.0.12/bin/java 2 /usr/local/java/jdk-8u202/bin/java Enter to keep the current selection[+], or type selection number:切换完用java -version就能确认当前生效的版本。注意javac也需要同样切换一次，否则可能出现java是17版本、javac还是8版本的情况，后面编译时报奇怪的错误。
3.2 排查系统中残留的旧JDK
使用包管理器安装过JDK的系统，想切换或者升级时经常发现“明明把新版本装好了，java -version还是旧版本”，这种情况八成是系统的/usr/bin/java软链接还在指向旧版本，或者PATH的环境变量顺序有问题。排查套路如下。
先看which java的结果，确认命令最终落在哪个路径：
which java如果输出是/usr/bin/java，再看它指向哪里：
ls -l /usr/bin/java正常情况下你会看到一个软链接，多级软链接也能通过这步看出最终指向。然后检查PATH顺序：
echo $PATH如果/usr/local/java/latest/bin排在后面，而系统自带的OpenJDK路径排在前面，那么执行java -version时就会优先用系统的旧版本。这时候要么调整环境变量里PATH的书写顺序，要么通过update-alternatives统一管理，把系统自带的候选优先级调低。
对于不想要的旧版本，可以用包管理器自带的命令卸载。CentOS、Rocky这类用rpm -qa | grep jdk查出来再rpm -e卸载，Ubuntu、Debian用dpkg -l | grep jdk配合apt purge卸载。卸载之前建议先确认项目没有依赖这个特定版本的JDK，否则线上环境直接“翻车”是很常见的。
3.3 实战场景：IDEA、Tomcat、Maven怎么指定JDK版本
装了多版本JDK之后，还有个高频操作：给特定框架或IDE指定JDK版本。
IDEA里全局设置位于File -> Project Structure -> SDKs，可以点击Add SDK手动添加本地JDK路径；新版本的IDEA在Settings -> Build, Execution, Deployment -> Build Tools -> Maven -> Runner里还能单独指定Maven运行时的JRE。开发机装多个JDK很常见，但要注意IDEA编译用的JDK版本和项目要求的target字节码版本要匹配，否则跑起来没问题，打包时却报“invalid target release”错误。
Tomcat是Java Web部署中最常见的环境。Tomcat启动时会读取CATALINA_HOME/bin/setenv.sh（如果没有可以手动创建），在里面显式指定：
export JAVA_HOME=/usr/local/java/latest export JRE_HOME=$JAVA_HOME有些老项目用了Tomcat 8或者更早的版本，它们对JDK版本有兼容性要求，比如Tomcat 8.5支持JDK 8到11，JDK 17就未必能很好兼容，这种场景下单独给Tomcat指向一个JDK 8的路径，比全局切换系统JDK要安全得多。
Maven同理，mvn -version会显示当前使用的Java版本，如果和你预期不一致，可以编辑/etc/mavenrc或者~/.mavenrc，写入：
export JAVA_HOME=/usr/local/java/jdk-17.0.12这种做法其实就是“局部覆盖全局”：JAVA_HOME这个变量在读取时，越具体的配置生效优先级越高。理解了这个逻辑，以后不管哪个框架需要指定JDK版本，思路都是一样的。
4. 常见报错与排查技巧，都是我踩过的坑
4.1 java: command not found，装了却用不了
这个报错最常见的原因是环境变量没配好或者没重新加载。核对的顺序建议是：
ls -l /usr/local/java/latest/bin/java echo $JAVA_HOME echo $PATH第一行确认JDK目录和软链接是否存在，第二行确认JAVA_HOME是否已设置，第三行确认$JAVA_HOME/bin是否在PATH里。哪一步有问题就修哪一步。
还有一个隐藏坑：如果你用的是sudo执行命令，sudo环境下会重置大部分用户级环境变量，所以java -version在普通用户下正常，在sudo java -version下反而报command not found。这种情况需要把环境变量配置在/etc/profile.d/java.sh（系统级配置）里，sudo命令默认会加载/etc/profile里的设置，或者用sudo -E保留当前用户环境变量。
4.2 版本不对，java -version还是旧版本
这种情况前面已经提过，核心原因就是PATH顺序或者alternatives配置问题。这里再补充一个检测思路：
readlink -f $(which java)readlink -f会一路追踪软链接直到最终的实际文件路径，一步到位看清你执行java时用到的到底是哪个JDK。看到路径之后再对照你的预期版本，就能快速定位问题。
有时候修改了环境变量并重启终端后，java -version还是旧的，这是因为bash会缓存命令的路径（hash表）。执行一下hash -r清理缓存即可：
hash -r4.3 JDK 17新特性引发的项目启动失败
如果你原本跑在JDK 8上的Spring Boot项目直接切到JDK 17启动，有可能会遇到一堆报错，典型的包括：java.lang.reflect.InaccessibleObjectException，原因是模块化系统（JPMS）默认禁止了深度反射；还有IllegalAccessError，多半是用了--add-opens才能解决的问题。这不是安装的问题，而是项目兼容性问题。
解决思路有两个：一是改代码，去掉对JDK内部API的反射调用，但这个成本高；二是配置启动参数，在启动脚本里加上：
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED这一类参数的数量取决于项目依赖了哪些内部API。网上能搜到很多针对不同框架的通用命令，但一定要理解参数含义再复制，别一套参数全项目通用，很容易掩盖真正的问题。
4.4 面试高频知识点：Linux常用命令与JDK关联
既然讲到了Linux运维，顺便把面试里经常被问到的几个点串一下。很多人搜“linux常用命令”背了一大堆，但在实际排查JDK问题时根本用不出来，本质原因是没有把命令和场景关联起来。
排查Java进程问题的高频命令组合：
# 查看Java进程及其参数 ps -ef | grep java # 或 jps -l # 查看进程实际使用的JDK路径 ls -l /proc/$(pgrep java)/exe # 查看JVM启动参数 jcmd $(pgrep java) VM.command_linejps是JDK自带的工具，列出本地Java进程的PID和主类名，比ps+grep更直观；ls -l /proc/PID/exe能显示进程启动时用的可执行文件，能看出这个进程到底走的哪套JDK，这一招在系统里有多版本JDK时非常实用，算是排查“进程用的和命令行看到的不一致”这个问题的杀手锏。
还有jstack、jmap、jstat这几个JDK自带诊断工具，生产环境定位线程死锁、堆内存溢出和GC问题时都是主力。面试如果问到JVM调优，能熟练说出几个诊断工具的适用场景，会是个加分项。
整体排查流程可以概括为：先确认命令找没找到（which、JAVA_HOME、PATH），再确认找到的是不是预期的版本（java -version、readlink -f），再确认具体进程用的是哪个JDK和哪些参数（ps -ef、/proc、jcmd），层级递进，基本不会漏掉问题点。
5. 生产环境的最佳实践和一些真心话
按这个思路安装JDK，本质上是把“软件安装”这件事从黑盒变成了白盒：你知道JDK躺在哪个目录，环境变量是怎么生效的，系统里有哪些版本在共用同一套PATH，换版本时动的是什么。这种掌控感在开发机还好，在线上环境是真的能救命的。
几个生产环境的心得，在这里一并分享。
第一，部署环境里尽量不要用“最新版”。线上系统追求稳定，JDK 8的老项目没必要盲目升级到更高版本，新项目也建议锁定一个LTS版本，比如17，然后在小版本上保持更新即可。每次大版本升级前，至少先在预发布环境把完整的回归测试跑一遍，你编译出来的不是测试代码，是线上的订单和用户数据。
第二，所有手动安装的软件，尽量用一套统一的目录规范。我的习惯是/usr/local/软件名/版本号，再用latest软链接指向当前用到的版本。这套规范不仅对JDK适用，对Tomcat、Nginx、Redis都适用，系统里维护了十几个组件之后，这种规范能省下大量查目录、找版本的时间。
第三，把安装过程记录下来。可以是你内部运维文档里的一份部署手册，也可以是这边帖子这样的笔记。我见过太多服务器“年久失修”，文档里写着JDK 8，机器上跑的是4个不同版本的JDK，没有人能说清哪个服务在用哪个。把版本、路径、部署日期、部署人这些信息记下来，过半年你回头看，会感谢当时的自己。
第四，多掌握几条Linux常用命令没有坏处。排查JDK问题用得上which、ls、ln、find、grep、ps、readlink，排查网络和部署问题还会用到scp、netstat、ss这些。很多运维岗位面试都会考Linux基础，平时多积累、多手动操作，比临时背命令要扎实得多。
最后说个小技巧：给生产环境做JDK升级时，别急着把原目录删掉。把旧版本目录留着，只切换软链接和新版本跑一段时间，确认运行稳定后再清理。这个“灰发切换”的思路，能让你在出现问题时有退路可走，比任何备份脚本都可靠。我自己就因为急着删旧目录，遇到过新版本JVM频繁Full GC，最后只能翻备份恢复的尴尬事，从那以后就再也不敢手快了。
