centos上java版本冲突怎么办

在CentOS上捣鼓Ja va开发的朋友，十有八九都遇过版本冲突这个坎儿。表现很直白——系统默认的Ja va版本跟项目要求的不一致，或者编译、运行时直接抛出来一个UnsupportedClassVersionError。这事儿说大不大，但卡着就是让人烦。下面这套流程，基本能把这个坑给填平。

先看看系统中到底装了哪些Ja va

动手之前，得先摸清家底。几条命令就能把情况摸透：

ja va -version        # 看看当前默认的运行时版本
ja vac -version       # 看看默认的编译器版本
ls /usr/lib/jvm/     # 瞅一眼所有装好的Ja va路径

这几步跑下来，冲突的源头基本就亮了——比如同时挂着Ja va 8和Ja va 11，但默认启动的是你不想要的那个。

不需要的老版本，果断卸掉

如果系统里有些Ja va版本已经彻底用不上，留着也只是添乱。用yum清理掉就行：

sudo yum remove ja va-<版本号>-openjdk*

举个例子，要是想拿掉Ja va 7：

sudo yum remove ja va-1.7.0-openjdk*

卸完后别忘了再用ja va -version确认一下，目标版本确实消失了。

多版本共存？alternatives帮你管好

CentOS自带了一个叫alternatives的工具，专门用来打理这种多版本并存的情况。用它可以很方便地切换默认版本。

先把各个版本的Ja va注册进去。以Ja va 8和Ja va 11为例，需要分别对ja va和ja vac执行注册命令：

sudo alternatives --install /usr/bin/ja va ja va /usr/lib/jvm/ja va-1.8.0-openjdk/bin/ja va 1
sudo alternatives --install /usr/bin/ja vac ja vac /usr/lib/jvm/ja va-1.8.0-openjdk/bin/ja vac 1
sudo alternatives --install /usr/bin/ja va ja va /usr/lib/jvm/ja va-11-openjdk/bin/ja va 2
sudo alternatives --install /usr/bin/ja vac ja vac /usr/lib/jvm/ja va-11-openjdk/bin/ja vac 2

注册完成后，切换版本就很简单了：

sudo alternatives --config ja va
sudo alternatives --config ja vac

系统会列出所有已注册的版本，输入对应的编号就能把默认版本切过去。

更灵活的方式：手动配环境变量

如果想让不同用户或不同项目用各自的Ja va版本，环境变量是更好的选择。

要全局配置（影响所有用户），就编辑/etc/profile文件，加入类似下面的内容：

export JA VA_HOME_8=/usr/lib/jvm/ja va-1.8.0-openjdk
export JA VA_HOME_11=/usr/lib/jvm/ja va-11-openjdk
export PATH=$JA VA_HOME_8/bin:$PATH   # 默认用Ja va 8

如果只想让当前用户生效，改~/.bashrc就行，内容一样。

要临时切版本，直接改环境变量：

export JA VA_HOME=$JA VA_HOME_11   # 切到Ja va 11
export PATH=$JA VA_HOME/bin:$PATH
source ~/.bashrc                 # 让配置生效

跑一下ja va -version确认是否已经切换成功。

版本冲突的终极解法：容器化

如果应用的Ja va版本要求非常严格（比如非Ja va 17不可），那最好的方式就是用Docker把环境彻底隔离起来。宿主机的Ja va版本再乱，也影响不到容器内部。

一个简单的Dockerfile示例：

FROM centos:latest
RUN yum install -y ja va-17-openjdk-devel
ENV JA VA_HOME=/usr/lib/jvm/ja va-17-openjdk
ENV PATH=$JA VA_HOME/bin:$PATH

构建运行：

docker build -t my-ja va-app .
docker run -it my-ja va-app ja va -version

容器里用的就是指定的Ja va 17，跟宿主机完全脱钩。

构建工具带来的依赖冲突，也别忘了

有时候冲突不是来自系统，而是Ma ven或Gradle里的依赖打架。解决方式也不复杂：

Ma ven的话，在pom.xml里显式指定依赖版本，同时排除掉那些有冲突的传递依赖：

    com.example
    example-artifact
    1.0.0
    
        
            org.conflicting
            conflicting-library
        
    

Gradle用户则在build.gradle里这样写：

dependencies {
    implementation('com.example:example-artifact:1.0.0') {
        exclude group: 'org.conflicting', module: 'conflicting-library'
    }
}

这一套下来，因为依赖库版本不对付导致的编译冲突基本能搞定。

说到底，解决Ja va版本冲突没有银弹，不同场景选不同手段就好。多版本并存用alternatives，要求严格直接上容器，构建工具出问题就从依赖管理入手。理清楚思路，操作起来其实没那么复杂。