分析JAVA应用CPU占用过高的问题

使用jstack分析java程序cpu占用率过高的有关问题
使用jstack分析java程序cpu占用率过高的问题
1，使用jps查找出java进程的pid，如3707
2，使用top -p 14292 -H观察该进程中所有线程的CPU占用。
1. [root@cp01-game-dudai-0100.cp01.baidu.com ~]# top -p 14292 -H
2. top - 22:14:13 up 33 days, 7:29, 4 users, load average: 25.68, 32.11, 33.76
3. Tasks: 113 total, 2 running, 111 sleeping, 0 stopped, 0 zombie
4. Cpu(s): 68.3%us, 6.3%sy, 0.0%ni, 20.2%id, 0.1%wa, 0.2%hi, 4.9%si, 0.0%st
5. Mem: 65965312k total, 65451232k used, 514080k free, 82164k buffers
6. Swap: 975864k total, 972052k used, 3812k free, 9714400k cached
7.
8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9. 15844 root 15 0 6889m 5.7g 4864 S 20.6 9.1 814:13.29 java
10. 15848 root 15 0 6889m 5.7g 4864 S 13.0 9.1 460:25.17 java
11. 15611 root 15 0 6889m 5.7g 4864 S 12.7 9.1 468:17.77 java
12. 15613 root 15 0 6889m 5.7g 4864 S 11.7 9.1 479:40.45 java
13. 15743 root 15 0 6889m 5.7g 4864 S 11.7 9.1 443:04.80 java
14. 15612 root 15 0 6889m 5.7g 4864 S 11.0 9.1 453:43.68 java
15. 15965 root 15 0 6889m 5.7g 4864 S 10.3 9.1 371:00.33 java
16. 15490 root 15 0 6889m 5.7g 4864 S 7.7 9.1 255:32.74 java
17. 15587 root 15 0 6889m 5.7g 4864 S 7.3 9.1 282:27.58 java
18. 15590 root 15 0 6889m 5.7g 4864 S 7.3 9.1 205:48.37 java
19. 15491 root 15 0 6889m 5.7g 4864 R 6.3 9.1 279:09.08 java
20. 15689 root 15 0 6889m 5.7g 4864 S 5.7 9.1 251:42.36 java
21. 16935 root 15 0 6889m 5.7g 4864 S 5.7 9.1 190:34.37 java
22. 15665 root 15 0 6889m 5.7g 4864 S 5.3 9.1 250:07.34 java
23. 16920 root 15 0 6889m 5.7g 4864 S 5.3 9.1 241:34.50 java
24. 15671 root 15 0 6889m 5.7g 4864 S 5.0 9.1 239:49.97 java
25. 15492 root 15 0 6889m 5.7g 4864 S 4.7 9.1 210:23.09 java
26. 14322 root 16 0 6889m 5.7g 4864 S 4.3 9.1 107:39.61 java
27. 14316 root 16 0 6889m 5.7g 4864 S 4.0 9.1 107:18.43 java
28. 14317 root 16 0 6889m 5.7g 4864 S 4.0 9.1 107:29.13 java
29. 15591 root 15 0 6889m 5.7g 4864 S 4.0 9.1 114:34.90 java
30. 14313 root 16 0 6889m 5.7g 4864 S 3.7 9.1 107:12.70 java
31. 14314 root 15 0 6889m 5.7g 4864 S 3.7 9.1 107:28.05 java
32. 14319 root 16 0 6889m 5.7g 4864 S 3.7 9.1 107:27.43 java
33. 14321 root 15 0 6889m 5.7g 4864 S 3.3 9.1 108:01.12 java
34. 15589 root 15 0 6889m 5.7g 4864 R 3.0 9.1 109:01.91 java
35. 15615 root 15 0 6889m 5.7g 4864 S 3.0 9.1 114:55.29 java
36. 16808 root 15 0 6889m 5.7g 4864 S 2.7 9.1 279:05.03 java
37. 14315 root 15 0 6889m 5.7g 4864 S 2.0 9.1 107:45.00 java
38. 14320 root 15 0 6889m 5.7g 4864 S 2.0 9.1 107:48.30 java
39. 15489 root 15 0 6889m 5.7g 4864 S 1.7 9.1 57:38.46 java
40. 15670 root 15 0 6889m 5.7g 4864 S 1.3 9.1 5:55.43 java
41. 14318 root 15 0 6889m 5.7g 4864 S 0.7 9.1 107:45.88 java
42. 14826 root 15 0 6889m 5.7g 4864 S 0.7 9.1 25:07.64 java

3，找出CPU消耗较多的线程id，如15844，将15844转换为16进制0x3de4，注意是小写哦
4，使用jstack 14292|grep -A 10 0x3de4来查询出具体的线程状态。

1. [root@cp01-game-dudai-0100.cp01.baidu.com ~]# jstack 14292|grep -A 10 0x3de4  
2. "pool-52-thread-1" prio=10 tid=0x000000005a08e000 nid=0x3de4 waiting on condition [0x00002ae63d917000]  
3.    java.lang.Thread.State: WAITING (parking)  
4.         at sun.misc.Unsafe.park(Native Method)  
5.         - parking to wait for  <0x00000006f9a0a110> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)  
6.         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)  
7.         at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)  
8.         at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)  
9.         at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)  
10.         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)  
11.         at java.lang.Thread.run(Thread.java:662)  

通过这些线程状态便可基本定位问题之所在。
来源于：http://blog.csdn.net/jiangguilong2000/article/details/17971247