记一次类污染问题定位

今天项目线上测试出现了一个问题,一个War包启动失败(使用Jetty Runner启动),报的错是: Caused by:
java.lang.NoSuchMethodError: org.apache.cxf.transport.AbstractTransportFactory.<init>(Ljava/util/List;Lorg/apache/cxf/Bus;)V

这个我一看第一反应是肯定是某个依赖的jar包的版本弄错了。我看了一下AbstractTransportFactory这个类,是属于cxf-api里面的(我们用的版本是2.6.2), 于是我就去Jetty解压出来的war包的目录下的lib里面看,发现里面有,cxf-api(2.6.2), cxf-core(3.1.12)等几个jar包,那就奇怪了,cxf-api的版本是对的,我甚至把它解压出来反编译了AbstractTransportFactory类来看,也是没有问题的。百思不得其解。后来同事Jun Gong提醒我说既然它报了那个错,就必定是加载到了错误的class,你这样看是看不出来的,你要把JVM加载的所有的class都打印出来,看最终加载到哪个包里面的类。

Google了一下,我在程序的java启动脚本里面加上了 -verbose:class
这个参数java -verbose:class ...... 1 > /tmp/test.log &
, 1 > /tmp/test.log
是把输出重定位到一个临时文件里面,方便查询。当我查看的时候,居然看到AbstractTransportFactory这个类是从cxf-core(3.1.12)这个包里面加载进来的,就是说cxf-api(2.6.2)和cxf-core(3.1.12)这两个包里面都有FQN(Full Qualified Name)为 org.apache.cxf.transport.AbstractTransportFactory
的类!!而JVM加载的时候,根据FQN去加载,如果加载到cxf-core里面的,就不会再加载cxf-api里面的,而我们需要的是cxf-api里面的!关键问题是,我们根本没法控制JVM的加载顺序!这就是为什么这个问题之前没有发生,属于概率问题。

虽然最后找到了Root Cause,主要还是我们项目里面各种依赖没有统一和处理好各种依赖关系。但我想吐槽一下,活该cxf这项目半死不活,居然在两个包里面用同一个FQN,这实在是bad practice的典范了。

原文 

http://ericcenblog.com/2018/07/31/ji-yi-ci-lei-wu-ran-wen-ti-ding-wei/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 记一次类污染问题定位

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址