解决线上Java程序GC频繁问题思路

1、Full GC次数过多

这种情况比较容易出现，尤其是新功能上线时。对应Full GC 较多的情况，其主要有如下两个特征：

• 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程
• 通过jstat命令监控GC情况，可以看到Full GC 次数非常多，并且次数在不断增加

对应的排查操作方向如下：

• 使用top命令查看系统CPU的占用情况
• 找到CPU占用量最高的Java程序，并用top命令查看该进程的各个线程运行情况
• 通过jstack命令查看具体某个线程为什么耗费CPU最高
• 根据具体的信息，来继续一步步排查问题所在

2、CPU过高

首先通过top命令查看当前CPU消耗过高的进程是哪个，从而得到进程ID，然后通过top -HP来查看进程中有哪些线程CPU过高，一般超过80%就是比较高的，80%左右是合理情况。得到CPU消耗比较高的线程id，接着通过id的十六进制表示在jstack日志中查看当前线程具体的堆栈信息。

分析导致CPU过高原因具体是Full GC 次数过多还是代码中比较耗时的计算，如果Full GC次数过多，那么通过jstack得到的线程信息会是类似VMThread之列的线程，而如果是代码中有比较耗时的计算，那么得到的就是线程的具体堆栈信息。

3、不定期出现的接口耗时现象

比较典型的例子就是，某个接口访问经常需要2-3秒才能返回，其消耗的CPU不多，而且占用的内存也不高，也就是说，通过上述两种方法排查无法解决这种问题。

由于这样的接口耗时比较大的问题是不定时出现的，首先需要找到该接口，通过压测工具不断加大访问力度，如果说该接口中有某个位置是比较耗时的，由于访问频率比较高，那么大多数的线程最终都将阻塞于改阻塞点，这样通过多个线程具有相同的堆栈日志，基本上就可以定位到该接口中比较耗时的diam位置。