jstack命令

最新推荐文章于 2025-04-19 17:34:48 发布

and1kaney

最新推荐文章于 2025-04-19 17:34:48 发布

阅读量3.3k

点赞数

分类专栏： Java

本文链接：https://blog.csdn.net/and1kaney/article/details/51214244

版权

Java 专栏收录该内容

15 篇文章

订阅专栏

jstack(Stack Trace for Java)命令用于生成JVM进程当前时刻的线程的调用堆栈，可以用来定位线程间死锁、锁等待、等待外部资源等

jstack 命令格式

jstack [option] pid

-F 当正常jstack正常的请求不被响应时，强制输出线程堆栈

-l 输出锁的附加信息

-m 如果调用本地方法，可以输出C/C++堆栈

线程状态（java.lang.Thread.State）

NEW:

未启动的线程的状态

RUNNABLE:

该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。

BLOCKED:

受阻塞并且正在等待监视器锁的某一线程的线程状态。

WAITING:

某一等待线程的线程状态。某一线程因为调用下列方法之一而处于等待状态：

不带超时值的 Object.wait
不带超时值的 Thread.join

TIMED_WAITING:

具有指定等待时间的某一等待线程的线程状态。某一线程因为调用以下带有指定正等待时间的方法之一而处于定时等待状态：

Thread.sleep
带有超时值的 Object.wait
带有超时值的 Thread.join

TERMINATED:

已终止线程的线程状态。线程已经结束执行。

线程信息中的waiting on condition、waiting for monitor entry 和 in Object.wait()

waiting on condition

该状态出现在线程等待某个条件的发生，比如等待IO、等待网络、等待sleep时间结束、wait时间结束等，具体等待的原因可以结合stack查看。

waiting for monitor entry与in Object.wait()

在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class对象的锁。每一个对象都有，也仅有一个 monitor。每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。
        先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像：
synchronized(obj) {
.........

}

这时有两种可能性：
     该 monitor不被其它线程拥有， Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码
     该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。

在第一种情况下，线程将处于 “Runnable”的状态，而第二种情况下，线程 DUMP会显示处于 “waiting for monitor entry”。

现在我们再来看现在线程为什么会进入 “Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于：

这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码：

 
 synchronized 
 (obj) { 

 
         
 ......... 

 
         
 obj.wait(); 

 
         
 ......... 

}

线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on <0xef63beb8> ）。
比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被 Notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。

jstack分析死锁的例子

public class DeadLockTest {
    public static void main(String[] args) {
        MyThread myThread = new MyThread();
        Thread thread1 = new Thread(myThread, "thread-1");
        Thread thread2 = new Thread(myThread, "thread-2");
        thread1.start();
        thread2.start();
    }
    private static class MyThread implements Runnable {
        private Object object1 = new Object();
        private Object object2 = new Object();
        public void methodA() {
            synchronized (object1) {
                synchronized (object2) {
                    System.out.println("Thread:" + Thread.currentThread().getName() + "invoke methodA");
                }
            }
        }
        public void methodB() {
            synchronized (object2) {
                synchronized (object1) {
                    System.out.println("Thread:" + Thread.currentThread().getName() + "invoke methodB");
                }
            }
        }
        @Override
        public void run() {
            for(int i = 0; i < 1000; i++) {
                methodA();
                methodB();
            }
        }
    }
}

当出现卡住的时候，jstack -l pid后可以直接看到jstack直接输出了死锁信息：