Java依赖冲突高效解决之道

简介：由于阿里妈妈联盟团队负责业务的特殊性，系统有庞大的对外依赖，依赖集团六七十个团队服务及N多工具组件，通过此文和大家分享一下我们积累的一些复杂依赖有效治理的经验，除了简单技术技巧的总结外，也会探讨一些关于这方面架构的思考，希望此文能系统彻底的解决java依赖冲突对大家的困扰。

作者 | 澄江
来源 | 阿里技术公众号

一 概述

由于阿里妈妈联盟团队负责业务的特殊性，系统有庞大的对外依赖，依赖集团六七十个团队服务及N多工具组件，通过此文和大家分享一下我们积累的一些复杂依赖有效治理的经验，除了简单技术技巧的总结外，也会探讨一些关于这方面架构的思考，希望此文能系统彻底的解决java依赖冲突对大家的困扰。

二 依赖冲突产生的本质原因

要解决依赖冲突，首先要理解一下java依赖冲突产生的本质原因。

图1

以上图为例，目前阿里大部分java工程都是maven工程，此类工程从开发到上线要经历以下两个重要步骤：

1 编译打包

平时我们编写的应用代码，用maven编译应用代码时，maven只依赖第一级jar包(A.jar，B.jar，*.jar)既完成应用代码的编译，至于传递依赖的jar包(Y.jar，Z.jar)maven首先会对同名不同version的jar包进行依赖仲裁，然后依据仲裁结果下载对应的jar放到指定目录下(例如上图中Y.jar最终只会仲裁1.0或2.0一个版本，此处假定仲裁到2.0版本，Z.jar即便内容与Y.jar一致，但名称不一样所以不属于maven仲裁范畴)。

有一点需注意不同maven版本可能会有差异，这会导致有时本地环境和日常、预发打包不一致造成应用逻辑表现不一致的情况（说明一下这种情况还有其他一些原因会导致，不是说一定是maven版本不一致仲裁结果不一致导致的）。

2 发布上线

先明确一个概念，在JVM中，一个类型实例是通过它的全类名和加载它的类加载器（ClassLoader）实例来唯一确定的。所以所谓的“类隔离”，实际就是通过不同的类加载器实例去加载需要隔离的类来实现的，这样即便两个全类名完全相同但内容不同的类，只要他们的类加载器实例不同，就能在一个容器进程中共存，并且各自运行互不干扰。

发布启动容器时，不管是tomcat、taobao-tomcat还是PandoraBoot，还是其他容器， 首先都是用特定的类加载器实例先加载容器本身依赖的jar包，容器一般都会有多个类加载器实例，容器自身所依赖的jar包一般由专门的类加载器实例加载实现与应用包的绝对隔离，像Pandroa还有专门的类加载器实例加载淘系中间件避免中间件与应用类冲突，如下图所示：

容器内部依赖jar加载完成后，才轮到必然的一步：由某个应用ClassLoader实例(一般与容器类加载器实例不是一个)来加载编译打包阶段打出来的应用jar包及应用.class程序，这样容器才能运行业务，同时确保应用不会干扰容器的运行。

例如图1中，最终打出的应用包中Y.jar-2.0，Z.jar都有com.taobao.Cc.class类，但一个应用ClassLoader实例仅能加载V3或V2中一个版本的com.taobao.Cc.class类。

那到底会加载哪个版本的com.taobao.Cc.class类呢？答案是不一定，这个取决于容器应用类加载实现策略， 从以往遇到的情况看，tomcat&