故障现象总结分类
- Full GC次数过多；
- CPU过高;
- 不定期出现的接口耗时现象;
- 某个线程进入WAITING状态;
- 死锁;
对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信息，然后重启系统，尽快保证系统的可用性。这种情况可能的原因主要有两种：
-
代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢；
-
代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢；
相对来说，这是出现频率最高的两种线上问题，而且它们会直接导致系统不可用。另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用：
-
代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随* 机的；
-
某个线程由于某种原因而进入WAITING状态，此时该功能整体不可用，但是无法复现；
-
由于锁使用不当，导致多个线程进入死锁状态，从而导致系统整体比较缓慢。
对于这三种情况，通过查看CPU和系统内存情况是无法查看出具体问题的，因为它们相对来说都是具有一定阻塞性操作，CPU和系统内存使用情况都不高，但是功能却很慢。下面我们就通过查看系统日志来一步一步甄别上述几种问题。
我们进行线上日志分析时，主要可以分为如下步骤：
- 通过
top命令查看CPU情况，如果CPU比较高，则通过top -Hp <pid>命令查看当前进程的各个线程运行情况，找出CPU过高的线程之后，将其线程id转换为十六进制的表现形式，然后在jstack日志中查看该线程主要在进行的工作。这里又分为两种情况 - 如果是正常的用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU；
- 如果该线程是
VM Thread，则通过jstat -gcutil <pid> <period> <times>命令监控当前系统的GC状况，然后通过jmap dump:format=b,file=<filepath> <pid>导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码； - 如果通过
top命令看到CPU并不高，并且系统内存占用率也比较低。此时就可以考虑是否是由于另外三种情况导致的问题。具体的可以根据具体情况分析： - 如果是接口调用比较耗时，并且是不定时出现，则可以通过压测的方式加大阻塞点出现的频率，从而通过
jstack查看堆栈信息，找到阻塞点； - 如果是某个功能突然出现停滞的状况，这种情况也无法复现，此时可以通过多次导出
jstack日志的方式对比哪些用户线程是一直都处于等待状态，这些线程就是可能存在问题的线程； - 如果通过
jstack可以查看到死锁状态，则可以检查产生死锁的两个线程的具体阻塞点，从而处理相应的问题。
一般问题排查操作步骤
-
找到CPU利用率持续比较高的进程, 命令：top
-
找到CPU使用率较高的线程ID(TID)：
命令：ps p 16480 -L -o pcpu,pid,tid,time,tname,cmd
-
将获取的线程号（十进制数）转换成十六进制
printf “%x\n” 16498
结果：4072
结合进程号和线程号,利用jstack查到异常代码所在行
jstack -l <pid> | grep <thread-hex-id> -A 10命令显示出错的堆栈信息，如下图：jstack -l 16480| grep 0x4072 -A 10
-A 10参数用来指定显示行数，否则只会显示一行信息。