Java thread dump分析

       系统运行4、5年后,随着功能越加越多,到今天总是会有CPU突然占用过高的警告发生,如果处理不好的话则会引起系统的OOM,很是头疼!有必要学习如何分析找到耗费CPU最高的源码,最好的分析方法就是分析thread dump文件

首先:如何产生thread dump日志

第一步:找到应用程序所在的进程号,通过top命令可以找到,linux命令行里输入top命令,然后回车会进入一个显示当前cpu,内存,进程等信息的界面,直接根据你程序的类型找到相应的进程,然后查看pid列的值。

该操作有点类似在window下查看任务管理器各进程的CPU以及内存使用情况:

[login@001 system]$ top -5

top - 11:22:20 up 97 days, 17:58,  3 users,  load average: 3.20, 3.19, 3.38

Tasks: 191 total,   1 running, 188 sleeping,   2 stopped,   0 zombie

Cpu(s): 41.7% us,  2.4% sy,  0.0% ni, 32.4% id, 23.3% wa,  0.2% hi,  0.0% si

Mem:  33275268k total, 32646440k used,   628828k free,    28560k buffers

Swap:  6144744k total,   877804k used,  5266940k free,  7816596k cached

 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                 

14354 wls81     15   0  717m 667m 1720 S 81.7  2.1  20572:58 java                                   4003 wls81     16   0  703m 670m 1724 S 63.4  2.1  14792:05 java                                   22416 wls81     16   0  381m 348m 1720 S 16.6  1.1 164:43.26 java                                 6389 wls81     15   0  244m 213m 1756 S  7.0  0.7   4909:44 java  

 

第二步:执行kill -3 pid获取thread dump日志(pid就是第一步获取到的)。                         其次:获取线程信息

大多数服务器应用都是多线程,因此必须查到具体是哪些线程占用的CPU高。通过top –H命令可以查看到应用程序的线程信息及占用CPU的情况。

如下所示:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

 4280 nbg-syst  18   0 3608m 2.0g  21m R 93.6 25.9   5004:49 java 

 4279 nbg-syst  18   0 3608m 2.0g  21m R 92.6 25.9   4876:40 java 

 4281 nbg-syst  18   0 3608m 2.0g  21m R 92.6 25.9   3892:54 java 

 4282 nbg-syst  18   0 3608m 2.0g  21m R 91.2 25.9   4954:40 java 

 4244 nbg-syst  15   0 3608m 2.0g  21m S  3.3 25.9 168:34.04 java                             

PID所在的列即是对应的线程ID,这是十进制的。               

       最后:找到耗费CPU高的线程及对应的源代码

取上面耗费CPU最高的第一行的PID 4280,将其转化为十六进制得到0x10b8。然后在thread dump日志中搜索0x10b8,将会搜到如下信息:

"Stack.ClientSelector-1" daemon prio=10 tid=0x000000004baeec00 nid=0x10b8 runnable [0x0000000053169000..0x0000000053169c90]

   java.lang.Thread.State: RUNNABLE

       at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

       at sun.nio.ch.EPollArrayWrapper.poll(Unknown Source)

       at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)

       at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)

       - locked <0x00002aaac4105468> (a sun.nio.ch.Util$1)

       - locked <0x00002aaac4131670> (a java.util.Collections$UnmodifiableSet)

       - locked <0x00002aaac3f79c78> (a sun.nio.ch.EPollSelectorImpl)

       at sun.nio.ch.SelectorImpl.select(Unknown Source)

       at com.****x

性能分析有两点需要注意:

1、dump文件(多个,不是一个,一个只是一个瞬间的),比较多个dump之间没有变化的线程,即阻塞的线程(可能有问题的)

2、针对内存要做threaddump看内存分布 或者加gc参数,查看的dump文件必须是针对业务应用对应的线程

 

java线程dump分析:

http://blog.csdn.net/yangjun2/article/details/6874599

http://www.linuxidc.com/Linux/2009-01/18171.htm

http://blog.csdn.net/zhaolingzhi55/article/details/8683161

http://blog.csdn.net/rachel_luo/article/details/8920596

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值