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()。