一般在项目依赖比较复杂或者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-