Linux下Java线程具体监控和其dump的分析使用----分析Java性能瓶颈[张振华-Jack]

作者：张振华(Jack)
这里对linux下、sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结；

linux环境下，当发现java进程占用CPU资源非常高，且又要想更进一步查出哪一个java线程占用了CPU资源时，依照下面步骤进行查找：

(一)：通过【top -p 12377 -H】 查看java进程的有哪些线程的执行情况。

      和通过【jstack 12377 > stack.log】生成Java线程的dump具体信息。

1. 1. 先用top命令找出占用资源厉害的java进程id，如图：# top
   2. 如上图所看到的。java的进程id为'52554'，接下来用top命令单独对这个进程中的全部线程作监视：

2. 1	top -p 52554 -H #  top视图里面里面能够通过快捷键依次b ,x高亮显示top的列找出须要的线程。默认CPU排序，Shift+< ,Shift+>能够左右移动高亮排序的列；

   如图：(这时就看出来哪个java线程CPU高。哪个线程内存用的多)
   
   

3. 如上图所看到的，linux下，全部的java内部线程，事实上都相应了一个进程id，也就是说，linux上的sun jvm将java程序中的线程映射为了操作系统进程；我们看到。占用CPU资源最高的那个进程id是'15417'，这个进程id相应java线程信息中的'nid'('n' stands for 'native');
4. (1)要想找到究竟是哪段详细的代码占用了如此多的资源，先使用jstack打出当前栈信息到一个文件中, 比方stack.log：

   1	jstack 52554 > stack.log

   然后使用'jtgrep'脚本把这个进程号为'9757'的java线程在stack.log中抓出来：

   1	jtgrep 9757 stack.log

   

   当中，'jtgrep'是自己随便写的一个shell脚本：

   1

   #!/bin/sh

   3	nid=`python -c "print hex($1)"`

   4	grep -i $nid $2

   道理非常easy，就是把'9757'转换成16进制后，直接grep stack.log;能够看到，被grep出的那个线程的nid=0x3c39。正好是15417的16进制表示。

(2) 通过(windows程序-->计算器)，选择程序猿计算器将进程ID转换成16进制 到dump里面的nid 就能够搜索到

"http-nio-8080-exec-25" daemon prio=10 tid=0x00007f69686b4800 nid=0x1ce5 waiting on condition [0x00007f698e7cf000]

   java.lang.Thread.State: WAITING (parking)

        at sun.misc.Unsafe.park(Native Method)

        - parking to wait for  <0x0000000777063ec8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

        at java.util.concurrent.locks.LockSupport.park(Unknown Source)

        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)

        at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)

        at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)

        at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)

        at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

        at java.lang.Thread.run(Unknown Source)

（二）另外一种通过 Java visualMv结合jconsole.exe  工具就可以查看如图所看到的。(第一种方式可能更准确一些)

三：在Java Visualvm工具里面安装JTA插件，分析线程dump文件，注意，正常阶段的dump文件与非正常时期的Dump文件进行比較更easy分析出问题：

（1）下载：https://java.net/projects/tda/downloads/directory/visualvm

  (2)安装与使用：

（3）使用：

四：直接通过tda-bin-2.2in da.sh 来分析导出ThreadDump文件；(在没有JMX监控的情况下手动查看threadDump信息)

       下载地址：https://java.net/projects/tda/downloads/directory/visualvm