破除java神话之线程按优先级唤醒

核心提示：在编写多线程代码的时候经常发生多个线程等待一个事件的情况，这种情况多发生于多个线程在同步方法或者同步块内调用wait方法等待同一个被锁住的对象，破除java神话之线程按优先级唤醒，当另一个锁住该对象的线程从同步方法或者同步块中调用notify或者notifyAll方法时这些等待线程被唤醒，

　　在编写多线程代码的时候经常发生多个线程等待一个事件的情况。这种情况多发生于多个线程在同步方法或者同步块内调用wait方法等待同一个被锁住的对象。当另一个锁住该对象的线程从同步方法或者同步块中调用notify或者notifyAll方法时这些等待线程被唤醒。 notify调用仅仅唤醒一个线程，因此假如有多个线程正处于等待状态，那么不会有对锁的竞争。另一方面，notifyAll调用唤醒所有的等待线程而造成竞争，然而只有一个线程能够得到锁，其它的都会被阻塞。

　　当多个线程处于等待状态时的问题是当调用notify或者notifyAll方法后哪一个线程将运行？很多程序员不正确的假定存在一种预定义的顺序表明线程如何被唤醒。一些认为是高优先级的线程首先被唤醒，另一些可能认为是等待了最长时间的线程首先被唤醒。不幸的是上面的假设都是不对的。在这些情况下，哪个线程被唤醒是不确定的，也许是最高优先级的线程，也许是等待最长的线程，但是没有保证。

　　线程的优先级不能决定它是否被唤醒（在使用notify方法的情况下）或者在多线程环境下的唤醒顺序（在使用notifyAll方法的情况下）。因此，因此你永远不应该假设线程的唤醒顺序。另外，你也永远不应该对抢占过程中的线程调度做任何假设。线程调度是实现相关的（implementation-dependent），不同的平台的调度机制是不同的。假如你想你的程序具有可移植性就不应该做这样的不明智的假设。

　　另外，notifyAll和notify方法没有提供唤醒等待进程的确定顺序，具体的顺序是依靠JVM的，并且notifyAll所能保证的事情不超过唤醒所有的等待线程。这个状况使得当你想以某种特定的顺序唤醒多个线程时会出现问题。

　　有两种办法达到控制线程的唤醒顺序:

　　1、使用精确唤醒模式
　　
　　（Specific notification pattern）

　　2、使用实现了实时规范的JVM（RTSJ，Real-Time Specification for java）（译者注：这其实不应该算一种好的方法，这加大了对特定JVM的依靠，打破了可移植性）

　　精确唤醒模式由Tom Cargill开发，具体说明了如何控制调用notify和notifyAll时的线程的唤醒顺序。这个实现是通过对需要被一起唤醒的每个线程或者每一套线程设置一个单独的锁达到的。通过对特定的锁进行释放而达到可定义的通知顺序。

　　假如实现合适，那么这种模式的执行代价是最小的。然而不可避免的要增加编码的复杂性，但是这个复杂性可以通过你得到的控制性抵消掉，假如你需要这样的控制，你可以考虑实现这个模式。

　　RTSJ改变了某些java语义的标准行为。其中之一就是确保等待线程按照优先级排序。因此当多个线程处于等待状态而调用了notify或者notifyAll，那么具有最高优先级的那个将首先执行，其它的继续等待。

　　通常，这不是推荐的做法，除非是进行实时编程。已经有几种不同的折衷方案使得java可以进行实时编程。创建RTSJ的最重要的一个原则就是及时性比执行速度更重要！