常见的Java问题排查方法

　　以下是Java应用在运行时常见的一些问题，总结了运行时黑盒方式的一些排查方法，也希望看到的同学能给予补充，无论是补充碰到的问题，还是补充解决方法。

　　类装载的相关问题

　　写过Java代码的同学估计都碰到过ClassNotFoundException/NoClassDefFoundError/NoSuchMethodException(还有一个常见的ClassCastException就不在这里说了)。

　　当碰到ClassNotFoundException/NoClassDefFound时，如果很确定这个class应该是从哪个路径装载的，则可以去相应的路径找下是否有对应的class文件存在，例如web应用通常会在*.war(ear)/WEB-INF/lib或classes目录下，对于lib下的jar包，可通过写个小脚本jar -tvf的方式找找;

　　如不确定class是从哪装载的，则可以先看看日志里是否有堆栈信息，如果有的话则可以看到具体是哪个ClassLoader实现在装载class，之后则可以通过www.grepcode.com或jar包反编译(推荐一个挺好用的反编译工具)看看具体是从哪装载的class;

　　如日志中没有，则可以用btrace来跟踪下抛出以上两个异常的堆栈信息，btrace脚本类似如下：

　　?

　　拿到堆栈信息后，可以继续使用上面的方法进行排查，在确认了class装载的位置后，则可将相应的class/jar加上即可。

　　这里还有个NoClassDefFoundError排查的case，感兴趣的话可以看看。

　　当碰到NoSuchMethodException时，通常是由于不存在需要的class版本或class版本冲突造成的，在这种情况下，可通过在启动参数上增加-XX:+TraceClassLoading，重启后在日志里看看此class是在哪load的，然后可以在对应的路径下用jar -tvf找找是不是有正确的版本的jar存在，通常可能会发现是版本冲突造成的，对于版本冲突的问题通常需要删掉有冲突的版本的jar，对于没有正确版本的，则需要用正确版本的jar替换掉(当然，这种通常还会出现一些恶心的问题，例如和容器/框架的jar冲突等)。

　　cpu us消耗高

　　当出现cpu us消耗高时，通常的排查方法如下。

　　从经验上来说，有些时候是由于频繁cms gc或fgc造成的(频繁的意思是差不多每次cms gc或fgc一结束后又立刻继续)，在gc log是记录的情况下(-Xloggc:)，可通过gc log看看，如果没打开gc log，可通过jstat -gcutil来查看，如是gc频繁造成的，则可跳到后面的内存问题 | GC频繁部分看排查方法。

　　如不是上面的原因，可使用top -H查看线程的cpu消耗状况，这里有可能会看到有个别线程是cpu消耗的主体，这种情况通常会比较好解决，可根据top看到的线程id进行十六进制的转换，用转换出来的值和jstack出来的java线程堆栈的nid=0x[十六进制的线程id]进行关联，即可看到此线程到底在做什么动作，这个时候需要进一步的去排查到底是什么原因造成的，例如有可能是正则计算，有可能是很深的递归或循环，也有可能是错误的在并发场景使用HashMap等，例如这里还有一段随即生成字符串的耗cpu的代码case。

原文转自：http://bluedavy.me/?p=445