一般在项目依赖比较复杂或者java运行的环境有问题时同一类型的jar包有不同版本存在,本质上说是JVM找不到某个类的特定方法,也就是说JVM加载了错误版本的类。

 

出现该问题的情形一般有一下几种:

 

   1、项目依赖复杂。不使用maven管理项目依赖时更容易出现该问题。

              处理的方法是: 如果使用maven,执行maven dependency:tree 人工排除

 

   2、运行环境问题。一般java web程序都运行在容器中,tomcat等。如果容器中已经存在了某个版本的jar包并已经加载了某些类,而web项目中依赖了不同的版本。

              处理方法:保证使用“干净”的容器运行程序,或者在maven依赖中将容器中已经存在的依赖设置为<scope>provided</scope>

   3、依赖的jar包在不修改namespace的情况下打包了某些他的依赖类。比如:junit 打包了org.hamcrest的一些类。

 

   4、依赖名称的不同,比如Google Collections 和 Guava,其实是一个东西。

 

要彻底解决这个问题,首先想到的是不让有冲突的jar包上线。

 

这里有我写的一个简单的工具:

https://code.google.com/p/jarconflict/

 

mvn install 到本地后,执行 mvn jarconflict:check 就可以在web工程中检查所有jar包中的class,如果发现重复就报错。

 

如果线上已经出现该问题,需要进行定位,解决的方法有以下几种:

1、挂jconsole、jvisualvm、jinfo等工具到启动的java进程,查看jvm的classpath。但这种方法有个局限:如果是web程序运行在tomcat等容器下,容器有自己的classloader结构,会加载web工程目录/WEB-INF/lib/下面所有的jar包,jinfo等工具无能为力

2、如果是web工程,可以将下面的jsp以 class_location.jsp 放到出现问题的web工程下:

 

 

然后访问 http://你的web程序的地址/class_location.jsp?className=需要检查的类名  检查该类的jar包路径。

例如访问XXX/class_location.jsp?className=net.spy.memcached.MemcachedClient

显示:net.spy.memcached.MemcachedClient location: /data/develop/repository/spy/memcached/2.3.1/memcached-2.3.1.jar

 

 

需要注意的是,java.* 下面的所有的类,是无法检测的。

 3、跟踪jvm类加载。在java启动参数中添加 -XX:+TraceClassLoading  -XX:+TraceClassUnloading参数,打印jvm的class loading信息


 

 

 -EOF-

 

 

 

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐