java分析dump文件_分析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啦)