1. Full GC次数过多
相对来说,这种情况是最容易出现的,尤其是新功能上线时。对于Full GC较多的情况,其主要有如下两个特征: 线上多个线程的CPU都超过了100%,通过jstack命令可以看到这些线程主要是垃圾回收线程 通过jstat命令监控GC情况,可以看到Full GC次数非常多,并且次数在不断增加。 首先我们可以使用top命令查看系统CPU的占用情况,如下是系统CPU较高的一个示例: 可以看到,有一个Java程序此时CPU占用量达到了98.8%,此时我们可以复制该进程id9,并且使用如下命令查看呢该进程的各个线程运行情况: 该进程下的各个线程运行情况如下: 可以看到,在进程为9的Java程序中各个线程的CPU占用情况,接下来我们可以通过jstack命令查看线程id为10的线程为什么耗费CPU最高。需要注意的是,在jsatck命令展示的结果中,线程id都转换成了十六进制形式。可以用如下命令查看转换结果,也可以找一个科学计算器进行转换: 这里打印结果说明该线程在jstack中的展现形式为0xa,通过jstack命令我们可以看到如下信息: 这里的VM Thread一行的最后显示nid=0xa,这里nid的意思就是操作系统线程id的意思。而VM Thread指的就是垃圾回收的线程。这里我们基本上可以确定,当前系统缓慢的原因主要是垃圾回收过于频繁,导致GC停顿时间较长。我们通过如下命令可以查看GC的情况: 可以看到,这里FGC指的是Full GC数量,这里高达6793,而且还在不断增长。从而进一步证实了是由于内存溢出导致的系