一次性搞清楚线上CPU100%，频繁FullGC排查套路

如下示例中则是在 SyncTask 的第 8 行导致该线程进入等待了：

"Thread-0" #11 prio=5 os_prio=31 tid=0x00007f9de08c7000 nid=0x5603 waiting on condition [0x0000700001f89000] 
   java.lang.Thread.State: WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) 
    at com.aibaobei.chapter2.eg4.SyncTask.lambda$main$0(SyncTask.java:8) 
    at com.aibaobei.chapter2.eg4.SyncTask$$Lambda$1/1791741888.run(Unknown Source) 
    at java.lang.Thread.run(Thread.java:748) 

死锁

对于死锁，这种情况基本上很容易发现，因为 jstack 可以帮助我们检查死锁，并且在日志中打印具体的死锁线程信息。

如下是一个产生死锁的一个 jstack 日志示例：

可以看到，在 jstack 日志的底部，其直接帮我们分析了日志中存在哪些死锁，以及每个死锁的线程堆栈信息。

这里我们有两个用户线程分别在等待对方释放锁，而被阻塞的位置都是在 ConnectTask 的第 5 行，此时我们就可以直接定位到该位置，并且进行代码分析，从而找到产生死锁的原因。

小结

本文主要讲解了线上可能出现的五种导致系统缓慢的情况，详细分析了每种情况产生时的现象，已经根据现象我们可以通过哪些方式定位得到是这种原因导致的系统缓慢。

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

①通过 top 命令查看 CPU 情况，如果 CPU 比较高，则通过 top -Hp 命令查看当前进程的各个线程运行情况。

找出 CPU 过高的线程之后，将其线程 id 转换为十六进制的表现形式，然后在 jstack 日志中查看该线程主要在进行的工作。

这里又分为两种情况：

• 如果是正常的用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗 CPU。
• 如果该线程是 VM Thread，则通过 jstat -gcutil 命令监控当前系统的 GC 状况。

然后通过 jmap dump:format=b,file= 导出系统当前的内存数据。

导出之后将内存情况放到 Eclipse 的 Mat 工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码。

②如果通过 top 命令看到 CPU 并不高，并且系统内存占用率也比较低。此时就可以考虑是否是由于另外三种情况导致的问题。

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

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

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

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!