概述
使用Maven可以很方便地管理项目中的依赖，但是由于Maven中的依赖具有传递性，会导致我们项目中的错综复杂，最典型的就是由依赖冲突发生的ClassNotFoundException和NoSuchMethodException
什么是依赖冲突
当项目中引用了某个jar包的不同版本，就会发生依赖冲突。假设项目A的依赖关系如下：
A
├── B
│ └── C
│ └── D 2.0
└── E
└── D 1.0
A中间接依赖了两个D，版本分别是D2.0跟D1.0，路径分别是A->B->C-D2.0,A->E->D1.0，此时就产生了依赖冲突，因为项目在打包运行的时候，只能使用一个D依赖，即只能使用D2.0或D1.0其中之一
Maven 如何解决依赖冲突
知道什么是依赖冲突后，我们来看看Maven是如何解决该问题的。在Maven的依赖处理机制中，使用最近定义(nearest definition)原则来处理包冲突问题，如果项目最终依赖于多个相同artifactid的多个版本，则会使用依赖树中最先定义的那个版本（广度优先）
因为A->E->D1.0的依赖路径比A->B->C->D2.0短，所以最终会使用D1.0作为项目的依赖版本
依赖冲突产生的问题
还是以上面的依赖关系为例
A
├── B
│ └── C
│ └── D 2.0
└── E
└── D 1.0
假设D1.0跟D2.0都有类A，两个版本中的方法如下
D1.0 D2.0
__________________ __________________
| classA | | classA |
|__________________| |__________________|
|+ method1() | |+ method1() |
| | |+ method2() |
|__________________| |__________________|
此时，当C调用了calssA中的method2()方法，就会报NoSuchMethodException，因为此时依赖的版本为D1.0，D1.0中并没有该method2()方法
NoSuchMethodException 问题解决
知道了NoSuchmethodException产生的原因后，解决的方法很简单，只要将D1.0的依赖改为D2.0就可以了，可以在A的pom文件中加入D2.0依赖，这样项目的依赖树就变为
A
├── B
│ └── C
│ └── D 2.0
└── E
| └── D 1.0
│
└── D 2.0
此时，依赖路径A->D2.0最短，根据Near Definition原则，项目的依赖版本就变为D2.0了
除了上面的方法外，还可以在E的pom使用exclusion，移除掉D1.0，这样项目中就只剩D2.0了
<dependency>
<groupId>xxx</groupId>
<artifactId>E</artifactId>
<version>xxx</version>
<exclusions>
<exclusion>
<artifactId>D</artifactId>
<groupId>xxx</groupId>
</exclusion>
</exclusions>
</dependency>
依赖隔离
使用D2.0替换D1.0的前提是D做了向下兼容，假设升级了D2.0后，并不能兼容原先的D1.0，那么此次升级就有可能引发别的问题，那么有什么方法能使D1.0跟D2.0同时存在呢，即模块E还是使用D1.0依赖，模块C用2.0依赖。答案就是依赖隔离技术
由于依赖隔离设计到的东西比较多，这里不做介绍，之后会额外写一篇文章介绍依赖隔离，感兴趣的可以关注我的公众号：huangxy，文章写好会第一时间推送，也可以扫下方二维码关注
参考
