7 个抓取 Java Thread Dumps 的方式

1. jstack

jstack 是一个抓取 thread dump 文件的有效的命令行工具,它位于 JDK 目录里的 bin 文件夹下(JDK_HOME\bin),以下是抓取 dump 文件的命令:

jstack -l  <pid> > <file-path>

说明:

  • pid: Java 应用的进程 id ,也就是需要抓取 dump 文件的应用进程 id。

  • file-path: 保存 dump 文件的路径。

示例:

jstack -l 37320 > /opt/tmp/threadDump.txt

上面的例子演示了用 jstack 生成 dump 文件到 /opt/tmp/threadDump.txt 目录下。

从 Java5 开始,jstack 被包含进了 jdk 当中,如果你使用老版本的 jdk,要考虑使用其他方式。

2. Kill -3

处于安全方面的考虑,有一部分生产环境的机器只包含 JRE 环境,因此就不能使用 jstack 工具了,在这种情况下,我们可以使用 kill -3 的方式:

kill -3 <pid>

说明:

  • pid: Java 应用的进程 id ,也就是需要抓取 dump 文件的应用进程 id 。

示例:

kill -3 37320

当使用 kill -3 生成 dump 文件时,dump 文件会被输出到标准错误流。假如你的应用运行在 tomcat 上,dump 内容将被发送到<TOMCAT_HOME>/logs/catalina.out 文件里。

3. JVisualVM

Java VisualVM 是一个可以提供 JVM 信息的图形界面工具。它位于 JDK_HOME\bin\jvisualvm.exe 文件里。从 JDK6 Update7 开始,它被包含进 JDK 里。

运行 jvisualvm,在左侧面板中(如下图所示),列出了运行的 JVM 信息,这个工具可以从本地或者远程运行的 JVM 里抓取 dump 文件。

点击上图的进程名称对应的 Thread Dump 按钮,将会生成 dump 文件,如下图所示:

4. JMC

Java Mission Control (JMC) 是一个能从本地或生产环境中收集和分析数据的工具,从 Oracle JDK 7 Update 40 开始,它被包含进 JDK 里,它可以从 JVM 里生成 dump 文件。JMC 位于 JDK_HOME\bin\jmc.exe 文件里:

运行该工具之后,你可以看到运行在本地的 Java 进程,它也可以连接到远程机器。双击你想要生成 dump 文件的 Java 进程,点击Flight Recorder,你会看到以下的对话框:

Thread Dump 下拉框,你可以选择生成 dump 文件的时间间隔。在上面的例子里,每隔60秒将会生成一个 dump 文件。选择完成之后启动 Flight recorder ,可以在 Threads 面板看到 dump 文件的内容:

5. Windows (Ctrl + Break)

这种方式仅仅在 Windows 操作系统上有效:

  • 在控制台窗口上选中命令行

  • 在命令行窗口上按 “Ctrl + Break” 命令

然后会生成 dump 文件,dump 文件的内容会被打印在命令行窗口上。

注意1: 有几款笔记本(比如 Lenovo T 系列)已经取消了 “Break” 键,在这种情况下你不得不用谷歌搜索与 Break 键功能类似的键,我发现 “Function key + B” 键与 Break 键的功能相同,因此我用 “Ctrl + Fn + B” 键来生成 dump 文件。

注意2: 用上述方式有一个缺点就是 dump 文件的内容会被打印到控制台上,没有 dump 文件的话,我们很难用分析工具比如http://fasthread.io来分析 dump 文件。因此你可以使用以下命令将 dump 文件的内容输出到文本文件当中,比如你的应用程序名字叫 SampleThreadProgram ,那么通常使用的命令如下:

java -classpath . SampleThreadProgram

将 dump 文件的内容输出到文本文件的命令如下:

java -classpath . SampleThreadProgram > C:\workspace\threadDump.txt 2>&1

当你按下 “Ctrl + Break” 键之后,dump 文件会被保存到 C:\workspace\threadDump.txt 里。

6. ThreadMXBean

从 JDK 1.5 开始,ThreadMXBean 被引入。这是 JVM 的管理接口,使用这个接口你仅需要少量的代码就能生成 dump 文件,以下是使用 ThreadMXBean 生成 dump 文件的主要实现:

public void  dumpThreadDump() {
   ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
   for (ThreadInfo ti : threadMxBean.dumpAllThreads(true, true)) {
       System.out.print(ti.toString());
   }
}

7. APM Tool – App Dynamics

一些应用性能监控工具提供了生成 dump 文件的功能,如果你使用 App Dynamics 监控你的应用,以下就是生成 dump 文件的步骤:

  1. 打开创建动作窗口,在创建动作窗口中选择 Diagnostics->Take a thread dump;

  2. 输入动作名称、抓取 dump 文件的数量、抓取 dump 文件的时间间隔(毫秒);

  3. 如果你想在抓取 dump 动作开始之前执行一些操作,那么你可以选中 Require approval executing before this Action 这个复选框,然后输入个人或小组的 email 地址;

  4. 点击 OK.

总结

尽管我在前面列出了7种抓取 dump 文件的方式,但恕我直言,jstackkill -3 是最好的选择,原因如下:

a. 简单,容易实现;

b. 通用:在大多数情况下,不管操作系统类型、Java 厂商、JVM 版本等等。

编译自:https://dzone.com/articles/how-to-take-thread-dumps-7-options

作者:九州暮云

  • 14
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 runnable 一般指该线程正在执行状态中,该线程占用了资源,正在处理某个操作,如通过SQL语句查询数据库、对某个文件进行写入等。 blocked 线程正处于阻塞状态,指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。 waiting on condition 线程正处于等待资源或等待某个条件的发生,具体的原因需要结合下面堆栈信息进行分析。 (1)如果堆栈信息明确是应用代码,则证明该线程正在等待资源,一般是大量读取某种资源且该资源采用了资源锁的情况下,线程进入等待状态,等待资源的读取,或者正在等待其他线程的执行等。 (2)如果发现有大量的线程都正处于这种状态,并且堆栈信息中得知正等待网络读写,这是因为网络阻塞导致线程无法执行,很有可能是一个网络瓶颈的征兆: 网络非常繁忙,几乎消耗了所有的带宽,仍然有大量数据等待网络读写; 网络可能是空闲的,但由于路由或防火墙等原因,导致包无法正常到达; 所以一定要结合系统的一些性能观察工具进行综合分析,比如netstat统计单位时间的发送包的数量,看是否很明显超过了所在网络带宽的限制;观察CPU的利用率,看系统态的CPU时间是否明显大于用户态的CPU时间。这些都指向由于网络带宽所限导致的网络瓶颈。 (3)还有一种常见的情况是该线程在 sleep,等待 sleep 的时间到了,将被唤醒。 waiting for monitor entry 或 in Object.wait() Moniter 是Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者class的锁,每个对象都有,也仅有一个 Monitor。 从上图可以看出,每个Monitor在某个时刻只能被一个线程拥有,该线程就是 "Active Thread",而其他线程都是 "Waiting Thread",分别在两个队列 "Entry Set"和"Waint Set"里面等待。其中在 "Entry Set" 中等待的线程状态是 waiting for monitor entry,在 "Wait Set" 中等待的线程状态是 in Object.wait()。 (1)"Entry Set"里面的线程。 我们称被 synchronized 保护起来的代码段为临界区,对应的代码如下: synchronized(obj){} 当一个线程申请进入临界区时,它就进入了 "Entry Set" 队列中,这时候有两种可能性: 该Monitor不被其他线程拥有,"Entry Set"里面也没有其他等待的线程。本线程即成为相应类或者对象的Monitor的Owner,执行临界区里面的代码;此时在Thread Dump中显示线程处于 "Runnable" 状态。 该Monitor被其他线程拥有,本线程在 "Entry Set" 队列中等待。此时在Thread Dump中显示线程处于 "waiting for monity entry" 状态。 临界区的设置是为了保证其内部的代码执行的原子性和完整性,但因为临界区在任何时间只允许线程串行通过,这和我们使用多线程的初衷是相反的。如果在多线程程序中大量使用synchronized,或者不适当的使用它,会造成大量线程在临界区的入口等待,造成系统的性能大幅下降。如果在Thread Dump中发现这个情况,应该审视源码并对其进行改进。 (2)"Wait Set"里面的线程 当线程获得了Monitor,进入了临界区之后,如果发现线程继续运行的条件没有满足,它则调用对象(通常是被synchronized的对象)的wait()方法,放弃Monitor,进入 "Wait Set"队列。只有当别的线程在该对象上调用了 notify()或者notifyAll()方法,"Wait Set"队列中的线程才得到机会去竞争,但是只有一个线程获得对象的Monitor,恢复到运行态。"Wait Set"中的线程在Thread Dump中显示的状态为 in Object.wait()。通常来说, 通常来说,当CPU很忙的时候关注 Runnable 状态的线程,反之则关注 waiting for monitor entry 状态的线程。 JVM线程运行状态 (JVM Thread Status)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

锋西

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值