注意,请不要被我误导,我没有看其他资料,这是我自己分析的,有些可能是不对的
"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啦)