可以分为如下步骤:
①通过 top 命令查看 CPU 情况,如果 CPU 比较高,则通过 top -Hp
找出 CPU 过高的线程之后,将其线程 id 转换为十六进制的表现形式(printf "%x" <线程id>),然后在 jstack 日志中查看该线程主要在进行的工作(jstack -F -l
这里又分为两种情况:
1: 如果是正常的用户线程,则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗 CPU。
2: 如果该线程是 VM Thread(VM Thread 指的就是垃圾回收的线程,一般前面会有 nid=0x.......,这里 nid 的意思就是操作系统线程 id),则通过 jstat -gcutil
②如果通过 top 命令看到 CPU 并不高,并且系统内存占用率也比较低。此时就可以考虑是否是由于另外三种情况导致的问题。
具体的可以根据具体情况分析:
1: 如果是接口调用比较耗时,并且是不定时出现,则可以通过压测的方式加大阻塞点出现的频率,从而通过 jstack 查看堆栈信息,找到阻塞点。
2: 如果是某个功能突然出现停滞的状况,这种情况也无法复现,此时可以通过多次导出 jstack 日志的方式对比哪些用户线程是一直都处于等待状态,这些线程就是可能存在问题的线程。
3: 如果通过 jstack 可以查看到死锁状态,则可以检查产生死锁的两个线程的具体阻塞点,从而处理相应的问题。