Linux 下 Java 彻底卸载与重装指南：清理残留、配置 JAVA_HOME

1. 先搞清楚：卸载 Java 为什么比安装更容易踩坑

Linux 上卸载并重装 Java，听起来是五分钟的事：apt remove 一下，再 apt install 一下，完事。但真在服务器上操作过的人都知道，这只是理想剧本。实际遇到的情况往往是：java -version 输出的还是旧版本号，或者程序启动时报 JAVA_HOME 找不到路径，又或者明明删干净了，which java 居然还能返回一个路径。

很多经验不足的同学第一次折腾 Java 环境，就从"卸载重装"开始。但要我说，卸载这一步的坑远比安装多——安装只要保证下载对、配置对就行，卸载却要同时清理三个层面的残留：包管理器记录、符号链接与 alternatives 机制、环境变量。任何一个层面没清干净，后面装新版 Java 都会被"看不见的旧版本"干扰。

这篇文章不谈理论空话，直接聚焦 Linux 环境下 Java 的卸载与安装完整闭环，覆盖 Debian/Ubuntu 系和 Red Hat/CentOS 系两套体系，以及手动解压安装这种更原始的方式。适合刚接触 Linux 开发的入门者，也适合在项目现场被 Java 版本问题折磨到上头的运维和开发同学。我会把每一步为什么这样做、命令背后的机制是什么、哪些地方容易翻车，全部说清楚。

先说一个核心认知：Linux 里的 Java 不是"一个文件"，而是一整套由二进制文件、动态库、配置文件、符号链接和环境变量组成的生态系统。装 Java 时系统做的动作很少，但卸载时你要做的动作很多。很多人卸载不干净，不是因为命令不对，而是因为根本没意识到有这么多东西要管。

2. 动手卸载前，先把系统里的 Java 查清楚

2.1 定位 Java 的"真身"：which、readlink、ls 三连

我对所有同学的第一条建议都是：在卸载之前，先搞清楚系统里到底有哪些 Java、它们装在哪里、当前默认的是哪一个。这就像做手术前先拍片子，看起来多花了五分钟，实际上能省下后面两个小时。

先执行这一组命令：

bash复制which java
java -version
echo $JAVA_HOME

which java 告诉你当前命令行调用的 java 在哪个路径，但这通常不是全貌。在多数 Linux 发行版上，/usr/bin/java 其实是一个符号链接，它并不指向真实安装目录，而是指向 alternatives 体系的链接，再由这个链接指向真正的 JDK 路径。所以要看到完整链条，得再用：

bash复制ls -l /usr/bin/java
readlink -f $(which java)

举个例子，某台 Debian 系服务器上，这三条命令的输出可能长这样：

bash复制lrwxrwxrwx 1 root root 26 3月 12 10:22 /usr/bin/java -> /etc/alternatives/java
/usr/lib/jvm/java-17-openjdk-amd64/bin/java

看到了吗？/usr/bin/java 指向 /etc/alternatives/java，后者又指向真实 JDK 目录。如果只盯着 /usr/bin/java 这个文件去删，你删掉的只是一个软链接，真实 JDK 还躺在 /usr/lib/jvm 下面，环境变量也原封不动。很多人卸载后 java -version 还能执行，就是这个原因——真身还在。

2.2 分清是谁装的：包管理器记录 vs 手动解压文件

定位了当前使用的 Java 之后，还要盘点系统里所有 JDK/JRE 的安装记录。这里的关键分水岭是：你的 Java 是拿包管理器装的，还是手动解压 tar.gz 装的？这两种方式对应的卸载方法完全不同，混着操作最容易出错。

用 dpkg 或 rpm 包管理器安装的 Java，在系统里留有包记录，可以用包管理器干净地移除。而手动解压到 /opt/java、/usr/local/java 这类目录的版本，系统完全没有记录，只能靠手动删除文件来解决。

先执行一个全面的检索，看系统里有哪些 Java 组件：

Debian/Ubuntu 系：

bash复制dpkg -l | grep -i java
apt list --installed | grep -i java

Red Hat/CentOS 系：

bash复制rpm -qa | grep -i java

这个阶段你可能会看到一大堆跟 Java 相关的包名，比如 openjdk-17-jdk、openjdk-11-jre-headless、libcommons-logging-java 之类的。注意区分：有些是 Java 运行时本身，有些只是依赖 Java 的第三方库包，卸载时不能一刀切全部干掉，否则其他服务可能跟着遭殃。

同时，手动安装的 Java 也要找出来。可以从这些位置入手：

bash复制ls -l /usr/lib/jvm/
ls -l /opt/java/
ls -l /usr/local/java/

一套排查下来，你心里基本就有数了：系统里有哪些 Java、哪个是包管理器装的、哪个是手动放的。我建议把所有发现记录在一张纸上或者心里有个数，后面每一个操作都对照清单来，不要头脑一热就开始删。

3. 卸载 Java 的三种典型场景与操作细节

3.1 场景一：通过包管理器安装的 Java，怎么卸干净

这是最常见的情况。Debian/Ubuntu 下安装的 OpenJDK，通常包名类似于 openjdk-11-jdk、openjdk-17-jdk 这样。卸载命令是：

bash复制sudo apt purge openjdk-17-jdk openjdk-17-jre

注意我用的是 purge 而不是 remove。很多人只用了 apt remove，然后发现配置文件、环境变量脚本还残留在系统里。remove 只删除二进制和库文件，purge 连配置文件一起清掉。对于卸载 Java 这种需要"断干净"的场景，我始终建议 purge。

卸载后顺手执行一遍清理依赖：

bash复制sudo apt autoremove

autoremove 会检查系统中是否还有残留的、没有被任何已安装软件依赖的库包，将其一并清理。实测下来，这条命令经常能清掉几十个被 Java 带进来的无意义依赖包。如果担心误删，可以先不加 -y 参数，让它列出准备清理的包，人工确认一遍再执行。

Red Hat/CentOS 系使用的命令逻辑类似，但包管理器和包名规则不太一样：

bash复制sudo dnf remove java-17-openjdk java-17-openjdk-devel

这里有一个容易踩的坑：Red Hat 系的 JDK 拆得比 Debian 系更细，而且还区分 headless 和图形化版本。比如 java-17-openjdk 是 JRE，java-17-openjdk-devel 才是带编译器的完整 JDK。很多同学只删了前者，第二天项目编译时提示 javac: command not found，才发现原来是忘了删 devel 包。

包管理器卸载完成后，检查一下替代机制是否还残留旧版本：

bash复制update-alternatives --list java
update-alternatives --remove java /usr/lib/jvm/java-17-openjdk-amd64/bin/java

update-alternatives 是 Linux 里管理同名命令多版本共存的机制，用户态下的 java、javac 命令通过它统一调度。如果不把它里面注册的旧版本删除，后续安装新版本时，java 命令默认指向的可能是刚从 alternatives 里清理出来的悬空链接，导致明明安装了新 JDK，java -version 却报错找不到执行文件。

3.2 场景二：手动解压安装的 Java，怎么删得干干净净

手动解压安装这种方式的特征非常明显：没有包管理记录，所有文件都在一个目录里，比如 /opt/java/jdk-17.0.1。由于系统"不知道"它的存在，卸载走了完全不同的路线。

先删除 Java 所在目录：

bash复制sudo rm -rf /opt/java/jdk-17.0.1

这步删除是物理性的，没有回收站，所以执行前务必确认路径准确无误。我个人习惯使用 mv 先把要删的目录改名挪到临时位置，比如：

bash复制sudo mv /opt/java/jdk-17.0.1 /tmp/jdk-17.0.1.bak

等系统正常运行几天确认不需要它了，再真正 rm -rf。这个操作习惯多花一分钟，但能避免手滑把别人正在用的 Java 给删掉的灾难。

删完目录后，还要清理软链接。手动安装通常会在 /usr/bin 下创建软链接，把 java、javac 指到 JDK 目录的 bin/java 上。这时要执行：

bash复制sudo rm -f /usr/bin/java /usr/bin/javac

但光这样还不够。很多同学在配环境变量时，会把 JAVA_HOME 和 PATH 写进 /etc/profile、/etc/profile.d/java.sh、~/.bashrc 这些文件。这些配置如果不清除，即使文件已经删了，终端里 echo $JAVA_HOME 还是能显示原来的路径。更要命的是，某些启动脚本逻辑比较简单，只检查 JAVA_HOME 是否存在，一但变量非空就直接调用，结果运行时才会报 No such file or directory。

检查环境变量的方式：

bash复制echo $JAVA_HOME
echo $PATH
grep -r "JAVA_HOME" /etc/profile /etc/profile.d/ ~/.bashrc 2>/dev/null

搜索出相关行后，用 vim 或 sed 把对应配置注释或删除。这一步别偷懒，只删除环境变量在当前终端的值是不够的，必须修改配置文件本身，否则每次重新登录终端旧变量又回来了。

3.3 场景三：卸载后的环境清理

文件删了、软链接清了、包管理器也 purge 了，并不代表彻底干净。系统里还可能残留 Java 相关的辅助目录，比如 /usr/lib/jvm 下留下的空目录、~/.java 用户缓存目录，以及一些应用的 .jre 私有目录。

最直观的残留景象是：ls /usr/lib/jvm/ 下面还有一堆类似 java-11-openjdk-amd64 的空文件夹，这是包管理器卸载时没有完全清理的痕迹。处理方法是直接删除：

bash复制sudo rm -rf /usr/lib/jvm/java-11-openjdk-amd64

检查一下用户目录下的缓存和配置：

bash复制ls -la ~/.java ~/.gradle ~/.m2 2>/dev/null

~/.gradle 和 ~/.m2 是 Gradle 和 Maven 的本地仓库目录。它们不是 Java 本身，但里面缓存了依赖的元数据，其中有部分条目记录了旧版本 JDK 的路径。如果之后用 Maven 或 Gradle 构建项目时出现指向旧 JDK 的报错，把这些目录清掉重建也是排查手段之一。不过我要提醒一下：~/.m2/repository 里如果有几百个公司内部依赖包，清空之后要重新下载，成本不小。我的建议是，先不动 ~/.m2，等遇到构建工具报路径错误再处理它，不必提前"预防性"地删。

清理完这三层后，用这组命令做最终验证：

bash复制which java
javac -version
echo $JAVA_HOME

如果 which java 没有任何输出，java -version 报 command not found，说明系统层面已经"没有 Java"了。注意，这个状态对于某些场景是好事——干净的卸载完成了，可以开始安装新版本了。但如果你只是想把原来的版本升级成新版本，不必追求删到这个程度，只要有包管理器记录，直接安装新版它会覆盖冲突文件。

4. 安装新 Java：两种主流方式的具体操作

4.1 方式一：包管理器直接安装，适合大多数场景

说完了卸载，进入重装环节。如果你是 Debian/Ubuntu 系，最稳的安装方式就是用包管理器：

bash复制sudo apt update
sudo apt install openjdk-17-jdk

Red Hat/CentOS 系对应的是：

bash复制sudo dnf install java-17-openjdk-devel

这里我推荐安装 17 或更新的大版本，具体原因后面分析。包管理器安装的好处是：自动生成 /usr/bin/java 软链接、自动注册到 update-alternatives、自动处理依赖的库文件，整个安装过程不需要手工配置。缺点是你无法精确选择 JDK 的构建版本，比如你就想要 17.0.9 这个具体版本号，包管理器只能提供发行版仓库里当前收录的版本。

安装完成后，验证一下：

bash复制java -version
javac -version

如果你对输出结果没有特殊期待，只需要确认能正常显示版本号，且 java 和 javac 都能找到，就说明安装基本成功了。

在这里多说一句版本选择的问题。Java 的大版本生命周期里，LTS（长期支持）版本是生产环境的合理选择。8、11、17、21 都是 LTS，但 8 太老，很多框架已经在放弃支持或保留兼容模式，21 虽然新，一些企业和开源生态还没有完全跟上。两种项目场景怎么选，我的经验是这样的：老项目需要环境兼容时用 8，新项目起步时直接上 17。如果今天在 17 和 21 之间犹豫，通常选 17 不会出错——生态兼容性更稳，构建工具支持已经很成熟。为保险起见，你可以先按 17 装一套，后面项目如果明确要求 21，再用后面讲到的手动安装方式切换。

4.2 方式二：手动安装 tar.gz 解压版，适合需要精确控制版本的场景

如果你在多个项目间切换，需要精确到某个小版本；或者你的项目要求必须用某个特定构建版本，而包管理器仓库里没有，那就要走手动安装了。

第一步，去官方或开源镜像站下载对应版本的 tar.gz 包。下载后先做校验：

bash复制sha256sum jdk-17.0.9_linux-x64_bin.tar.gz

把输出和官方发布的校验值对比，确认文件完整无误，再执行解压：

bash复制sudo mkdir -p /opt/java
sudo tar -xzf jdk-17.0.9_linux-x64_bin.tar.gz -C /opt/java

解压完成后，目录结构应该长这样：

bash复制ls /opt/java/jdk-17.0.9/

里面应该有 bin、lib、conf、include 这些子目录。看到 bin/javac 存在于解压目录中，说明解压成功。

为了让 PATH 里的 java 命令能直接指向这个新版本，需要创建软链接。我的做法是把软链接放到 /usr/bin/ 下：

bash复制sudo ln -sf /opt/java/jdk-17.0.9/bin/java /usr/bin/java
sudo ln -sf /opt/java/jdk-17.0.9/bin/javac /usr/bin/javac

注意这里我加了 -f 参数，表示强制覆盖。如果之前已经存在软链接指向旧版本，这个参数能一步到位切换过来。如果你希望保留多个版本切换，就不要用软链接覆盖这种粗暴方式，而是注册到 update-alternatives，我在后面的常见问题里会展开讲。

4.3 JAVA_HOME 与 PATH 配置的关键细节

手动安装之后，最重要的一步是配环境变量。这里的核心原则就一句话：JAVA_HOME 指向 JDK 解压目录的根路径，不要带 /bin。 PATH 里添加的是 $JAVA_HOME/bin，而不是 $JAVA_HOME 本身。

正确写法：

bash复制export JAVA_HOME=/opt/java/jdk-17.0.9
export PATH=$JAVA_HOME/bin:$PATH

错误写法（我见过不少人写成这样）：

bash复制export JAVA_HOME=/opt/java/jdk-17.0.9/bin
export PATH=$JAVA_HOME:$PATH

第二种写法会导致 PATH 多出一个指向 .../bin/bin 的无效路径，同时许多依赖 JAVA_HOME 的脚本（比如启动脚本、构建工具）会因为没有找到 lib、bin 目录而行为异常。

配置文件放哪里也有讲究。我的建议是放在 /etc/profile.d/java.sh，而不是直接改 /etc/profile 或者 ~/.bashrc。原因是 /etc/profile.d/ 下的脚本片段会在用户登录时自动加载，独立成文件便于集中管理。如果以后切换版本，只需要改这一个文件。

bash复制sudo tee /etc/profile.d/java.sh << 'EOF'
export JAVA_HOME=/opt/java/jdk-17.0.9
export PATH=$JAVA_HOME/bin:$PATH
EOF

修改后让配置立即生效：

bash复制source /etc/profile.d/java.sh

最后验证：

bash复制echo $JAVA_HOME
echo $PATH
java -version
javac -version

这几项全部正常，安装就算真正完成了。

5. 常见问题与排查实录：java -version 之后的一切

5.1 卸载后 command not found，但程序仍然能找到旧 Java

有一个非常典型的场景：你执行了完整的卸载流程，which java 返回空，java -version 告诉你 command not found。结果某个应用重启后，日志里还显示它用的是卸载前的旧 Java 版本，路径还是那个已经删除的目录。

为什么？因为很多应用服务在启动时，并不会读取交互式 shell 的环境变量，而是读取自己配置文件里写死的路径。最常见的就是 systemd 服务单元文件里的设置，比如：

ini复制Environment=JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

或者某些 Tomcat、Spring Boot 应用的 setenv.sh 里，明确写了 JAVA_HOME 和 PATH。这类文件平时不会跟系统的 /etc/profile 一起更新，即使你把系统级环境全部清干净了，这些应用还是会按自己的配置去找旧路径。

解决办法就是全局搜索残留路径的引用：

bash复制grep -r "java-11" /etc/systemd/system/ /opt/ /home/ 2>/dev/null

找到后逐一修改或注释掉。这个问题的核心启发是：卸载 Java 时，不能只盯着自己的终端环境变量，还要考虑到其他软件可能已经"记住"了你系统里的 Java 路径。

5.2 多版本切换：update-alternatives 与软链接冲突

实际项目中经常遇到多个 Java 版本并存的需求，比如一个老项目要求 8，一个新项目要求 17。这种场景最容易踩的坑是：两个版本都安装了，java -version 显示的却不是你想用的那个。

先说明底层机制。当系统里存在多个 Java 版本时，/usr/bin/java 应该通过 update-alternatives 来管理，而不是直接 ln -sf 强行覆盖。执行下面命令可以查看当前所有注册的 Java 备选项：

bash复制update-alternatives --display java

如果你看到类似这种输出：

bash复制java - auto mode
   link best version is /usr/lib/jvm/java-17-openjdk-amd64/bin/java
   currently points to /usr/lib/jvm/java-17-openjdk-amd64/bin/java

说明系统正通过 alternatives 机制管理 java 命令。手动切换当前使用的版本只需要：

bash复制sudo update-alternatives --config java

这是一个交互式命令，会列出所有已注册的 Java 路径，输入编号即可切换。同理，javac 也要单独切一次：

bash复制sudo update-alternatives --config javac

这里容易出的问题是：包管理器安装的新版本会自动注册到 alternatives，但手动解压的版本不会。所以如果你把手动安装的 JDK 放到 /opt/java，然后用 ln -sf 强行覆盖了 /usr/bin/java 软链接，下次运行 update-alternatives --config java，这个手动版本可能不会出现在列表里，或者列表里显示的是悬空链接。正确的做法是手动注册：

bash复制sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17.0.9/bin/java 100
sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk-17.0.9/bin/javac 100

最后的数字是优先级，数值越大优先级越高。注册完成后，再执行 update-alternatives --config java，就能看到多个版本并列展示，随时用数字键快速切换。

5.3 环境变量不生效：临时生效、登录生效、常驻生效三套逻辑

环境变量配置之后不生效，是安装 Java 后高频出现的问题。具体表现是：手动 source 配置文件后 java -version 正常，重新开一个终端窗口却提示找不到命令。

原因在于 Linux 加载配置文件的时序逻辑。source /etc/profile.d/java.sh 只会让当前终端生效，新开的终端窗口不会自动继承你手动执行过的 export，它只会读取登录时加载的配置文件。所以排查思路是这样的：

第一，确认配置文件写对了位置。/etc/profile.d/ 下的脚本对所有用户生效，~/.bashrc 只对当前用户生效。如果你是普通用户而非 root，系统管理员把 Java 装在了 /opt/java，但配置文件写进了 /root/.bashrc，你登录后自然会看不到。

第二，确认当前 shell 是否重新加载过配置。用 bash -l 重新开一个登录 shell 测试，或者直接断开 SSH 重新连接。登录 shell 才会执行 /etc/profile 及 /etc/profile.d/ 下的脚本，非登录交互式 shell 只执行 ~/.bashrc。

第三，用 env 命令检查当前环境变量是否真的设置成功：

bash复制env | grep JAVA

这个命令展示的是当前进程实际继承的环境变量，比 echo $JAVA_HOME 更能反映真实状态。如果 env 里没有，说明配置根本没被加载；如果 env 里有但 java -version 还是找不到命令，那多半是 PATH 顺序的问题——前面有某个目录里存在一个残缺的 java 文件，优先级比你的 JDK 更高。这种情况直接输出 PATH 排查：

bash复制echo $PATH

逐段检查 PATH 中每条路径下是否存在和 java 同名的可执行文件，找到后清理掉那个残留即可。

另外，我还想提醒一个 GUI 和桌面环境相关的坑：如果你在桌面 Linux 上工作，通过图形界面启动的终端（比如 GNOME Terminal），有时候继承的环境变量和通过 SSH 登录的终端不同。桌面会话的全局环境变量通常在 ~/.pam_environment 或上面提到的配置文件里管理，处理方式大同小异，但排查思路要额外多想到这一层。

5.4 配置速查与常见报错对照

把手头常遇到的问题整理一下，统一放在下面这个表里，方便对照排查：

这张表不是让我用来套用所有情况的，真正的排障价值在于"先判断是哪个层面出了问题，再去动对应层面的配置"。系统层面、用户层面、应用层面，三个层面互不干扰，先定位再动手，永远比乱试命令更高效。

6. 最后再分享一个小经验

在 Linux 上卸载和安装 Java，说到底不是记命令的问题，而是建立一套"看得见全貌"的排查习惯。我在实际运维和开发中反复踩坑之后，现在每次操作 Java 环境，都会先给自己列一个问题清单：这个 Java 是怎么装的？包管理器有没有记录？软链接指向哪？配置写在哪？卸载还是切换版本？四个问题问完再动手，基本不会翻车。

一个我特别想强调的细节是：永远不要为了省事跳过手动清理残留这一步。卸载 Java 不像卸载普通软件那样删完就万事大吉，它的环境变量和 alternatives 注册往往是最难清的部分。宁可多花十分钟检查 grep -r 全局搜索一遍旧路径引用，也不要等到线上项目启动时报错才开始后悔。

如果你正在做的项目切换多个 Java 版本，我建议把 update-alternatives 的用法好好啃透，它比频繁改环境变量、反复重建软链接要稳定得多。每当要切换版本时，一条 update-alternatives --config java 搞定问题，这才是 Linux 多版本共存的优雅姿势。