资讯

精准传达 • 有效沟通

从品牌网站建设到网络营销策划,从策略到执行的一站式服务

Java类加载器与类冲突怎么解决

这篇文章主要介绍了Java类加载器与类冲突怎么解决的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇Java类加载器与类冲突怎么解决文章都会有所收获,下面我们一起来看看吧。

成都网络公司-成都网站建设公司成都创新互联公司十年经验成就非凡,专业从事做网站、成都网站制作,成都网页设计,成都网页制作,软文推广广告投放等。十年来已成功提供全面的成都网站建设方案,打造行业特色的成都网站建设案例,建站热线:13518219792,我们期待您的来电!

在同一个项目中,包含了一个类库的两个不同版本

这个时候,可能就会遇到奇怪的问题

  • 代码的逻辑不符合预期

  • 出现NoSuchMethodError

  • ...

先说结论,出现这些问题,不用怀疑,一定是当前使用的class版本和你预期的不一致。

这里我们以 apache 的 commons-codec类库来分析问题场景。

在实现一个功能的时候,你通过maven引入了这个库的依赖:

commons-codec

commons-codec

1.10

此时,在代码里使用了类库内处理Base64的一个类,有一个这样的实现

public static byte[] decodeBase64(String base64String) {
   return (new Base64()).decode(base64String);
}

然后没多久,系统中新增其它的功能,和其他系统对接的时候,引入了一个依赖。当我们高高兴兴的完成了任务,提交代码时,某天会遇到QA提了一个问题,XX功能现在不可用。

什么情况,WTF?

然后重跑功能,果不其然。什么情况。原来我们之前使用的commons-codec-1.10版本,并没有被使用,而是使用了com.springsource.org.apache.commons.codec-1.3.0版本。

什么情况?

我们在接入其他系统的时候,引入了一些依赖,而这其中他会依赖一个


  org.apache.commons
  com.springsource.org.apache.commons.httpclient

而他,会把上面的com.springsource.org.apache.commons.codec-1.3.0引进来。

此时,系统中就会有两个关于commons-codec的包。

而旧版本的对应Base64的类,只支持传入一个数组,不支持String

难道Maven这么傻,不会解决一下?

他会根据引入的版本,使用的maven的版本,从而选择是根据依赖声明的前后顺序或者是nearest来使用。但这个解决不了我们上面的问题,因为maven对于同一个groupId和artifactId才会使用上面这个依赖机制,所以相同的groupId和artifactId的依赖,会直接忽略,最终只使用一个。依赖树上可以看了出来:

Java类加载器与类冲突怎么解决

看上面的提示omitted for duplicate。而上面关于codec的依赖,是因为artifactId被换成了org.springsource.org.apache.commons,这样maven的机制就不会生效,导致项目里出现了两个codec的jar。而且,codec.jar虽然对于org.springsource这个指定的,虽然artifactId是这个,但里面的包名还是一样样的org.apache.commons,所以是相同于两个一模一样的Jar,只是版本不同。

这个时候,到了类加载器上场的时候了。类加载器在加载类,初始化的时候,会需要加载当前class依赖的类,此时,由于依赖低版本codec的class先被加载,从而导致低版本的codec被加载。

等后面再需要codec的地方又需要类的时候,此时虽然WebappClassloader可以子优先加载,对于不同的应用进行资源隔离,但是对于同一个应用内的相同package的类,是不会重复加载的。此时,有相同的请求到来时,从已经加载的资源中找到了低版本的codec,就直接用了,而这个类里没有我们要调用的方法,就出现了熟悉的NoSuchMethodError。

解决

问题了解清楚了,那该怎么解决呢,引入一个依赖的时候,总不能一个个的去查看jar的pom声明。

出现了上述问题时,如果不是使用maven管理依赖的,像之前SSH那种一下添加一堆jar到lib目录的时候,确定了对应的问题jar后,直接删除就好,简单直接。

如果是用maven管理依赖,就需要了解,是请把这小子带到这儿的。这个时候,使用maven的命令工具:

mvn dependency:tree

然后把结果生成到一个文件中,就可以查看引入冲突的jar是谁引进来的,查明真相后,就把依赖排除出去,

类似这样:


   com.xxx
   xxx
   1.0.4
   


   org.apache.commons
   com.springsource.org.apache.commons.codec



关于“Java类加载器与类冲突怎么解决”这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对“Java类加载器与类冲突怎么解决”知识都有一定的了解,大家如果还想学习更多知识,欢迎关注创新互联行业资讯频道。


分享文章:Java类加载器与类冲突怎么解决
网页链接:http://cdkjz.cn/article/iegjdj.html
多年建站经验

多一份参考,总有益处

联系快上网,免费获得专属《策划方案》及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

大客户专线   成都:13518219792   座机:028-86922220