OpenJDK安装前无需卸载系统自带版本，因其通过update-alternatives机制实现多版本共存与切换，强行卸载易破坏依赖服务；仅在手动解压安装或存在来源不明/异常JDK时才需谨慎卸载。
不需要。OpenJDK 安装前完全不必卸载系统自带的 OpenJDK 或其他 Java 运行时，强行卸载反而容易破坏依赖它的服务（比如 systemd 工具链、python3-javapackages、某些监控 agent）。
为什么 rpm/apt 安装的 OpenJDK 可以和平共存
Linux 发行版（CentOS/RHEL/Ubuntu/麒麟等）通过包管理器安装的 OpenJDK（如 java-11-openjdk-devel、openjdk-17-jdk）默认使用 /usr/lib/jvm/ 下的独立子目录存放，彼此不覆盖。系统还内置了 update-alternatives 机制来统一调度 java、javac 等命令指向哪个版本——它不是靠“删旧装新”，而是靠注册和切换。
常见错误现象：java -version 显示的是旧版本，但 which java 却指向 /usr/bin/java（一个符号链接），而这个链接背后正是 update-alternatives 管理的；此时你直接删掉 /usr/lib/jvm/java-1.8.0-openjdk，可能导致 alternatives --config java 报错或失效。
- 用
rpm -qa | grep openjdk或dpkg -l | grep openjdk查看已装包，只关注“是否需要”而非“能否共存” - 不要用
rpm -e --nodeps强制卸载，除非你确认该包没被任何Requires:依赖引用 -
tzdata-java、javapackages-tools这类工具包必须保留，它们是 JDK 多版本协同工作的底层支撑
什么时候才真得考虑卸载
仅在两种明确场景下才需卸载已有 Java：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 你准备用 tar.gz 手动解压安装（比如从
jdk.java.net下的 OpenJDK 25），且希望彻底接管JAVA_HOME和PATH，避免包管理器版本干扰路径优先级 - 当前系统里混装了来源不明的 JDK（例如某第三方下载站打包的“绿色版”或带私有补丁的 JDK），运行
java -version输出含糊（如无 vendor 信息、版本号乱码），或出现cannot execute binary file: Exec format error（架构不匹配）
即便如此，也建议先用 update-alternatives --remove-all java 清理注册项，再删文件，而不是直接 rm -rf 目录。
多版本共存的实际配置要点
真正影响切换效果的不是“装几个”，而是“怎么指”：
-
JAVA_HOME应始终指向你当前想用的 JDK 根目录（如/usr/lib/jvm/java-17-openjdk-amd64），IDE、Maven、Gradle 都认这个变量 -
PATH中应只包含$JAVA_HOME/bin，不要硬编码多个/usr/lib/jvm/xxx/bin路径，否则java命令可能永远调不到你期望的版本 - 如果同时用了
update-alternatives和手动设置JAVA_HOME，前者管终端命令，后者管构建工具——二者可以并存，但别让JAVA_HOME指向/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.392.b08-1.el7_9.x86_64/jre这种带jre后缀的路径，它缺少javac
最易被忽略的一点：很多 CI 脚本或 Dockerfile 会直接写死 export JAVA_HOME=/usr/lib/jvm/default-java，但这个软链接在不同发行版中行为不一致（Ubuntu 有，CentOS 默认没有），跨环境部署时务必验证 $JAVA_HOME/bin/javac 是否真实存在。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
