(10)系统慢,CPU100%,Full GC过多排查思路(1)

导出jstack和内存信息，重启系统，尽快保证可用性。

主要原因(可导致不可用)：

    (1)读数据量较大，内存耗尽，Full GC多，慢； (2)耗CPU操作，CPU过高，慢；

原因(只慢，还可用)：

    (3)阻塞，耗时，出现随机；(4)线程WAITING，整体不可用，但无法复现；(5)多个线程死锁

这种要查看系统日志，查CPU和系统内存，看不出具体问题，阻塞性操作，CPU和系统内存使用都不高。

一. Full GC次数过多

 两个特征：CPU超过100%，jstack命令看，主要是垃圾回收线程

                    jstat命令看监控GC情况，Full GC不断增加。

操作概要：看CPU，看进程(线程)，看内存日志（哪些对象多），内存占用不高，Full GC多，System.gc()禁用

1、输入 “top”  看CPU高示例：

2、来查看哪些线程CPU高top -Hp 9：

进程9中各个线程CPU占用情况，jstack命令看10线程为什么耗费CPU最高。jsatck中线程id都转换成十六进制。查看转换结果：root@a39de7e7934b:/# printf "%x\n" 10a (结果说明在jstack中的展现形式为0xa)，jstack命令：

nid=0xa，nid是系统线程。VM Thread是垃圾回收线程。GC停顿时间长，慢。GC情况：

3、Full GC数量高达6793，不断增长。dump内存日志(看是否是内存溢出)，通过eclipse的mat看，展示对象树结构：

PrintStream最多，消耗量只有12.2%。不足导致大量Full GC，显示System.gc()调用导致GC次数过多，解决：添加-XX:+DisableExplicitGC禁用

    Shallow Size：对象本身占内存大小，不包含引用对象。1)对象（非数组）Shallow Size由其成员变量的数量和类型来定，2)数组ShallowSize由数组类型和长度决定，为数组元素大小总和

    Retained Size=当前对象+直/间接引用到对象大小总和。(A->B->C,C间接引用) ，排除被GC Roots直/间接引用对象。就是当前对象被GC后，Heap释放掉的总内存

二、CPU过高

jstack得到线程信息，类似VM Thread线程（上面），如代码耗时计算，得到线程堆栈信息：定位UserController34行

三、接口不定期耗时

消耗CPU和内存都不多，jstack命令信息没法判断

思路：压测接口，复现堆栈日志：阻塞在18行

四、 线程WAITING

罕见情况，“不可复现性”，用CountDownLatch时，并行任务完成，唤醒主线程。一个连接一直等待服务器响应。其余WAITING。

问题线程与其他一样，思路：grep在jstack日志，找所有TIMED_WAITING线程，导出到a1.log：

10s后，再对jstack日志grep，导出到a2.log：

重复2，导出3~4文件对比，几个文件一直存在的用户线程，是问题线程。正常线程不会20~30s后还等待。通过线程名，排除框架线程

看堆栈信息，哪个代码导致：Thread-0是线程，SyncTask8行导致

五、 死锁

jstack检查死锁，日志中打印：

死锁线程堆栈信息

六. 小结

(1)top看CPU情况，top -Hp 看线程，将线程id转换为十六进制，jstack日志：

    1、VM Thread，jstat -gcutil 监控GC状，jmap dump:format=b,file= 内存数据。放到eclipse的mat工具分析

    2、正常线程，堆栈信息看哪处代码消耗CPU；

(2)CPU、内存都不高：

压测，jstack看堆栈信息；

无法复现，多次导出jstack日志，找出问题线程。

jstack看死锁

https://my.oschina.net/zhangxufeng/blog/3017521