maven jar包冲突解决方法,工具,以及原理

发布时间:2021年03月04日 阅读:3774 次

前言

昨天打包更新应用,出现上传文件错误,查看日志发现报错

ERROR:java.lang.NoSuchMethodError: org.apache.http.util.Args.containsNoBlanks(Ljava/lang/CharSequence;Ljava/lang/String;)Ljava/lang/CharSequence;
        at org.apache.http.HttpHost.<init>(HttpHost.java:80) ~[httpcore-4.4.11.jar:4.4.11]
        at org.apache.http.client.utils.URIUtils.extractHost(URIUtils.java:370) ~[httpclient-4.3.2.jar:4.3.2]
        at org.apache.http.impl.client.CloseableHttpClient.determineTarget(CloseableHttpClient.java:92) ~[httpclient-4.3.2.jar:4.3.2]
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:159) ~[httpclient-4.3.2.jar:4.3.2]
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:136) ~[httpclient-4.3.2.jar:4.3.2]
        at com.datacenter.jeefp.common.http.HttpClientUtil.doHttpGet(HttpClientUtil.java:181) ~[jeefp-single-1.2.8.jar:?]
        at com.datacenter.jeefp.common.http.HttpClientUtil.doHttpGet(HttpClientUtil.java:115) ~[jeefp-single-1.2.8.jar:?]
        at com.datacenter.jeefp.modules.edi.common.edi.EdiGetSource.getEdiCostcoSearch(EdiGetSource.java:630) ~[jeefp-single-1.2.8.jar:?]
        at com.datacenter.jeefp.modules.edi.service.impl.OrdersEdiMethodServiceImpl.checkHaive(OrdersEdiMethodServiceImpl.java:135) ~[jeefp-single-1.2.8.jar:?]
        at com.datacenter.jeefp.modules.edi.service.impl.OrdersEdiMethodServiceImpl$$FastClassBySpringCGLIB$$22a9099d.invoke(<generated>) ~[jeefp-single-1.2.8.jar:?]
        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) ~[spring-core-5.1.6.RELEASE.jar:5.1.6.RELEASE]
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738) ~[spring-aop-4.3.11.RELEASE.jar:4.3.11.RELEASE]
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) ~[spring-aop-4.3.11.RELEASE.jar:4.3.11.RELEASE]
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:294) ~[spring-tx-5.1.6.RELEASE.jar:5.1.6.RELEASE]

初步分析是httpclient版本问题

改了版本号4.3.6

再次打包更新,OK了(其实本质问题并没有解决,下文具体分析)

今天再次打包更新,错误重现

下文就涉及到maven jar包问题了

大家在项目中肯定有碰到过Maven的Jar包冲突问题,经常出现的场景为:
本地运行报NoSuchMethodErrorClassNotFoundException。明明在依赖里有这个Jar包啊。怎么运行不了!?
项目中明明定义着某个jar包版本为2.0.2,怎么打包之后变成2.5.0了!?
A项目引xxx.jar包运行好好的,B项目同样引入xxx.jar后,运行报错了。。是B项目有问题,还是xxx.jar包有问题!?
本地环境和测试环境运行的好好的,到了生产就报一堆NoSuchMethodError,是我人品有问题还是生产环境有问题!?
这样的问题如果不熟悉maven依赖机制的同学排查起来,估计挺头痛的。
而且maven依赖结构不好的项目,在引入新的Jar包时的风险也是巨大的。小则影响性能,大则引起生产发布和运行时异常。
其实以上问题的根源都来自于Maven的Jar包冲突和使用不当的依赖传递。以下3个内容:

依赖传递原则

几乎所有的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版本的。

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包不向下兼容,或者新增了某些低版本没有的API才有可能导致这样的问题

定位冲突

IDEA提供了一个maven依赖分析神器:Maven Helper

image.png

用这个插件能很好的显示出项目中所有的依赖树和冲突

image.png

这里面红色高亮的部分,就表明这个Jar包有了冲突。选中这个jar包,可以看到这2个版本的冲突的来源。

上图的例子,表明httpclient这个Jar包,有2个传递依赖,分别为4.3.2版本和4.5.8版本。冲突的描述为:

omitted for conflict with 4.5.8 由于与4.3.2版本冲突而被省略

具体的层级在右边也一目了然了,所以maven最终根据最短路径优先原则选择了4.3.2版本,4.5.8版本被忽略。

这时候有同学会问:本地环境我可以利用Maven Helper来定位,那么预生产或者生产环境呢。又没有IDEA,如何定位冲突的细节?

image.png

其实mvn命令行一样好用。非常清晰明确。

解决Jar包冲突的几个实用技巧

排除法

image.png

还是上面的那个例子,现在生效的是4.3.2,如果想生效4.5.8。只需要在4.3.2上面点exclude就行了。


版本锁定法

如果很多个依赖都传递了Jar包A,涉及了很多个版本,但是你只想指定一个版本。用排除法一个个去exclude太麻烦,而且exclude在pom文件中也会体现,太多的话,也影响代码整洁和阅读感受。

这时候需要用到版本锁定法

何谓版本锁定法?公司的项目一般都会有父级pom,你想指定哪个版本只需要在你项目的父POM中(当然在本工程内也可以)定义如下:(还是举上个例子,指定4.3.2版本

<dependencyManagement>
   <dependencies>
      <dependency>
         <groupId>org.apache.httpcomponents</groupId>
         <artifactId>httpclient</artifactId>
         <version>4.3.2</version>
      </dependency>
   </dependencies>
</dependencyManagement>

锁定版本法可以打破2个依赖传递的原则,优先级为最高

锁定版本后,依赖树为:

image.png

都统一变成4.3.2,锁定版本有一个好处:版本锁定并不排除Jar包,而且显示的把所有版本不一致的Jar包变成统一一个版本,这样在阅读代码时比较友好。也不用忍受一大堆的exclude标签。

如何写一个干净依赖关系的POM文件

我本人是有些轻度代码洁癖的人,所以即便是pom文件的依赖关系也想干净而整洁。如何写好干净的POM呢,作者认为有几点技巧要注意:

最后

其实庞大的项目依赖传递也一定多。但是不管多复杂的依赖关系,看到不要害怕。就这么几条原则,细心的去分析,所有的依赖都有迹可循。

这些传递依赖如果管理的好,能让你的维护成本大大降低。如果管不好,这群野孩子每一个都可能是引发下一个NoSuchMethodError的导火索。


Tag:JAVA jar包冲突 mavaen依赖关系 导致NoSuchMethodError问题 maven依赖传递规则
相关文章