操作步骤:
1、执行:top 或者 top -c
查看进程,如下图中进程pid=7477的占用cpu很高
2、执行:top -H -p 7477
查看进程下面的各个线程, 7477 是第一步中的进程pid
3、执行:jstack 7477|grep -A 10 1d3a
查看某个线程的堆栈信息,7477是进程pid,1d3a 是线程pid=7482的转的16进制后的值,注意字母是小写(进制在线转换工具 https://tool.lu/hexconvert/)。-A 10表示查找到所在行的后10行。下图显示大量的GC动作导致了程序变慢,最后OOM。
如果是 Full GC 次数过多,那么通过 jstack 得到的线程信息会是类似于 VM Thread 之类的线程。
而如果是代码中有比较耗时的计算,那么我们得到的就是一个线程的具体堆栈信息。
4、执行:jstack 7477 > 12.log
查看并导出整个进程的堆栈信息(包含该进程下面的所有线程的堆栈信息)
执行:jstat -gcutil 20344 1s 每1秒打印一次进程id=20344的GC情况。
不过以上步骤对分析具体的详细的GC等原因用处不大,请参照下面:
1.使用jmap命dump文件。 其中 file 指文件的存放目录,6829 指进程id,即出现异常的pid
jmap -dump:live,format=b,file=/tmp/tmux-0/heap-dump.hprof 6829
2.如果dump的文件比较大,下载到本地比较费时,可以先进行压缩了之后在下载
tar -zcvf heap-dump.hprof.tar.gz heap-dump.hprof
3.运用工具Eclipse mat或者\jdk\bin目录下 jvisualvm 对dump进行详细分析,具体用法见对应链接:
mat:https://blog.csdn.net/xu19950210rou/article/details/120845384
jvisualvm :https://blog.csdn.net/xu19950210rou/article/details/120842952