排查步骤
1.执行“top”命令：查看所有进程占系统CPU的排序。极大可能排第一个的就是咱们的java进程（COMMAND列）。PID那一列就是进程号。
2.执行“top -Hp 进程号”命令：查看java进程下的所有线程占CPU的情况。
3.执行“printf “%x\n 10”命令 ：后续查看线程堆栈信息展示的都是十六进制，为了找到咱们的线程堆栈信息，咱们需要把线程号转成16进制。例如,printf “%x\n 10-》打印：a，那么在jstack中线程号就是0xa.
4.执行 “jstack 进程号 | grep 线程ID” 查找某进程下-》线程ID（jstack堆栈信息中的nid）=0xa的线程状态。如果“”VM Thread” os_prio=0 tid=0x00007f871806e000 nid=0xa runnable”，第一个双引号圈起来的就是线程名，如果是“VM Thread”这就是虚拟机GC回收线程了
5.执行“jstat -gcutil 进程号 统计间隔毫秒 统计次数（缺省代表一致统计）”，查看某进程GC持续变化情况，如果发现返回中FGC很大且一直增大-》确认Full GC! 也可以使用“jmap -heap 进程ID”查看一下进程的堆内从是不是要溢出了，特别是老年代内从使用情况一般是达到阈值(具体看垃圾回收器和启动时配置的阈值)就会进程Full GC。
6.执行“jmap -dump:format=b,file=filename 进程ID”，导出某进程下内存heap输出到文件中。可以通过eclipse的mat工具查看内存中有哪些对象
1. Full GC次数过多
两个特征
-
线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程
-
通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加。
top命令
top -Hp 9 命令
该进程下的各个线程运行情况如下：
可以看到，在进程为 9的Java程序中各个线程的CPU占用情况，接下来我们可以通过jstack命令查看线程id为 10的线程为什么耗费CPU最高。
jsatck命令展示的结果中，线程id都转换成了十六进制形式
printf ”%x\n” 10
jstack命令
”VM Thread“ 代表垃圾回收线程
jstat -gcutil 进程号
1
2
3
root@8d36124607a0:/# jstat -gcutil 9 1000 10 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 0.00 75.07 59.09 59.60 3259 0.919 6517 7.715 8.635 0.00 0.00 0.00 0.08 59.09 59.60 3306 0.930 6611 7.822 8.752 0.00 0.00 0.00 0.08 59.09 59.60 3351 0.943 6701 7.924 8.867 0.00 0.00 0.00 0.08 59.09 59.60 3397 0.955 6793 8.029 8.984
Full GC数量，这里高达6793，而且还在不断增长。从而进一步证实了是由于内存溢出导致的系统缓慢。
jmap -dump:format=b,file=filename 进程ID
[Full GC (System.gc())
-XX:+DisableExplicitGC来禁用JVM对显示GC的响应
2. CPU过高
jstack日志中查看当前线程具体的堆栈信息
如果是Full GC次数过多，那么通过 jstack得到的线程信息会是类似于VM Thread之类的线程，而如果是代码中有比较耗时的计算，那么我们得到的就是一个线程的具体堆栈信息。
3. 死锁
jstack可以帮助我们检查死锁，并且在日志中打印具体的死锁线程信息。如下是一个产生死锁的一个 jstack日志示例
可以看到，在jstack日志的底部，其直接帮我们分析了日志中存在哪些死锁，以及每个死锁的线程堆栈信息。
https://mp.weixin.qq.com/s/g8KJhOtiBHWb6wNFrCcLVg
