注意，请不要被我误导，我没有看其他资料，这是我自己分析的，有些可能是不对的
| "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啦）
http://blog.csdn.net/iceman1952/article/details/5526430
http://blog.csdn.net/kobejayandy/article/details/9132927
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0903_suipf_javadump/
