大家在项目中肯定有碰到过Maven
的 Jar 包冲突问题,经常出现的场景为:
本地运行报NoSuchMethodError
,ClassNotFoundException
。明明在依赖里有这个 Jar 包啊。怎么运行不了!?
项目中明明定义着某个 jar 包版本为2.0.2
,怎么打包之后变成2.5.0
了!?
A 项目引 xxx.jar 包运行好好的,B 项目同样引入 xxx.jar 后,运行报错了。。是 B 项目有问题,还是 xxx.jar 包有问题!?
本地环境和测试环境运行的好好的,到了生产就报一堆NoSuchMethodError
,是我人品有问题还是生产环境有问题!?
这样的问题如果不熟悉maven
依赖机制的同学排查起来,估计挺头痛的。
而且maven
依赖结构不好的项目,在引入新的 Jar 包时的风险也是巨大的。小则影响性能,大则引起生产发布和运行时异常。
其实以上问题的根源都来自于Maven
的 Jar 包冲突和使用不当的依赖传递。这篇文章我就好好分析下以下 3 个内容:
POM
文件几乎所有的 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 版本的。
假设我们项目中依赖了 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 包不向下兼容,或者新增了某些低版本没有的 API 才有可能导致这样的问题
IDEA 提供了一个maven
依赖分析神器:Maven Helper
用这个插件能很好的显示出项目中所有的依赖树和冲突
这里面红色高亮的部分,就表明这个 Jar 包有了冲突。选中这个 jar 包,可以看到这 2 个版本的冲突的来源。
上图的例子,表明cruator-client
这个 Jar 包,有 2 个传递依赖,分别为 2.5.0 版本和 4.0.1 版本。冲突的描述为:
omitted for conflict with 2.5.0. 由于与 2.5.0 版本冲突而被省略
具体的层级在右边也一目了然了,所以maven
最终根据最短路径优先原则选择了 2.5.0 版本,4.0.1 版本被忽略。
这时候有同学会问:本地环境我可以利用Maven Helper
来定位,那么预生产或者生产环境呢。又没有 IDEA,如何定位冲突的细节?
可以利用 mvn 命令来解决:
mvn dependency:tree -Dverbose
此处一定不要省略
-Dverbose
参数,要不然是不会显示被忽略的包的
其实 mvn 命令行一样好用。非常清晰明确。
排除法
还是上面的那个例子,现在生效的是 2.5.0,如果想生效 4.0.1 。只需要在 2.5.0 上面点exclude
就行了。
版本锁定法
如果很多个依赖都传递了 Jar 包 A,涉及了很多个版本,但是你只想指定一个版本。用排除法一个个去exclude
太麻烦,而且exclude
在 pom 文件中也会体现,太多的话,也影响代码整洁和阅读感受。
这时候需要用到版本锁定法
何谓版本锁定法?公司的项目一般都会有父级 pom,你想指定哪个版本只需要在你项目的父 POM 中(当然在本工程内也可以)定义如下:(还是举上个例子,指定 4.0.1 版本)
<dependencyManagement>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-client</artifactId>
<version>4.0.1</version>
</dependency>
</dependencyManagement>
锁定版本法可以打破 2 个依赖传递的原则,优先级为最高
锁定版本后,依赖树为:
都统一变成 4.0.1,锁定版本有一个好处:版本锁定并不排除 Jar 包,而且显示的把所有版本不一致的 Jar 包变成统一一个版本,这样在阅读代码时比较友好。也不用忍受一大堆的exclude
标签。
POM
文件我本人是有些轻度代码洁癖的人,所以即便是 pom 文件的依赖关系也想干净而整洁。如何写好干净的 POM 呢,作者认为有几点技巧要注意:
<dependencyManagement>
,来进行本项目一些依赖版本的管理,这样可以从很大程度上解决一定的冲突mvn dependency:analyze-only
命令用于检测那些声明了但是没被使用的依赖,如有有一些是你自己声明的,那尽量去掉mvn dependency:analyze-duplicate
命令用来分析重复定义的依赖,清理那些重复定义的依赖其实庞大的项目依赖传递也一定多。但是不管多复杂的依赖关系,看到不要害怕。就这么几条原则,细心的去分析,所有的依赖都有迹可循。
这些传递依赖如果管理的好,能让你的维护成本大大降低。如果管不好,这群野孩子每一个都可能是引发下一个NoSuchMethodError
的导火索。
觉得有用的话,请关注下我的公众号「元人部落」,作者坚持原创的内容技术分享,也有开源作品,欢迎关注
开源仓库为: https://gitee.com/bryan31
公众号一般周更,每次会分享一些实用的技术,陪你一起成长
关注后回复“资料”领取 50G 的视频资料,包括一套企业级微服务的视频教学
1
sonice 2020-08-31 12:00:05 +08:00
有用,感谢
|
2
shenmimu 2020-08-31 19:23:18 +08:00 1
还有可能会有 不同 jar 之内的同名类冲突
分析和排除依赖通常是在事后,最佳实践应该是使用 maven-enforcer-plugin 检查冲突,在引入时避免 |
3
wybhdxfx 2020-09-01 00:34:02 +08:00
感谢,学习了。
|
4
yumenawei 2020-09-01 09:22:20 +08:00
感谢分享
|
5
cheng6563 2020-09-01 09:32:42 +08:00
感觉还是 gradle 那种高版本优先好用些
|
6
cnzjl 2020-09-02 16:35:08 +08:00
感谢分享,收藏了
|