java thread dump 分析_如何分析thread dump | 学步园

JVM thread Dump

jvm thread dump是给定时间所有被创建的Java线程的快照。每个Java线程会给出以下信息:

1)thread name:通常被中间件提供商使用来标记伴随相关线程池名字和状态的线程ID。

2)thread type&priority:例如daemon prio=3 ***,中间间典型创建它们线程作为守护线程,意味着这些线程在后台运行,给java ee application提供服务。

3)Java thread ID:例如tid=0x000000011e52a800 ***,这是Java线程ID,通过java.lang.Thread.getId(),通常用自增方式实现。

4)Native Thread ID:例如nid=0x251c ***,当本地线程ID

5)Java Thread State and detail:例如waiting for moniter entry[0xfffffffea5afb000] java.lang.Thread.state:Blocked(on object moniter),允许快速了解线程状态和它的潜在当前阻塞条件。

6)Java thread statck trace:到目前为止这是最重要的数据。Java stack trace提供了大部分信息来精确定位问题根源。

7)Java Heap breakdown:从jdk1.6开始在thread dump快照底部可以找到崩溃点的内存空间利用情况:YongGen,OldGen和PermGen。Heap

PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)

eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)

from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)

to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)

PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)

object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)

PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)

object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)

Thread Dump breakdown overview

1358319103_3194.png

从HotSpot VM thread dump中可以发现有多个信息块。

Full thread dump identifier

一旦生成一个thread dump(kill -3 pid),就可以在中间间或单机Java标准输出日之中找到一个唯一关键字。Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):

Java EE middleware, third party & custom application Threads

此部分是thread dump的核心,大部分分析时间都会消费在此。发现多少个线程依赖于你使用的中间件,第三方库和你的application。

在我们的样例中,Weblogic被使用,这有一个唯一标识"weblogic.kernel.Default (self-tuning)"。"[STANDBY] ExecuteThread: '414' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000]

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

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

- waiting on <0xffffffff27d44de0> (a weblogic.work.ExecuteThread)

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

at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160)

- locked <0xffffffff27d44de0> (a weblogic.work.ExecuteThread)

at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

HotSpot VM Thread

被HotSpot VM管理的内部线程为了完成内部本地操作,一般来说不需要担心它们,除非CPU很高。"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition

HotSpot GC Thread

当使用HotSpot parallel GC,HotSpot VM默认创建一定数目的GC thread。"GC task thread#0 (ParallelGC)" prio=3 tid=0x0000000100120000 nid=0x3 runnable

"GC task thread#1 (ParallelGC)" prio=3 tid=0x0000000100131000 nid=0x4 runnable

………………………………………………………………………………………………………………………………………………………………

当面对过多GC,内存泄露等问题时,这些是关键的数据。使用native id,可以将从OS/Java进程观测到的高CPU与这些线程关联起来。

JNI global references count

JNI global reference是基本的对象引用,从本地代码到被Java GC管理的Java对象的引用。其角色是阻止仍然被本地代码使用的对象集合,但在Java代码中没有引用。

在探测JNI相关内存泄露时,关注JNI references很重要。如果你的程序直接使用JNI或使用第三方工具,如检测工具,检测本地内存泄露。JNI global references: 1925

Java Heap utilization view

Heap

PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)

eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)

from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)

to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)

PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)

object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)

PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)

object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java Thread Dump 是一个非常有用的工具,它可以帮助开发人员分析 Java 应用程序中的线程问题和死锁。下面是分析 Java Thread Dump 的一些步骤: 1. 获取 Java Thread Dump - 在 Linux 或 Unix 系统上,可以使用 jstack 命令来获取 Java Thread Dump。例如,使用以下命令获取正在运行的 Java 应用程序的 Thread Dump: ``` jstack -l <pid> ``` 这里的 `<pid>` 是 Java 应用程序的进程 ID。 - 在 Windows 系统上,可以使用 jps 命令来获取 Java 应用程序的进程 ID,然后使用 jstack 命令来获取 Java Thread Dump。例如,使用以下命令获取正在运行的 Java 应用程序的 Thread Dump: ``` jstack -l <pid> ``` 2. 分析 Java Thread Dump 一旦获取了 Java Thread Dump,就可以开始分析它了。通常,可以使用以下步骤来分析 Thread Dump: - 找到死锁情况:在 Thread Dump 中查找线程状态为 BLOCKED 的线程,这些线程可能是死锁的线程。 - 查找 CPU 密集型线程:在 Thread Dump 中查找 CPU 使用率高的线程,这些线程可能是导致应用程序性能下降的原因。 - 查找等待线程:在 Thread Dump 中查找线程状态为 WAITING 或 TIMED_WAITING 的线程,这些线程可能正在等待某个资源或锁。 - 查找异常:在 Thread Dump 中查找线程状态为 RUNNABLE 的线程,这些线程可能正在抛出异常。 3. 解决线程问题 分析 Java Thread Dump 后,可以采取以下措施来解决线程问题: - 修复死锁:找到死锁的线程并释放锁,或者重新设计代码以避免死锁情况。 - 优化性能:找到 CPU 密集型线程并优化它们的代码,或者调整线程池的大小以提高应用程序的性能。 - 解决等待问题:找到等待资源或锁的线程并释放它们,或者重新设计代码以避免等待问题。 - 处理异常:找到抛出异常的线程并修复代码中的错误。 总之,Java Thread Dump 是一个非常有用的工具,可以帮助开发人员快速定位和解决 Java 应用程序中的线程问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值