jstack和线程dump分析

最新推荐文章于 2025-06-15 16:43:04 发布

西门吹雪碧

最新推荐文章于 2025-06-15 16:43:04 发布

阅读量338

点赞数

本文介绍jstack工具的基本使用方法及如何通过线程Dump定位死锁等问题。jstack是Java虚拟机自带的堆栈跟踪工具，可用于生成线程快照，分析线程状态，如死锁、等待资源等情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

摘要： jstack和线程dump分析 jstack定义： jstack是java虚拟机自带的一种堆栈跟踪工具。基本介绍： jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。

jstack和线程dump分析

jstack定义：

jstack是java虚拟机自带的一种堆栈跟踪工具。

基本介绍：

jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。

线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

命令格式：

jstack [ option ] pid

基本参数：

-F 当’jstack [-l] pid’没有相应的时候强制打印栈信息

-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表.

-m 打印java和native c/c++框架的所有栈信息. -h | -help打印帮助信息

pid 需要被打印配置信息的java进程id,可以用jps工具查询

案例

C:\Users\Administrator>jstack  5516
2015-12-21 16:10:53
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

"DestroyJavaVM" prio=6 tid=0x000000000027d800 nid=0x1bb0 waiting on condition [0
x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" prio=6 tid=0x000000000cb13800 nid=0x19ac waiting for monitor entry [0
x000000000d67f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at thread.DeadLockDemo$2.run(DeadLockDemo.java:35)
        - waiting to lock <0x00000007d5a9be88> (a java.lang.String)
        - locked <0x00000007d5a9beb8> (a java.lang.String)
        at java.lang.Thread.run(Unknown Source)

"Thread-0" prio=6 tid=0x000000000cb0e800 nid=0x6bc waiting for monitor entry [0x
000000000d48f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at thread.DeadLockDemo$1.run(DeadLockDemo.java:21)
        - waiting to lock <0x00000007d5a9beb8> (a java.lang.String)
        - locked <0x00000007d5a9be88> (a java.lang.String)
        at java.lang.Thread.run(Unknown Source)

这里运行了一段死锁code，导致程序中的两个线程都在等待对方释放锁，造成程序死锁。

从这段代码中可以明确的看出是 DeadLockDemo.class 中的第35行，和21行出现了阻塞，然后就是要优化这个函数了。

PS : 在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。