在編寫多線程代碼的時(shí)候經(jīng)常發(fā)生多個(gè)線程等待一個(gè)事件的情況。這種情況多發(fā)生于多個(gè)線程在同步方法或者同步塊內(nèi)調(diào)用wait方法等待同一個(gè)被鎖住的對(duì)象。當(dāng)另一個(gè)鎖住該對(duì)象的線程從同步方法或者同步塊中調(diào)用notify或者notifyAll方法時(shí)這些等待線程被喚醒。notify調(diào)用僅僅喚醒一個(gè)線程，因此如果有多個(gè)線程正處于等待狀態(tài)，那么不會(huì)有對(duì)鎖的競(jìng)爭(zhēng)。另一方面，notifyAll調(diào)用喚醒所有的等待線程而造成競(jìng)爭(zhēng)，然而只有一個(gè)線程能夠得到鎖，其它的都會(huì)被阻塞。

　　當(dāng)多個(gè)線程處于等待狀態(tài)時(shí)的問(wèn)題是當(dāng)調(diào)用notify或者notifyAll方法后哪一個(gè)線程將運(yùn)行？很多程序員不正確的假定存在一種預(yù)定義的順序表明線程如何被喚醒。一些認(rèn)為是高優(yōu)先級(jí)的線程首先被喚醒，另一些可能認(rèn)為是等待了最長(zhǎng)時(shí)間的線程首先被喚醒。不幸的是上面的假設(shè)都是不對(duì)的。在這些情況下，哪個(gè)線程被喚醒是不確定的，也許是最高優(yōu)先級(jí)的線程，也許是等待最長(zhǎng)的線程，但是沒有保證。

　　線程的優(yōu)先級(jí)不能決定它是否被喚醒（在使用notify方法的情況下）或者在多線程環(huán)境下的喚醒順序（在使用notifyAll方法的情況下）。因此，因此你永遠(yuǎn)不應(yīng)該假設(shè)線程的喚醒順序。另外，你也永遠(yuǎn)不應(yīng)該對(duì)搶占過(guò)程中的線程調(diào)度做任何假設(shè)。線程調(diào)度是實(shí)現(xiàn)相關(guān)的（implementation-dependent），不同的平臺(tái)的調(diào)度機(jī)制是不同的。如果你想你的程序具有可移植性就不應(yīng)該做這樣的不明智的假設(shè)。

　　另外，notifyAll和notify方法沒有提供喚醒等待進(jìn)程的確定順序，具體的順序是依賴JVM的，并且notifyAll所能保證的事情不超過(guò)喚醒所有的等待線程。這個(gè)狀況使得當(dāng)你想以某種特定的順序喚醒多個(gè)線程時(shí)會(huì)出現(xiàn)問(wèn)題。

　　有兩種辦法達(dá)到控制線程的喚醒順序:

　　1、使用精確喚醒模式
　　
　�。⊿pecific notification pattern）

　　2、使用實(shí)現(xiàn)了實(shí)時(shí)規(guī)范的JVM（RTSJ，Real-Time Specification for Java）（譯者注：這其實(shí)不應(yīng)該算一種好的方法，這加大了對(duì)特定JVM的依賴，打破了可移植性）

　　精確喚醒模式由Tom Cargill開發(fā)，詳細(xì)說(shuō)明了如何控制調(diào)用notify和notifyAll時(shí)的線程的喚醒順序。這個(gè)實(shí)現(xiàn)是通過(guò)對(duì)需要被一起喚醒的每個(gè)線程或者每一套線程設(shè)置一個(gè)單獨(dú)的鎖達(dá)到的。通過(guò)對(duì)特定的鎖進(jìn)行釋放而達(dá)到可定義的通知順序。

　　如果實(shí)現(xiàn)合適，那么這種模式的執(zhí)行代價(jià)是最小的。然而不可避免的要增加編碼的復(fù)雜性，但是這個(gè)復(fù)雜性可以通過(guò)你得到的控制性抵消掉，如果你需要這樣的控制，你可以考慮實(shí)現(xiàn)這個(gè)模式。

　　RTSJ改變了某些java語(yǔ)義的標(biāo)準(zhǔn)行為。其中之一就是確保等待線程按照優(yōu)先級(jí)排序。因此當(dāng)多個(gè)線程處于等待狀態(tài)而調(diào)用了notify或者notifyAll，那么具有最高優(yōu)先級(jí)的那個(gè)將首先執(zhí)行，其它的繼續(xù)等待。

　　通常，這不是推薦的做法，除非是進(jìn)行實(shí)時(shí)編程。已經(jīng)有幾種不同的折衷方案使得java可以進(jìn)行實(shí)時(shí)編程。創(chuàng)建RTSJ的最重要的一個(gè)原則就是及時(shí)性比執(zhí)行速度更重要！