一、cpu飙升
在线上有时候某个时刻，可能会出现应用某个时刻突然cpu飙升的问题。对此我们应该熟悉一些指令，快速排查对应代码。
1.找到最耗CPU的进程
指令:top
2.找到该进程下最耗费cpu的线程
指令:top -Hp pid
3.转换进制
printf "%x
" 15332
4.过滤指定线程，打印堆栈信息
指令:
jstack pid |grep 'threadPid' -C5 --color
jstack 13525 |grep '0x3be4' -C5 --color //打印进程堆栈，并通过线程id，过滤得到线程堆栈信息
可以看到是一个上报程序，占用过多cpu了（以上例子只为示例，本身耗费cpu并不高）
二、线程死锁
有时候部署场景会有线程死锁的问题发生，但又不常见。此时我们采用jstack查看下一下。比如说我们现在已经有一个线程死锁的程序，导致某些操作waiting中。
1.查找java进程id
指令:top 或者 jps
2.查看java进程的线程快照信息
指令：jstack -l pid
从输出信息可以看到，有一个线程死锁发生，并且指出了那行代码出现的。如此可以快速排查问题。
三、OOM内存泄露
OOM的三种情况:
1.申请资源（内存）过小，不够用。
2.申请资源太多，没有释放。
3.申请资源过多，资源耗尽。比如：线程过多，线程内存过大等。
1.排查申请申请资源问题。
指令：jmap -heap 11869
查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。从上述排查，发现程序申请的内存没有问题。
2.排查gc
指令：jstat -gcutil 11938 1000 每秒输出一次gc的分代内存分配情况以及gc时间
3.查找最费内存的对象
指令：jmap -histo:live 11869 | more
上述输出信息中，最大内存对象才161kb,属于正常范围。如果某个对象占用空间很大，比如超过了100Mb，应该着重分析，为何没有释放。
注意，上述指令:
jmap -histo:live 11869 | more
执行之后，会造成jvm强制执行一次fgc，在线上不推荐使用，可以采取dump内存快照，线下采用可视化工具进行分析，更加详尽。
jmap -dump:format=b,file=/tmp/dump.dat 11869
或者采用线上运维工具，自动化处理，方便快速定位，遗失出错时间。
4.确认资源是否耗尽
pstree 查看进程线程数量
netstat 查看网络连接数量
参考：https://my.oschina.net/u/1859679/blog/1552290