在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 17JDK 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/dnfUbuntu、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.128-262) Java HotSpot(TM) 64-Bit Server VM (build 17.0.128-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到11JDK 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.langALL-UNNAMED --add-opens java.base/java.utilALL-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和主类名比psgrep更直观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最后只能翻备份恢复的尴尬事从那以后就再也不敢手快了。
Linux下JDK安装与多版本切换指南：从环境变量到生产实践
在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 17JDK 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/dnfUbuntu、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.128-262) Java HotSpot(TM) 64-Bit Server VM (build 17.0.128-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到11JDK 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.langALL-UNNAMED --add-opens java.base/java.utilALL-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和主类名比psgrep更直观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最后只能翻备份恢复的尴尬事从那以后就再也不敢手快了。
