在测试脚本编写和应用部署时,经常遇到的一
个问题是
:java.lang.NoSuchMethodError。这个问题产生的根本原因是运行时应用加载的jar包版本不是应用代码真正需要的版本。要解决这个问题,就要让应用加载真正“HasSuchMethod"的类所在的jar包。解决这个问题,我把它归纳为以下几步:验证加载内容、查找包含该类的jar包、查找应用适用的jar版本、查看出错应用加载的jar包位置、替换错误jar包版本到需要的版本。
验证加载内容
通常,发生了NoSuchMethodError,在报错中我们可以查看到应用真实需要的方法和方法签名,例如如下的报错:
java.lang.NoSuchMethodError: com.taobao.eagleeye.EagleEye.rpcClientRecv(Ljava/lang/String;I)V
表明应用需要的是EagleEye类中的包含方法签名如:void rpcClientRecv(String str,int i)的方法。知道了这一点,我就自然需要去看一下应用中实际加载的EagleEye是什么样的情况,rpcClientRecv方法的签名是什么样子的。
要得到这些内容,可以用两个工具来获取,1是clas
sdump工具,它通过Serviceability Agent技术在运行时dump指定的类的字节码文件。2是jdgui,这是使用得最多的反编译工具,它可以把clas
sdump工具dump出来的字节码文件反编译成java代码,可以更直观得查看应用中加载的类是什么样子。
clas
sdump工具的使用:
命令:java -classpath
".:/opt/taobao/java/lib/sa-jdi.jar" sun.jvm.hotspot.tools.jcore.ClassDump
16528
其中-classpath把sa-jdi的jar包加入到classpath中,ClassDump 是执行字节码文件dump的main方法入口类,16528是目标进程的pid,可以用jps命令得到。
这样,ClassDump会把当前加载的所有Java类都dump到当前目录下,如果有全限定名相同但内容不同的类同时存在于一个Java进程中,那么dump的时候会有覆盖现象,实际dump出来的是同名的类的最后一个。
如果需要指定被dump的类的范围,可以自己写一个过滤器,在启动ClassDump工具时指定-Dsun.jvm.hotspot.tools.jcore.filter=filterClassName,如果需要指定dump出来的Class文件的存放路径,可以用-Dsun.jvm.hotspot.tools.jcore.outputDir=path来指定,path替换为实际路径。
对于上面讲的
例子,我们只需要
EagleEye类的内容,那么,就可以写一个FilterClass类来进行dump的过滤,写这个过滤类,需要实现sun.jvm.hotspot.tools.jcore.ClassFilter,具体实现如下图所示,InstanceKlass对应于HotSpot中表示Java类的内部对象,我们只要过滤类名以com/taobao/eagleeye的类就好。
![](https://img-my.csdn.net/uploads/201302/02/1359803415_9851.png)
写好了这个类之后,编译,把这个类的class文件放到要执行ClassDump命令的目录下,执行时增加如下参数:-Dsun.jvm.hotspot.tools.jcore.filter=MyFilter,ClassDump就会在当前目录dump出com.taobao.eagleeye.EagleEye类的字节码。
然后使用jd-gui,jd-gui是一个绿色工具,直接打开字节码文件,可以看到rpcClientRecv方法,这里就可以看到,实际上当前jvm加载的是一个没有参数的rpcClientRecv方法。
![](https://img-my.csdn.net/uploads/201302/02/1359803456_3320.png)
查找包含该类的jar包、查找应用适用的jar版本
确认了当前出现错误的应用中确实加载了不符合要求的类之后,就需要去看一下,这个类是从哪里来的,在哪个jar包中。做这件事情比较简单,只需要去eclipse中执行ctrl+shift+t,输入类名,就可以看到当前eclipse的工程中依赖的各个版本的包含这个类的jar包。接下来你可以把各个版本的类都打开,检查这些版本的jar包中是否有符合要求的方法,即方法签名符合rpcClientRecv(Ljava/lang/String;I)V的方法。方法签名识别:其中L开头,;结尾的字符串标识了一个对象类型,这里的第一个参数是java.lang.String类型,第二个参数是int类型,V表示void类型返回。详细的jvm中字段类型和方法签名表示见下图:
![](https://img-my.csdn.net/uploads/201302/02/1359803496_8892.png)
通过这个步骤,我们知道了实际上我们的应用需要什么版本的jar包,那么,接下来自然就会想要知道应用当前加载的是什么版本的jar包,又是在哪里加载进来的。
查看出错应用加载的jar包和jar包位置
在这个步骤,要想知道应用加载的是jar包的什么版本,需要使用jvm类加载跟踪器这个工具,这是一个基于java agent、instrument的,用于排查jar包冲突、类冲突、类版本冲突、NoClassDefFoundError、ClassNotFoundException、NoSuchMethodError 等类加载相关问题的辅助工具。这个工具的能够定时得把新加载入虚拟机类个jar包等数据输出到指定的html文件中。
工具的使用方式是:首先,下载得到
jvminspect.jar;其次,修改目标应用的jvm配置,在jvm参数上增加如下的配置:
JAVA_OPTIONS=$JAVA_OPTIONS -javaagent:jvminspect.jar=outputfile=jvm.inspect.output,flushIntervalSecond=300 -DHtmlFlusher.enableHyperlink=false;其中
jvminspect.jar是下载得到的工具jar包,
jvm.inspect.output是输出的文件地址,
flushIntervalSecond参数指定的是定时刷新的时间间隔。增加了这个参数之后重启,就可以在
jvm.inspect.output文件中查看这个jvm进程加载类的情况了。
我们关心的是出现NoSuchMethodError 所在的类,在这个例子中,这是com.taobao.eagleeye.EagleEye类,在输出的文件中我们可以看到这个类被jvm从jar包的哪个版本中加载,jar包的物理位置等信息。
![](https://img-my.csdn.net/uploads/201302/02/1359803545_8510.png)
知道了这些信息,我们就很清楚得能够确定问题的原因。
替换错误jar包版本到需要的版本
知道应用在那里加载了不期望被加载的jar包,我们就可以着手让应用把需要加载的正确版本包加载进来。不同的场景可以做不一样的操作,比如应用的war包中本身加载了错误版本的jar包,那你需要做的是修改应用的pom文件进行重新打包,把正确的jar包依赖到war包中;如果是由于某些环境的原因,classpath中存在了两个不同版本的jar包,那你就可以根据前面几步得到的信息,把错误版本(导致应用报NoClassDefFoundError、ClassNotFoundException、NoSuchMethodError等错)的版本删除,留下应用代码实际上依赖的jar包。