jar包冲突如何排查
大家在项目中肯定有碰到过Maven的Jar包冲突问题，经常出现的场景为：
项目中运行报NoSuchMethodError，ClassNotFoundException。明明在依赖里有这个Jar包啊。怎么运行不了！？
项目中明明定义着某个jar包版本为2.0.2，怎么打包之后变成2.5.0了！？
A项目引xxx.jar包运行好好的，B项目同样引入xxx.jar后，运行报错了。。是B项目有问题，还是xxx.jar包有问题！？
本地环境和测试环境运行的好好的，到了生产就报一堆NoSuchMethodError，是我人品有问题还是生产环境有问题！？
其实以上问题的根源都来自于Maven的Jar包冲突和使用不当的依赖传递。这篇文章我就好好分析下以下3个内容：
- 依赖传递的原则和产生Jar包冲突的原理分析
- 定位冲突以及解决Jar包冲突的几个简单技巧
- 如何写一个干净依赖关系的
POM文件
依赖传递的原则和产生Jar包冲突的原理分析
1) 依赖传递原则
几乎所有的Jar包冲突都和依赖传递原则有关，所以我们先说Maven中的依赖传递原则：
- 最短路径优先原则
假如引入了2个Jar包A和B，都传递依赖了Z这个Jar包：
A -> X -> Y -> Z(2.5)
B -> X -> Z(2.0)
那其实最终生效的是Z(2.0)这个版本。因为他的路径更加短。如果我本地引用了Z(3.0)的包，那生效的就是3.0的版本。一样的道理。
- 最先声明优先原则
如果路径长短一样，优先选最先声明的那个。
A -> Z(3.0)
B -> Z(2.5)
这里A最先声明，所以传递过来的Z选择用3.0版本的。
2) Jar包冲突的原理
假设我们项目中依赖了A和B两个Jar包。而A和B各自又有以下传递依赖
A -> X -> Z(2.0)
B -> X -> Y -> Z(2.5)
那最终系统中Z包就产生了冲突，2.0和2.5两个版本冲突。但是classpath中只会依赖一个版本的Z包。根据传递依赖的最短路径优先原则，最终依赖的应该是2.0版本。
如果Y包中用了Z包2.5版本中新的method时候，当运行到这段逻辑的时候。就会报NoSuchMethodError了。因为本来依赖的是2.5版本，但是因为Jar包冲突Maven选择了2.0版本，2.0版本中又没有这个新的method，导致出错。
但要注意的是，不是所有冲突都会引起运行异常。相反，大部分公司的项目都会有一些Jar包冲突，但其实没有造成运行时的问题。
这是因为很多传递依赖的Jar包，不管是2.0版本也好，2.5版本也好，都可以运行。
当出现jar包冲突时，一般建议采用高版本的jar包，因为高版本的jar在设计时一般会考虑向下兼容。只有高版本Jar包不向下兼容才有可能导致这样的问题。
定位冲突以及解决Jar包冲突的几个简单技巧
1）定位冲突
idea提供了个神器插件maven helper。安装好后可直接在图形化界面进行分析。安装好maven helper好后，在项目的父pom左下方可以看到Depencency Analysizer选项，点击，即可检索jar冲突情况，如下图所示：
2）解决冲突的常见方法
- 排除依赖法
- 锁定版本法
如果很多个依赖都传递了Jar包A，涉及了很多个版本，但是你只想指定一个版本。用排除法一个个去exclude太麻烦，而且exclude在pom文件中也会体现，太多的话，也影响代码整洁和阅读感受。这时候需要用到版本锁定法，何谓版本锁定法？公司的项目一般都会有父级pom，你想指定哪个版本只需要在你项目的父POM中(当然在本工程内也可以)定义如下：（还是举上个例子，指定4.0.1版本）
org.apache.curator
curator-client
4.0.1
注：锁定版本法可以打破2个依赖传递的原则，优先级为最高
补充：maven加载jar包的来源优先级，项目子module对应的jar包>本地仓库jar包>远程仓库jar包
如何写一个干净的pom文件
尽量在父POM中定义