Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈[张振华-Jack]
来源:互联网 发布:传智播客云计算大数据 编辑:程序博客网 时间:2024/06/05 22:57
作者:张振华(Jack)
这里对linux下、sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结;
这里对linux下、sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结;
linux环境下,当发现java进程占用CPU资源很高,且又要想更进一步查出哪一个java线程占用了CPU资源时,按照以下步骤进行查找:
(一):通过【
top
-p 12377 -H
】 查看java进程的有哪些线程的运行情况; 和通过【jstack 12377 > stack.log】生成Java线程的dump详细信息;
- 先用top命令找出占用资源厉害的java进程id,如图:# top
- 如上图所示,java的进程id为'52554',接下来用top命令单独对这个进程中的所有线程作监视:
1
top
-p 52554 -H
# top视图里面里面可以通过快捷键依次b ,x高亮显示top的列找出需要的线程,默认CPU排序,Shift+< ,Shift+>可以左右移动高亮排序的列;如图:(这时就看出来哪个java线程CPU高,哪个线程内存用的多)
- 如上图所示,linux下,所有的java内部线程,其实都对应了一个进程id,也就是说,linux上的sun jvm将java程序中的线程映射为了操作系统进程;我们看到,占用CPU资源最高的那个进程id是'15417',这个进程id对应java线程信息中的'nid'('n' stands for 'native');
- (1)要想找到到底是哪段具体的代码占用了如此多的资源,先使用jstack打出当前栈信息到一个文件里, 比如stack.log:
1
然后使用'jtgrep'脚本把这个进程号为'9757'的java线程在stack.log中抓出来:jstack 52554 > stack.log
1
jtgrep 9757 stack.log
其中,'jtgrep'是自己随便写的一个shell脚本:
1
#!/bin/sh
3
nid=`python -c
"print hex($1)"
`
4
grep
-i $nid $2
道理很简单,就是把'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文件进行比较更容易分析出问题:
(1)下载:https://java.net/projects/tda/downloads/directory/visualvm
(2)安装与使用:
(3)使用:
四:直接通过tda-bin-2.2\bin\tda.sh 来分析导出ThreadDump文件;(在没有JMX监控的情况下手动查看threadDump信息)
下载地址:https://java.net/projects/tda/downloads/directory/visualvm
1 0
- Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈[张振华-Jack]
- Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈[张振华-Jack]
- Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈
- Linux下Java线程详细监控和其dump的分析使用—-分析Java性能瓶颈
- Linux下Java线程详细监控和其dump的分析使用—-分析Java性能瓶颈
- Linux下Java线程详细监控和其dump的分析使用—-分析Java性能瓶颈
- Linux下Java线程详细监控和其dump的分析使用—-分析Java性能瓶颈
- COPY Linux下Java线程详细监控和其dump的分析使用
- JAVA线程dump的分析
- JAVA线程dump的分析
- Linux常用命令(6)-性能瓶颈分析(java)
- Linux下的CPU性能瓶颈分析
- Linux下的CPU性能瓶颈分析
- java线程dump分析
- 使用jstack和TDA进行java线程dump分析
- java性能测试瓶颈分析
- java程序性能分析之thread dump和heap dump
- JAVA线程dump的分析 --- jstack pid
- 泛型初步理解
- Cocos2dx内存管理
- MATLAB数据拟合(二)
- windows下编译lua源码
- SQL/NoSQL两大阵营激辩:谁更适合大数据
- Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈[张振华-Jack]
- PHP开发环境配置问题汇总
- poj2185 Milking Grid(KMP运用)
- 从零开始学android<Tablelayout表格布局.十五.>
- HTML 字符实体
- Android应用加入微信分享
- 关于字符编码,你所需要知道的
- ruby 返回jsonp
- [LeetCode]-Unique Paths 矩阵中求两点间所有路线条数