CPU、内存过高排查

对于互联网公司，线上CPU、内存飙升的问题很常见（比如流量突然飙升）而作为程序员，基本上都是下面操作作为排查的步骤

常规操作

1.执行top命令，查看到底是哪个进程占用的CPU过高

可以看到java进程的PID为11391

2.查看java进程所有线程占用CPU的情况

top -Hp < PID >

此时的PID为线程的ID

3.线程ID转换16进制，堆栈信息展示的是十六进制的，所以需要把线程id转换成16进制

printf %x 11405

4.查看堆栈信息

jstack < 进程号 > | grep < 十六进制线程Id >

如果““VM Thread” os_prio=0 tid=0x00007f871806e000 nid=0xa runnable”，如果是“VM Thread”这就是虚拟机GC回收线程了

5.查看进程GC情况

jstat -gcutil < 进程号 > < 统计间隔毫秒 > < 统计次数 >

查看某进程GC持续变化情况，如果发现返回中FGC很大且一直增大

确认Full GC!

或者使用

jmap -heap < 进程ID >

查看一下进程的堆内从是不是要溢出了，特别是老年代内从使用情况一般是达到阈值(具体看垃圾回收器和启动时配置的阈值)就会进程Full GC

6.输出dump文件，借助工具查看程序实例个数

jmap -dump:format=b,file=filename < PID > 导出某进程下内存heap到文件中，通过jdk自带 visualvm 或者 mat 工具查看内存中有哪些对象

原因分析

1.内存消耗过大，导致FULL GC 次数过多

执行操作1-5

查看哪些线程在负责垃圾回收

通过jstat 命令监控GC，可以看到FULL GC的次数非常多

2.代码中有大量消耗CPU的地方

执行步骤1-4

通过堆栈信息就可以定位到是哪行代码耗CPU

3.由于锁使用不当，导致死锁

执行步骤1-4

如果有死锁，会直接提示。关键字：deadlock. 步骤四，会打印出业务死锁的位置。

造成死锁的原因：最典型的就是2个线程互相等待对方持有的锁。

4.随机出现大量线程访问接口缓慢

代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随机的；平时消耗的CPU不多，而且占用的内存也不高。

思路：

首先找到该接口，通过压测工具不断加大访问力度，大量线程将阻塞于该阻塞点。

执行步骤1-4：

查看线程阻塞状态，如果出现TIMED_WAITING就是代码阻塞

5.某个线程由于某种原因而进入WAITING状态，此时该功能整体不可用，但是无法复现；

执行步骤1-4：

jstack多查询几次，每次间隔30秒，对比一直停留在parking 导致的WAITING状态的线程。例如CountDownLatch倒计时器，使得相关线程等待->AQS->LockSupport.park()。

了解更多计算机编程技术推荐观看教学视频继续学习