系统运行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 USERPRNIVIRTRESSHR S %CPU %MEMTIME+COMMAND
14354 wls81150717m 667m 1720 S 81.72.120572:58 java4003 wls81160703m 670m 1724 S 63.42.114792:05 java22416 wls81160381m 348m 1720 S 16.61.1 164:43.26 java6389 wls81150244m 213m 1756 S7.00.74909:44 java
第二步：执行kill -3 pid获取thread dump日志（pid就是第一步获取到的）。其次：获取线程信息
大多数服务器应用都是多线程，因此必须查到具体是哪些线程占用的CPU高。通过top –H命令可以查看到应用程序的线程信息及占用CPU的情况。
如下所示：
PID USERPRNIVIRTRESSHR S %CPU %MEMTIME+COMMAND
4280 nbg-syst180 3608m 2.0g21m R 93.6 25.95004:49 java
4279 nbg-syst180 3608m 2.0g21m R 92.6 25.94876:40 java
4281 nbg-syst180 3608m 2.0g21m R 92.6 25.93892:54 java
4282 nbg-syst180 3608m 2.0g21m R 91.2 25.94954:40 java
4244 nbg-syst150 3608m 2.0g21m S3.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
【java|Java thread dump分析】http://blog.csdn.net/rachel_luo/article/details/8920596
推荐阅读
- 操作系统|[译]从内部了解现代浏览器(1)
- Java|Java基础——数组
- 人工智能|干货！人体姿态估计与运动预测
- java简介|Java是什么（Java能用来干什么？）
- Java|规范的打印日志
- Linux|109 个实用 shell 脚本
- 程序员|【高级Java架构师系统学习】毕业一年萌新的Java大厂面经，最新整理
- Spring注解驱动第十讲--@Autowired使用