线上CPU100%，频繁FullGC排查套路笔记

最新推荐文章于 2023-02-03 15:57:47 发布

zhg_vincent

最新推荐文章于 2023-02-03 15:57:47 发布

阅读量363

点赞数 1

分类专栏：笔记 java 文章标签：线上调优笔记

本文链接：https://blog.csdn.net/Vincent2014Linux/article/details/102484228

版权

15 篇文章 2 订阅

订阅专栏

10 篇文章 0 订阅

订阅专栏

对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出 jstack 和内存信息，然后重启系统，尽快保证系统的可用性。

这种情况可能的原因主要有两种：

相对来说，这是出现频率最高的两种线上问题，而且它们会直接导致系统不可用。

另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用：

简要的说，我们进行线上日志分析时，主要可以分为如下情况：

通过 top 命令查看 CPU 情况，如果 CPU 比较高，则通过 top -Hp 命令查看当前进程的各个线程运行情况。
找出 CPU 过高的线程之后，将其线程 id 转换为十六进制的表现形式（printf “%x” ），然后在 jstack 日志中查看该线程主要在进行的工作（jstack 进程pid | grep 十六进制的线程tid 如：jstack 1956 | grep -A10 7b9:显示含有线程号为【7b9】的那一行以及其后10行的数据）。

这里又分为两种情况：

如果是正常的用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗 CPU。（jstack -l pid(进程pid) > 文件路径名）
如果该线程是 VM Thread，则通过 jstat -gcutil 命令监控当前系统的 GC 状况。
然后通过 jmap dump:format=b,file= 导出系统当前的内存数据。导出之后将内存情况放到 Eclipse 的 Mat 工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码。

具体的可以根据具体情况分析：

如果是接口调用比较耗时，并且是不定时出现，则可以通过压测的方式加大阻塞点出现的频率，从而通过 jstack 查看堆栈信息，找到阻塞点。
如果是某个功能突然出现停滞的状况，这种情况也无法复现，此时可以通过多次导出 jstack 日志的方式对比哪些用户线程是一直都处于等待状态，这些线程就是可能存在问题的线程。
如果通过 jstack 可以查看到死锁状态，则可以检查产生死锁的两个线程的具体阻塞点，从而处理相应的问题。

本文主要总结了五种常见的导致线上功能缓慢的问题，以及排查思路。当然，线上的问题出现的形式是多种多样的，也不一定局限于这几种情况。