对于互联网公司，线上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()。
了解更多计算机编程技术推荐观看教学视频继续学习
