在编写多线程代码的时候经常发生多个线程等待一个事件的情况这种情况多发生于多个线程在同步方法或者同步块内调用wait方法等待同一个被锁住的对象当另一个锁住该对象的线程从同步方法或者同步块中调用notify或者notifyAll方法时这些等待线程被唤醒notify调用仅仅唤醒一个线程因此如果有多个线程正处于等待状态那么不会有对锁的竞争另一方面notifyAll调用唤醒所有的等待线程而造成竞争然而只有一个线程能够得到锁其它的都会被阻塞
当多个线程处于等待状态时的问题是当调用notify或者notifyAll方法后哪一个线程将运行？很多程序员不正确的假定存在一种预定义的顺序表明线程如何被唤醒一些认为是高优先级的线程首先被唤醒另一些可能认为是等待了最长时间的线程首先被唤醒不幸的是上面的假设都是不对的在这些情况下哪个线程被唤醒是不确定的也许是最高优先级的线程也许是等待最长的线程但是没有保证
线程的优先级不能决定它是否被唤醒（在使用notify方法的情况下）或者在多线程环境下的唤醒顺序（在使用notifyAll方法的情况下）因此因此你永远不应该假设线程的唤醒顺序另外你也永远不应该对抢占过程中的线程调度做任何假设线程调度是实现相关的（implementationdependent）不同的平台的调度机制是不同的如果你想你的程序具有可移植性就不应该做这样的不明智的假设
另外notifyAll和notify方法没有提供唤醒等待进程的确定顺序具体的顺序是依赖JVM的并且notifyAll所能保证的事情不超过唤醒所有的等待线程这个状况使得当你想以某种特定的顺序唤醒多个线程时会出现问题
有两种办法达到控制线程的唤醒顺序
使用精确唤醒模式
（Specific notification pattern）
使用实现了实时规范的JVM（RTSJRealTime Specification for Java）（译者注这其实不应该算一种好的方法这加大了对特定JVM的依赖打破了可移植性）
精确唤醒模式由Tom Cargill开发详细说明了如何控制调用notify和notifyAll时的线程的唤醒顺序这个实现是通过对需要被一起唤醒的每个线程或者每一套线程设置一个单独的锁达到的通过对特定的锁进行释放而达到可定义的通知顺序
如果实现合适那么这种模式的执行代价是最小的然而不可避免的要增加编码的复杂性但是这个复杂性可以通过你得到的控制性抵消掉如果你需要这样的控制你可以考虑实现这个模式
RTSJ改变了某些java语义的标准行为其中之一就是确保等待线程按照优先级排序因此当多个线程处于等待状态而调用了notify或者notifyAll那么具有最高优先级的那个将首先执行其它的继续等待
通常这不是推荐的做法除非是进行实时编程已经有几种不同的折衷方案使得java可以进行实时编程创建RTSJ的最重要的一个原则就是及时性比执行速度更重要！
