四，JVM 自带命令行工具之JStack

jstack（stack trace for java） 命令

用于查看虚拟机当前时刻的线程快照（一般称为threaddump或者javacore文件）。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间的停顿原因。

 用Jstack分析死锁(以下代码将产生死锁)

Java虚拟机死锁发生时，从操作系统上观察，虚拟机的CPU占用率为零，很快会从top或prstat的输出中消失。这时就可以收集thread dump了。

在thread dump中查找"waiting for monitor entry"的thread，如果大量thread都在等待给同一个地址上锁（因为对于Java，一个对象只有一把锁），这说明很可能死锁发生了。

在jdk1.5中会有更明显的死锁提示，下面的图中会看到。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class App {
    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(2);
        Object o1 = new Object();
        Object o2 = new Object();
        executorService.execute(new DeadThread1(o1, o2));
        executorService.execute(new DeadThread2(o1, o2));
    }
    public static class DeadThread1 implements Runnable {
        private Object o1;
        private Object o2;
        public DeadThread1(Object o1, Object o2) {
            this.o1 = o1;
            this.o2 = o2;
        }
        public void run() {
            synchronized (o1) {//先锁o1
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (o2) {
                    System.out.println(Thread.currentThread().getName() + "is done!!");
                }
            }
        }
    }
    public static class DeadThread2 implements Runnable {
        private Object o1;
        private Object o2;
        public DeadThread2(Object o1, Object o2) {
            this.o1 = o1;
            this.o2 = o2;
        }
        public void run() {
            synchronized (o2) {//先锁o2
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (o1) {
                    System.out.println(Thread.currentThread().getName() + "is done!!");
                }
            }
        }
    }
}

使用jps查到进程号

使用jstack 4546或jstack 4536 >dumpthread.txt查看此进程的线程堆栈，由于以上代码中两个线程争用o1,o2两个锁，因此可以看到threaddump中线程死锁提示，如下图。

或者通过jconsole来分析

点击检测死锁

可以看到具体阻塞的线程

附jstack中线程状态的解释：
NEW
public static final Thread.State NEW至今尚未启动的线程的状态。

RUNNABLE
public static final Thread.State RUNNABLE可运行线程的线程状态。处于可运行状态的某一线程正在 Java 虚拟机中运行，但它可能正在等待操作系统中的其他资源，比如处理器。

BLOCKED
public static final Thread.State BLOCKED受阻塞并且正在等待监视器锁的某一线程的线程状态。处于受阻塞状态的某一线程正在等待监视器锁，以便进入一个同步的块/方法，或者在调用 Object.wait 之后再次进入同步的块/方法。

WAITING
public static final Thread.State WAITING某一等待线程的线程状态。某一线程因为调用下列方法之一而处于等待状态：
①不带超时值的 Object.wait
②不带超时值的 Thread.join
③LockSupport.park
处于等待状态的线程正等待另一个线程，以执行特定操作。 例如，已经在某一对象上调用了 Object.wait() 的线程正等待另一个线程，以便在该对象上调用 Object.notify() 或 Object.notifyAll()。已经调用了 Thread.join() 的线程正在等待指定线程终止。

TIMED_WAITING

在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。下 面这个图，描述了线程和 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”。如下所示： 
"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8] 
at testthread.WaitThread.run(WaitThread.java:39) 
- waiting to lock <0xef63bf08> (a java.lang.Object) 
- locked <0xef63beb8> (a java.util.ArrayList) 
at java.lang.Thread.run(Thread.java:595) 
临界区的设置，是为了保证其内部的代码执行的原子性和完整性。但是因为临界区在任何时间只允许线程串行通过，这 和我们多线程的程序的初衷是相反的。 如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP中发现了这个情况，应该审查源码，改进程序。

现在我们再来看现在线程为什么会进入 “Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于： 
        "Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38] 
        at java.lang.Object.wait(Native Method) 
        - waiting on <0xef63beb8> (a java.util.ArrayList) 
        at java.lang.Object.wait(Object.java:474) 
        at testthread.MyWaitThread.run(MyWaitThread.java:40) 
        - locked <0xef63beb8> (a java.util.ArrayList) 
        at java.lang.Thread.run(Thread.java:595) 
  
仔细观察上面的 DUMP信息，你会发现它有以下两行： 
- locked <0xef63beb8> (a java.util.ArrayList) 
- waiting on <0xef63beb8> (a java.util.ArrayList) 
这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码： 
        synchronized(obj) { 
               ......... 
               obj.wait(); 
               ......... 
        } 
线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on <0xef63beb8> ）。 
往往在你的程序中，会出现多个类似的线程，他们都有相似的 DUMP信息。这也可能是正常的。比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被 Notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。

public static final Thread.State TIMED_WAITING具有指定等待时间的某一等待线程的线程状态。某一线程因为调用以下带有指定正等待时间的方法之一而处于定时等待状态：
①Thread.sleep
②带有超时值的 Object.wait
③带有超时值的 Thread.join
④LockSupport.parkNanos
⑤LockSupport.parkUntil

TERMINATED
public static final Thread.State TERMINATED已终止线程的线程状态。线程已经结束执行

其它参考资料

http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html