分析java dump文件

注意，请不要被我误导，我没有看其他资料，这是我自己分析的，有些可能是不对的

 

"DestroyJavaVM" prio=6 tid=0x00316800 nid=0x448 waiting on condition [0x00000000

..0x00a0fd4c]

   java.lang.Thread.State: RUNNABLE

 

"Thread-1" prio=6 tid=0x02f85000 nid=0xd18 waiting for monitor entry [0x0319f000

..0x0319fd14]

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

        at xunlei.kkk.f2(TestLock.java:20)

        - waiting to lock <0x22ad0160> (a java.lang.Object)//在“入口区”等待获取<0x22ad0160>

        - locked <0x22ad0158> (a java.lang.Object)//获得了监视器<0x22ad0158>

        at xunlei.TestLock$2.run(TestLock.java:42)

 

"Thread-0" prio=6 tid=0x02bff400 nid=0xd40 waiting for monitor entry [0x02f4f000

..0x02f4fd94]

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

        at xunlei.kkk.f1(TestLock.java:9)

        - waiting to lock <0x22ad0158> (a java.lang.Object) 在“入口区”等待获取<0x22ad0158>

        - locked <0x22ad0160> (a java.lang.Object) //获得了监视器<0x22ad0160>

        at xunlei.TestLock$1.run(TestLock.java:35)

 

"A2" prio=6 tid=0x02c01400 nid=0xb0c in Object.wait() [0x02fef000..0x02fefa94]

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

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

        - waiting on <0x22a15d48> (a java.lang.Object)//在“等待区”等待获取<0x22a15d48>

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

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

"A1" prio=6 tid=0x02c00000 nid=0xf8 in Object.wait() [0x02f9f000..0x02f9fb14]

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

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

        - waiting on <0x22a15d48> (a java.lang.Object)

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

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

"A0" prio=6 tid=0x02c17800 nid=0xe68 in Object.wait() [0x02f4f000..0x02f4fb94]

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

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

        - waiting on <0x22a15d48> (a java.lang.Object)

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

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

 

在windows的cmd.exe中运行的java程序，按下ctrl+break，则会弹出此时程序的堆栈，上面显示了线程的几种状态

 

一、- locked <0x22ad0158> (a java.lang.Object)

线程获得了监视器<0x22ad0158>

 

二、- waiting to lock <0x22ad0160> (a java.lang.Object)

此线程不持有监视器<0x22ad0160>，但是它期待着获得监视器<0x22ad0160>

 

此线程是在“入口区”等待获取监视器<0x22ad0160>，即此线程不必等待其他线程执行<0x22ad0160>.notify()或<0x22ad0160>.notifyAll()，而是一旦<0x22ad0160>被其他线程释放掉（通过其他线程<0x22ad0160>.notify()或<0x22ad0160>.notifyAll()，或者其他线程<0x22ad0160>.wait()），此线程总是会去争抢<0x22ad0160>

 

三、- waiting on <0x22a15d48> (a java.lang.Object)

此线程刚刚执行了<0x22a15d48>.wait()后释放了监视器<0x22a15d48>，并期望再次获得<0x22a15d48>

此线程是在“等待区”等待获取监视器<0x22a15d48>，当然，再次获得时，需要其他线程调用<0x22a15d48>.notify()或<0x22a15d48>.notifyAll()，如果其他线程不调用<0x22a15d48>.notify()或<0x22a15d48>.notifyAll()，则此线程永远不会复活

 

在下面的语句中

       synchronized (obj) {// waiting to lock <0x22a15d48>

           while (!condition) {

              obj.wait();//waiting on <0x22a15d48>（不再持有监视器了，在“等待区”期待着再次获得监视器）

           }

           // do when condition is OK

       }

 

四、obj.wait()包含了两层含义：

1、  此线程释放了obj的监视器，即此线程现在已经不再持有obj的监视器啦

2、  在“等待区”等待着再次获取obj的监视器（其他线程必须调用obj.notify()或obj.notifyAll()，如果仅仅执行完成synchronized语句或synchronized块而没有调用obj.notify()或obj.notifyAll()，则“等待区”中的线程就永远不会苏醒）

 

五、线程的状态

1、  java.lang.Thread.State: RUNNABLE，此线程正在运行

2、  java.lang.Thread.State: WAITING，此线程位于“等待区”，等待其他线程调用<0x22a15d48>.notifyAll()，否则，这个线程永远不可能苏醒

3、  java.lang.Thread.State: BLOCKED，此线程位于“入口区”，且被阻塞了，在上面的例子中，死锁了，永远不会有解除block的机会（当然，在Java中，有些I/O方法也会阻塞的，不过，等到I/O完成后，就会自动解除block啦）