常见的Java问题排查方法

发表于:2013-04-10来源:homeAboutPhotosBlueDavy之技术b作者:bluedavy点击数: 标签:java
以下是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脚本类似如下:

  ?

1
2
3
4
5
6
7
8
9
10
11
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.*;
@BTrace public class Trace{
   @OnMethod(
       clazz="java.lang.ClassNotFoundException",
       method="<init>"
   )
   public static void traceExecute(){
        jstack(); 
   }
}

  拿到堆栈信息后,可以继续使用上面的方法进行排查,在确认了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