使用Java thread dump分析CPU高使用率和线程死锁问题
2018-01-08 15:39
651 查看
开门见山,本文将简述如何使用java thread dump来分析CPU高使用率以及线程死锁问题。
一般java thread dump用于web开发中分析web容器或是应用服务器的性能问题还是比较常用并有效的。常用的入门级web容器Tomcat,以及高级别的jboss、websphere、weblogic等的性能调优问题都可以使用java thread dump来分析。
首先,阐述一下thread dump常用来解决的是何种问题
(1)高CPU使用
(2)线程死锁
其次,使用步骤[以JBOSS为例]
1..get thread dump log
(1)找到应用程序所在的进程号,命令如下
Java代码
ps aux |grep 'jboss' | grep 'java'
、
获取需要的PID
(2)执行sudo kill -3 PID获取thread dump log(PID是第一步获取)。
注意:在不同的linux环境下执行输出的日志的地方可能不同。在IBM的PowerPC小型机上的linux上执行kill -3 pid会在工作目录下产生类似javacore.20100409.161739.7614.0001.txt的文件。JBOSS默认环境下,thread dump log输出到jboss console,所以thread dump信息会输出到个人定义的控制台打印log中。
部分示例如下所以:
引用
2010-10-08 20:27:42
Full thread dump Java HotSpot(TM) Server VM (16.3-b01 mixed mode):
"http-182.50.0.138-8084-6" daemon prio=10 tid=0x08ce5000 nid=0x6a4c in Object.wait() [0x87b5c000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x95eb81b0> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:415)
- locked <0x95eb81b0> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at org.apache.t
4000
omcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:441)
at java.lang.Thread.run(Thread.java:619)
"http-182.50.0.138-8084-5" daemon prio=10 tid=0x08c2e000 nid=0x6a4b in Object.wait() [0x87bad000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x95ed0600> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:415)
- locked <0x95ed0600> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:441)
at java.lang.Thread.run(Thread.java:619)
"ajp-127.0.0.1-8009-Acceptor-0" daemon prio=10 tid=0x894de800 nid=0x6a45 runnable [0x881f3000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390)
- locked <0x949c1288> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:619)
DefaultQuartzScheduler_QuartzSchedulerThread" prio=10 tid=0x8a460800 nid=0x6a38 sleeping[0x88818000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:394)
(3)获取线程信息
使用上面的ps或者使用top命令也可以。获取的线程信息如下所示:
引用
27143 root 20 0 780m 376m 11m S 17 11.5 2:56.48 java
4839 root 20 0 778m 162m 11m S 10 5.0 1717:03 java
5049 root 20 0 764m 147m 11m S 4 4.5 1744:06 java
1 root 20 0 2100 720 624 S 0 0.0 0:28.08 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.44 migration/0
第一列是十进制PID,需要转化为16进制后才能和thread dump信息对应。
2.分析thread dump信息[不在列举示例,只讲思想]
(1)分析高CPU使用线程的thread dump信息,查找那些代码导致高CPU使用。
(2)线程死锁
a.为了发现线程动态变化,需要多次做thread dump,每次间隔10-30s为佳.
b.线程状态用 runnable(正在运行)、waiting for monitor(主动等待)、waiting for monitor entry(死锁)。所以我们最多的是关注runnable和entry类型的线程。
一种典型的死锁是在server端多个应用同时使用同一个jboss资源,这时候需要将多个应用分不到不用的队列中。
http://binma85.iteye.com/blog/778986
一般java thread dump用于web开发中分析web容器或是应用服务器的性能问题还是比较常用并有效的。常用的入门级web容器Tomcat,以及高级别的jboss、websphere、weblogic等的性能调优问题都可以使用java thread dump来分析。
首先,阐述一下thread dump常用来解决的是何种问题
(1)高CPU使用
(2)线程死锁
其次,使用步骤[以JBOSS为例]
1..get thread dump log
(1)找到应用程序所在的进程号,命令如下
Java代码
ps aux |grep 'jboss' | grep 'java'
、
获取需要的PID
(2)执行sudo kill -3 PID获取thread dump log(PID是第一步获取)。
注意:在不同的linux环境下执行输出的日志的地方可能不同。在IBM的PowerPC小型机上的linux上执行kill -3 pid会在工作目录下产生类似javacore.20100409.161739.7614.0001.txt的文件。JBOSS默认环境下,thread dump log输出到jboss console,所以thread dump信息会输出到个人定义的控制台打印log中。
部分示例如下所以:
引用
2010-10-08 20:27:42
Full thread dump Java HotSpot(TM) Server VM (16.3-b01 mixed mode):
"http-182.50.0.138-8084-6" daemon prio=10 tid=0x08ce5000 nid=0x6a4c in Object.wait() [0x87b5c000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x95eb81b0> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:415)
- locked <0x95eb81b0> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at org.apache.t
4000
omcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:441)
at java.lang.Thread.run(Thread.java:619)
"http-182.50.0.138-8084-5" daemon prio=10 tid=0x08c2e000 nid=0x6a4b in Object.wait() [0x87bad000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x95ed0600> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:415)
- locked <0x95ed0600> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:441)
at java.lang.Thread.run(Thread.java:619)
"ajp-127.0.0.1-8009-Acceptor-0" daemon prio=10 tid=0x894de800 nid=0x6a45 runnable [0x881f3000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390)
- locked <0x949c1288> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:619)
DefaultQuartzScheduler_QuartzSchedulerThread" prio=10 tid=0x8a460800 nid=0x6a38 sleeping[0x88818000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:394)
(3)获取线程信息
使用上面的ps或者使用top命令也可以。获取的线程信息如下所示:
引用
27143 root 20 0 780m 376m 11m S 17 11.5 2:56.48 java
4839 root 20 0 778m 162m 11m S 10 5.0 1717:03 java
5049 root 20 0 764m 147m 11m S 4 4.5 1744:06 java
1 root 20 0 2100 720 624 S 0 0.0 0:28.08 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.44 migration/0
第一列是十进制PID,需要转化为16进制后才能和thread dump信息对应。
2.分析thread dump信息[不在列举示例,只讲思想]
(1)分析高CPU使用线程的thread dump信息,查找那些代码导致高CPU使用。
(2)线程死锁
a.为了发现线程动态变化,需要多次做thread dump,每次间隔10-30s为佳.
b.线程状态用 runnable(正在运行)、waiting for monitor(主动等待)、waiting for monitor entry(死锁)。所以我们最多的是关注runnable和entry类型的线程。
一种典型的死锁是在server端多个应用同时使用同一个jboss资源,这时候需要将多个应用分不到不用的队列中。
http://binma85.iteye.com/blog/778986
相关文章推荐
- 真实案例:使用Java Thread Dump分析ReadWriteLock导致的死锁问题
- Linux 下分析Java程序CPU使用高的问题
- 使用Java线程堆栈分析问题
- 如何使用MDB调试分析Solaris内核死锁的问题
- Java中Thread的使用、死锁以及生产者消费者问题详解
- 分析java程序中cpu占用过高的线程
- java基础问题---java中有几种方法可以实现一个线程?用什么关键字修饰同步方法? stop()和suspend()方法为何不推荐使用
- java 使用ireport无法显示图片问题分析
- DllMain中不当操作导致死锁问题的分析——线程中调用GetModuleFileName、GetModuleHandle等导致死锁
- windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码
- Java笔记3 多线程<1>线程概述、多线程的创建、多线程的安全问题、静态同步函数的锁、死锁
- 使用jstack分析cpu消耗过高的问题
- 一个线程死锁问题的分析
- 使用jstack分析cpu消耗过高的问题
- 我们使用jdk自带的jstack来分析。当linux出现cpu被java程序消耗过高时
- JavaWeb开发之Servlet中的线程问题及使用ServletConfig对象操作Servlet中的参数
- 通过Java thread dump分析找到耗费CPU最高的源代码
- windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码
- java线程同步之死锁问题
- java笔记:熟练掌握线程技术---基础篇之线程的协作和死锁的问题(下)