系统CPU飙高和频繁GC问题查询思路

处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。

对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信息，然后重启系统，尽快保证系统的可用性。这种情况可能的原因主要有两种：

• 代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢；
• 代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢；

相对来说，这是出现频率最高的两种线上问题，而且它们会直接导致系统不可用。另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用：

• 代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随机的；
• 某个线程由于某种原因而进入WAITING状态，此时该功能整体不可用，但是无法复现；
• 由于锁使用不当，导致多个线程进入死锁状态，从而导致系统整体比较缓慢。

对于这三种情况，通过查看CPU和系统内存情况是无法查看出具体问题的，因为它们相对来说都是具有一定阻塞性操作，CPU和系统内存使用情况都不高，但是功能却很慢。下面我们就通过查看系统日志来一步一步甄别上述几种问题。

1. 服务器CPU占用率高

 

首先我们可以使用top命令查看系统CPU的占用情况，如下是系统CPU较高的一个示例：

top 命令

 

可以看到，有一个Java程序此时CPU占用量达到了101.0%，此时我们可以复制该进程id 10241，并且使用如下命令查看呢该进程的各个线程运行情况：

 

top -Hp 10241

该进程下的各个线程运行情况如下

 

可以看到，在进程为10241的Java程序中各个线程的CPU占用情况，接下来我们可以通过jstack命令查看线程id为10362的线程为什么耗费CPU最高。需要注意的是，在jsatck命令展示的结果中，线程id都转换成了十六进制形式。可以用如下命令查看转换结果，也可以找一个科学计算器进行转换：

 

printf "%x\n" 10362

这里打印结果说明该线程在jstack中的展现形式为287a，通过jstack命令我们可以看到如下信息：

那么我们得到的就是一个线程的具体堆栈信息。如下是一个代码中有比较耗时的计算，导致CPU过高的线程信息：

 

这里可以看到，在请求ShippingTemplatesController的时候，由于该Controller进行了一个比较耗时的调用，导致该线程的CPU一直处于100%。我们可以根据堆栈信息，直接定位到ShippingTemplatesController的97行，查看代码中具体是什么原因导致计算量如此之高。

 

 

总结 

　　以上，展示了一次比较完成的线上问题定位过程。主要用到的命令有: top 、printf 和 jstack

·

2：线上服务器频繁发生Full GC如何排查

相对来说，这种情况是最容易出现的，尤其是新功能上线时。对于Full GC较多的情况，其主要有如下两个特征：

• 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程
• 通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加。

1：查看JVM堆配置参数

     jinfo -flag <name> PID   

     jinfo -flag ThreadStackSize 18348，得到结果-XX:ThreadStackSize=256，即Xss为256K

2：linux下查看java虚拟机（JVM）GC情况

jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] 如下表示分析进程id为31736 的gc情况，每隔1000ms打印一次记录，打印10次停止，每3行后打印指标头部 jstat -gc -h3 31736 1000 10

3：导出堆栈的dump信息分析 

1，使用 jmap 命令生成 dump 文件，命令 jmap -dump:live,format=b,file=c:\dump\heap.hprof <pid>   比如：jmap -dump:format=b,file=before.hprof 28679和jmap -dump:live,format=b,file=after.hprof 28679来dump堆快照文件也是可以的，加上live表示只保存存活对象。 2，使用 JVM 参数获取 dump 文件       -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base       当OutOfMemoryError发生时自动生成 Heap Dump 文件。这可是一个非常有用的参数，因为当你需要分析Java内存使用情况时，往往是在OOM(OutOfMemoryError)发生时。 3，使用 jcmd 命令生成 dump 文件      jcmd <pid> GC.heap_dump c:\dump\heap.hprof

 

4: 使用Eclipse MAT工具分析对快照

很显然可以看到堆内存被对象DoctorInvitePictureManagerImpl占用了811.8M，就是它导致了内存泄漏。剩下的就需要业务同学排查代码了。