来源 | 草捏子,作者 | 草捏子
之前有了解到Maven可以依赖调解,即当包版本不一致时,会根据一定规则选择相应的包来加载,从而避免冲突。当时不解的是既然Maven都能解决冲突,为何还经常听到“发生了依赖冲突”,冲突不是解决了吗,还存在什么问题呢?直到这周在工作中自己遇到了,就明白是咋回事了。下面先从我的实际经历说起。
1. Maven依赖冲突经历
我在Y模块中,写了一个
Encryptor
类,主要是使用了
DigestUtils
、
MessageDigest
、
HmacUtils
等类对字符串进行加密(下面代码是随便写的,只表示使用到了这些类),如下:
执行单元测试可以正常运行。但是当整个应用启动时,则会报
IllegalAccessError
错误。
应用启动报错IllegalAccessError
在Y模块下的单元测试运行时不会报错,但是当整个应用启动,作为程序入口的X模块,调用Y模块中的
Encryptor
时,发生了
IllegalAccessError
报错。根据图中的具体报错信息,是说没有权限访问
getSha256Digest
方法,我Ctrl+B点进
getSha256Digest
方法查看,如下:
getSha256Digest是public
getSha256Digest
方法是
public
的访问级别,我一脸懵。由于这个方法很简单,既然报错,那我就索性不用了,换成下面这种写法。
又报错了,好吧,真是躲不过了!报错如下:
应用启动报错ClassNotFoundException
这次报的是
ClassNotFoundException
,
HmacUtils
这个类找不到。可是我Ctrl+B进去,这个类好好的就在那里啊。这时我才把注意力集中在思考是不是发生了Maven依赖冲突。我打开pom.xml,用Dependency Analyzer查看,果然我使用的
commons-codec
包发生了冲突。
X模块的依赖树
在Y模块中,依赖关系:Y -> B -> C -> commons-codec-1.10。而在X模块中,引用了A包:X -> A -> commons-codec-1.6,也引用了Y模块:X -> Y -> B -> C -> commons-codec-1.10。可见
commons-codec
包有两个版本1.6和1.10,所以Maven会进行依赖调解,第一原则是“路径最短者优先”,自然只会使用1.6版本的包。而我再去查看1.6的包下,
getSha256Digest
方法是
private
的访问级别,
HmacUtils
这个类也不存在。解释了之前的报错。解决该冲突,通过排除依赖便能解决了,将A包下的
commons-codec
排除,如下:
排除后,这时将只有1.10版本的包,程序也可以正常运行了。
2. 为什么需要Maven依赖调解
问题已经解决了,大家是不是也明白了,为什么依赖冲突会常导致发生
NoClassDefFoundError
、
NoSuchMethodException
、
IllegalAccessError
等错误。虽然Y模块在编译时,由于引入了
commons-codec 1.10
能正常编译,但是在运行时,由于依赖冲突,只加载了1.6版本的包,所以不能正常运行。
注意:代码的编译仅仅是编译当前的代码。编译成功后,最后能否正常运行,还要取决于运行时的环境是否等同或兼容编译时环境。
下面我们想想为什么需要Maven依赖调解,如果不调解行不行。
当使用Maven的过程中,如果同时引入了groupId和artifactId相同而version不同的包时,Maven会认为发生了依赖冲突,将进行依赖调解,通过两个原则决定使用哪个版本的包:第一原则,路径最近者优先,如前文。如果路径相同,则使用第二原则,在pom中第一声明者优先。而当我们在点击Run运行时,classpath中将只会有一个明确版本的包。
思考一下。Java在运行时,是否能引入版本不同的包。其实这个问题是在问,java命令的classpath参数中能不能有多个版本不同的包,当然是可以的。classpath参数是用于指示JVM如何搜索class文件,当你在classpath中指定的路径下有多个版本不同的包,JVM都会去jar包下搜索class文件进行加载,而至于class能不能成功加载,则在于ClassLoader的逻辑,当同名类被加载时,则不会再被加载,即同一个类只会被加载一次。这也意味,当有多个版本不同的包时,包在classpath中的顺序,决定了哪个包中的类能先被加载。而这样具有不确定性。因为在生产环境下通常使用
shell
命令将jar包拼接:
不同环境下得到的jar包顺序可能是不同的。而Maven依赖调解将使得只有一个明确版本的包参与构建,从而避免不确定性。
3. 排查在线问题的利器-Arthas
Arthas,早有听说,但一直未使用过,这次我尝试了下,觉得确实可以,安利下。对于前文说的依赖冲突情况,当发生
IllegalAccessError
报错时,可以通过Arthas直接查看运行情况下的
DigestUtils
。我们把代码变为最初的情况,且在Main类中加个死循环,为了让程序不死掉,以通过Arthas观察。
打开Arthas,连接上我们的程序(可以通过官方教程学习),然后通过
sc
命令查看
DigestUtils
:
可以从
code-source
中清晰地查到
DigestUtils
是哪个包下的Class,这时就该意识到发生了依赖冲突问题。
而通过
jad
命令,还能反编译,在线看代码。好用!
4. 参考
- Arthas 实战,助你解决同名类依赖冲突问题(https://www.cnblogs.com/goodAndyxublog/p/12424734.html)
- Maven依赖冲突问题原理简析(https://blog.csdn.net/qq_27529917/article/details/79741607)
- 重新看待Jar包冲突问题及解决方案(http://www.yangbing.club/2017/07/15/solution-for-jar-conflicts/)