Java_tomcat thread dump 分析

  1. 前言

Java Thread Dump 是一个非常有用的应用诊断工具, 通过thread dump出来的信息, 可以定位到你需要了解的线程, 以及这个线程的调用栈. 如果配合linux的top命令, 可以找到你的系统中的最耗CPU的线程代码段, 这样才能有针对性地进行优化.

  1. 场景和实践

2.1. 后台系统一直是在黑盒运行, 除了能暂停一部分任务的执行, 根本无法知道哪些任务耗CPU过多。所以一直以为是业务代码的问题, 经过各种优化(删减没必要的逻辑, 合并写操作)等等优化, 系统负载还是很高. 没什么访问量, 后台任务处理也就是每天几百万的级别, load还是达到了15以上. CPU只有4核，天天收到load告警却无从下手, 于是乎就被迫来分析一把线程.

2.2 系统跑的是java tomcat, 要触发tomcat thread dump很简单, 先找到tomcat对应的进程id, 我们设置为PID

【linux 命令】：  ps -ef | grep tomcat

可以找到, 然后给这个进程发送一个QUIT的信号量, 让其触发线程的dump,  下面的操作先别急着动手, 等到看完2.3再动手不迟

【linux 命令】： kill -3 $PID   /  kill -QUIT $PID

tomcat会把thread dump的内容输出到控制台

【linux 命令】：cd $tomcathome/logs/

查看 catalina.out 文件, 把最后的跟thread相关的内容获取出来.

大致内容如下:

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2012-04-13 16:30:41

Full thread dump OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode):

"TP-Processor12" daemon prio=10 tid=0x00000000045acc00 nid=0x7f19 in Object.wait() [0x00000000483d0000..0x00000000483d0a90]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on <0x00002aaab5bfce70> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Object.wait(Object.java:502)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662)

- locked <0x00002aaab5bfce70> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Thread.run(Thread.java:636)

"TP-Processor11" daemon prio=10 tid=0x00000000048e3c00 nid=0x7f18 in Object.wait() [0x00000000482cf000..0x00000000482cfd10]

java.lang.Thread.State: WAITING (on object monitor)

....

"VM Thread" prio=10 tid=0x00000000042ff400 nid=0x77de runnable"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000429c400 nid=0x77d9 runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000000429d800 nid=0x77da runnable

"GC task thread#2 (ParallelGC)" prio=10 tid=0x000000000429ec00 nid=0x77db runnable

"GC task thread#3 (ParallelGC)" prio=10 tid=0x00000000042a0000 nid=0x77dc runnable

"VM Periodic Task Thread" prio=10 tid=0x0000000004348400 nid=0x77e5 waiting on condition

JNI global references: 815

Heap

PSYoungGen      total 320192K, used 178216K [0x00002aaadce00000, 0x00002aaaf1800000, 0x00002aaaf1800000)

eden space 303744K, 55% used [0x00002aaadce00000,0x00002aaae718e048,0x00002aaaef6a0000)

from space 16448K, 65% used [0x00002aaaf0690000,0x00002aaaf110c1b0,0x00002aaaf16a0000)

to   space 16320K, 0% used [0x00002aaaef6a0000,0x00002aaaef6a0000,0x00002aaaf0690000)

PSOldGen        total 460992K, used 425946K [0x00002aaab3a00000, 0x00002aaacfc30000, 0x00002aaadce00000)

object space 460992K, 92% used [0x00002aaab3a00000,0x00002aaacd9f6a30,0x00002aaacfc30000)

PSPermGen       total 56192K, used 55353K [0x00002aaaae600000, 0x00002aaab1ce0000, 0x00002aaab3a00000)

object space 56192K, 98% used [0x00002aaaae600000,0x00002aaab1c0e520,0x00002aaab1ce0000)

最后一段是系统的对内存的使用情况.

2.3. 要知道thread dump是不会告诉你每个线程的负载情况的, 需要知道每个线程的负载情况, 还得靠top命令来查看.

【linux 命令】：top -H -p $PID

这时候, 可以看到java进程下各个线程的负载和内存等使用情况. 也不用全部搞下来, 只要top几个负载过高的记录即可（最好按下SHIFT+T 按CPU耗时总时间倒序排序，这样找到的top几个是最耗CPU时间的，而且系统启动时间应该持续15分钟以上，这样容易看出哪个线程耗时多。）

大致内容如下:

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

Tasks: 118 total,   2 running, 116 sleeping,   0 stopped,   0 zombie

Cpu(s): 92.6%us,  2.3%sy,  0.0%ni,  3.8%id,  0.7%wa,  0.1%hi,  0.7%si,  0.0%st

Mem:   4054168k total,  3892212k used,   161956k free,   115816k buffers

Swap:  4192956k total,   294448k used,  3898508k free,  2156024k cachedPID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

8091 admin     16   0 1522m 814m 9660 R 22.3 20.6   4:05.61 java

8038 admin     16   0 1522m 814m 9660 R 10.3 20.6   2:46.31 java

8043 admin     15   0 1522m 814m 9660 S  3.7 20.6   1:52.04 java

8039 admin     15   0 1522m 814m 9660 S  0.7 20.6   2:10.98 java

8041 admin     15   0 1522m 814m 9660 S  0.7 20.6   1:39.66 java

8009 admin     15   0 1522m 814m 9660 S  0.3 20.6   0:27.05 java

8040 admin     15   0 1522m 814m 9660 S  0.3 20.6   0:51.46 java

7978 admin     25   0 1522m 814m 9660 S  0.0 20.6   0:00.00 java

7980 admin     19   0 1522m 814m 9660 S  0.0 20.6   0:05.05 java

7981 admin     16   0 1522m 814m 9660 S  0.0 20.6   0:06.31 java

7982 admin     15   0 1522m 814m 9660 S  0.0 20.6   0:06.50 java

7983 admin     15   0 1522m 814m 9660 S  0.0 20.6   0:06.66 java

7984 admin     15   0 1522m 814m 9660 S  0.0 20.6   0:06.87 java

7985 admin     15   0 1522m 814m 9660 S  0.0 20.6   0:33.82 java

几个字段跟top的字段意思是一致的, 就是这里的 PID是 线程在系统里面的ID, 也就是进程每创建一个线程, 不仅进程自己会分配ID, 系统也会的. 接下来的问题排查就是主要根据这个PID来走的.

看到上面的部分数据, 当前正在跑的任务中, CPU占用最高的几个线程ID

2.4. 如果不借助工具, 自己分析的话, 可以把PID字段从10进制数改为 16进制, 然后到threaddump日志中去查找一把, 找对对应的线程上下文信息, 就可以知道哪段代码耗CPU最多了.

比如 8091  的16进制是 1F9B, 查找 thread dump 日志中, nid=0x1F9B 的线程( 这里的nid意思是nativeid, 也就是上面讲的系统为线程分配的ID), 然后找到相关的代码段, 进行优化即可.

比如

?


1

2

3

4

5

"链路检测" prio=10 tid=0x00002aaafa498000 nid=0x1F9B runnable [0x0000000045fac000..0x0000000045facd10]</div>

java.lang.Thread.State: RUNNABLE

at cn.emay.sdk.communication.socket.AsynSocket$CheckConnection.run(AsynSocket.java:112)

at java.lang.Thread.run(Thread.java:636)

可以看出, 这是一个 发短信的客户端的链路检测引擎的系统负载飙升. (实际上这个线程引起的负载绝不止这么一点.)

2.5 第三方的jar包, 我感到顿时泪奔. 接下来是反编译, 看详细的代码… 果然是有一段死循环监听的… 目前是像他们要一份SDK的源代码， 或者要他们进行优化。

2.6 使用工具的话, 可以看到更多一点的信息, java的tda工具就是专门分析thread dump的.

具体功能自己去挖掘啦.

时间： 2024-08-05 11:29:01

Java_tomcat thread dump 分析的相关文章

性能分析之-- JAVA Thread Dump 分析综述

性能分析之-- JAVA Thread Dump 分析综述 一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 T

性能分析之-- JAVA Thread Dump 分析综述【转】

一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 Thread Dump特点 1. 能在各种操作系统下使用 2.

通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码

http://heylinux.com/archives/1085.html通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码 首先,要感谢我的好朋友 钊花 的经验分享. 相信大家在实际的工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况. 通常这种情况发生时,我们会认为这些问题理所当然的该由开发人员自己去解决,因为操作系统环境是没有任何问题的. 但实际上,我们是可以帮助他们的,效果好的话还可以定位到具体出问题的代码行数,思路如下: 1.通过对CPU与内存的

tomcat thread dump 分析【转载】

前言 Java Thread Dump 是一个非常有用的应用诊断工具, 通过thread dump出来的信息, 可以定位到你需要了解的线程, 以及这个线程的调用栈. 如果配合linux的top命令, 可以找到你的系统中的最耗CPU的线程代码段, 这样才能有针对性地进行优化. 场景和实践 2.1. 后台系统一直是在黑盒运行, 除了能暂停一部分任务的执行, 根本无法知道哪些任务耗CPU过多.所以一直以为是业务代码的问题, 经过各种优化(删减没必要的逻辑, 合并写操作)等等优化, 系统负载还是很高.

三个实例演示 Java Thread Dump 日志分析

jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Object.wait() 或 TIMED_WAITING 阻塞,Blocked(重点关注)   停止,Parked 下面我们先从第一个例子开始分析,然后再列出不同线程

三个实例演示 Java Thread Dump 日志分析（转）

原文链接:http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html 转来当笔记^_^ jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象

[JAVA]JAVA章4 Thread Dump如何分析

一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 Thread Dump特点 1. 能在各种操作系统下使用 2.

转：Java - Heap Dump, Thread Dump and Core Dump

Dump 就是对程序运行时内存上的信息进行转储, 让我们可以查看程序当时的运行情况. Dump 对于调优和排错是非常有用的工具. Heap Dump Java 运行时对象分配在堆内存上, Heap dump 就是对堆内存进行转储. 生成 Heap dump 的生成有两种方式: 1) 运行 Java 程序时添加 -XX:+HeapDumpOnOutOfMemoryError 选项, 这样当程序发生 Out of Memory 错误时就会自动生成一份 Heap dump. 2) 使用 jmap 工具

JVM故障分析系列之四：jstack生成的Thread Dump日志线程状态

JVM故障分析系列之四:jstack生成的Thread Dump日志线程状态 2017年10月25日  Jet Ma  JavaPlatform JVM故障分析系列系列文章 JVM故障分析系列之一:使用jstack定位线程堆栈信息JVM故障分析系列之二:jstack生成的Thread Dump日志结构解析JVM故障分析系列之三:jstat命令的使用及VM Thread分析JVM故障分析系列之四:jstack生成的Thread Dump日志线程状态JVM故障分析系列之五:常见的Thread Dum