jvm线程状态的流转

最初是有这样一个疑问：

“使用concurrent包里的lock和传统的synchronized相比，等在同步块之外的线程处于一样的状态吗？是blocked还是waiting？两者貌似都是线程处于等待状态，有何区别？”

看图说话：

因为lock的实现是通过LockSupport.park()方法，因此结论是：

传统synchro块：blcoked

lock：waitting

有什么区别呢？

waiting必须等待notify或者notifyAll被触发时才会被唤醒，重新开始临界区（monitor）的争夺；而block是多个线程僵在临界区门口随时准备展开争夺。

且一旦进入waiting状态便会暂时释放已经获取的所有monitors，唤醒后要重新尝试一个个取回。

（详见What is Thread.State in Java? What's it used for?）

通俗点打个比方，

n个人各自从家里出发开车去公司，抢同一间办公室。

车开到大门口，门卫会发临时停车许可证。没抢到车位的人，不允许进入；

成功进入公司的人，也只有一位能抢到办公室的使用权。

接下来，被堵在办公室门口，打算等上一位出来就立刻夺门而入的，叫blocking状态；

眼看着办公室会被占用一整天，放弃争夺回家等通知的，叫waitting状态。（注意回家等通知，意味着离开公司，出门会顺便归还临时停车许可证。）

可见，临界区流转得余越不频繁，block的线程越多，徒耗在上下文切换上的资源浪费就越严重；

反之，临界区流转得很快，block的线程也不多的话，block对于临界区的利用率则更高。

映射回上面的例子，如果临界区从办公室换成洗手间，等几分钟里面的人就出来了，肯定会选block。

============分割线==============

天下武功出少林，看完java的线程状态流转，再来看看linux的情况，

注意到，除了就绪和运行，等待(休眠)状态被分为可中断interruptible和不可中断uninterruptible两种。对磁盘文件的IO动作便会触发后者。

线程等待（休眠）的本质是被移出线程的run queue，从而无法被scheduler调度到。参见：Kernel Korner - Sleeping in the Kernel

再看一眼.net clr的线程状态流转：

msdn上，从.net 1.0 到 4.0 线程状态枚举就没改动过，相当的稳定。

.net 的设计里，所有的等待状态被归结在一起，叫waitSleepJoin（还真是直白）。