天天看點

java多線程-線程通信

線程通信的目标是使線程間能夠互相發送信号。另一方面,線程通信使線程能夠等待其他線程的信号。

通過共享對象通信

忙等待

wait(),notify()和 notifyAll()

丢失的信号

假喚醒

多線程等待相同信号

不要對常量字元串或全局對象調用 wait()

線程間發送信号的一個簡單方式是在共享對象的變量裡設定信号值。線程 A 在一個同步塊裡設定 boolean 型成員變量 hasDataToProcess 為 true,線程 B 也在同步塊裡讀取 hasDataToProcess 這個成員變量。這個簡單的例子使用了一個持有信号的對象,并提供了 set 和 check 方法:

java多線程-線程通信
java多線程-線程通信

線程 A 和 B 必須獲得指向一個 MySignal 共享執行個體的引用,以便進行通信。如果它們持有的引用指向不同的 MySingal 執行個體,那麼彼此将不能檢測到對方的信号。需要處理的資料可以存放在一個共享緩存區裡,它和 MySignal 執行個體是分開存放的。

準備處理資料的線程 B 正在等待資料變為可用。換句話說,它在等待線程 A 的一個信号,這個信号使 hasDataToProcess()傳回 true。線程 B 運作在一個循環裡,以等待這個信号:

java多線程-線程通信
java多線程-線程通信

忙等待沒有對運作等待線程的 CPU 進行有效的利用,除非平均等待時間非常短。否則,讓等待線程進入睡眠或者非運作狀态更為明智,直到它接收到它等待的信号。

Java 有一個内建的等待機制來允許線程在等待信号的時候變為非運作狀态。java.lang.Object 類定義了三個方法,wait()、notify()和 notifyAll()來實作這個等待機制。

一個線程一旦調用了任意對象的 wait()方法,就會變為非運作狀态,直到另一個線程調用了同一個對象的 notify()方法。為了調用 wait()或者 notify(),線程必須先獲得那個對象的鎖。也就是說,線程必須在同步塊裡調用 wait()或者 notify()。以下是 MySingal 的修改版本——使用了 wait()和 notify()的 MyWaitNotify:

java多線程-線程通信
java多線程-線程通信

等待線程将調用 doWait(),而喚醒線程将調用 doNotify()。當一個線程調用一個對象的 notify()方法,正在等待該對象的所有線程中将有一個線程被喚醒并允許執行(校注:這個将被喚醒的線程是随機的,不可以指定喚醒哪個線程)。同時也提供了一個 notifyAll()方法來喚醒正在等待一個給定對象的所有線程。

如你所見,不管是等待線程還是喚醒線程都在同步塊裡調用 wait()和 notify()。這是強制性的!一個線程如果沒有持有對象鎖,将不能調用 wait(),notify()或者 notifyAll()。否則,會抛出 IllegalMonitorStateException 異常。

(校注:JVM 是這麼實作的,當你調用 wait 時候它首先要檢查下目前線程是否是鎖的擁有者,不是則抛出 IllegalMonitorStateExcept。)

但是,這怎麼可能?等待線程在同步塊裡面執行的時候,不是一直持有螢幕對象(myMonitor 對象)的鎖嗎?等待線程不能阻塞喚醒線程進入 doNotify()的同步塊嗎?答案是:的确不能。一旦線程調用了 wait()方法,它就釋放了所持有的螢幕對象上的鎖。這将允許其他線程也可以調用 wait()或者 notify()。

一旦一個線程被喚醒,不能立刻就退出 wait()的方法調用,直到調用 notify()的

java多線程-線程通信
java多線程-線程通信

線程退出了它自己的同步塊。換句話說:被喚醒的線程必須重新獲得螢幕對象的鎖,才可以退出 wait()的方法調用,因為 wait 方法調用運作在同步塊裡面。如果多個線程被 notifyAll()喚醒,那麼在同一時刻将隻有一個線程可以退出 wait()方法,因為每個線程在退出 wait()前必須獲得螢幕對象的鎖。

notify()和 notifyAll()方法不會儲存調用它們的方法,因為當這兩個方法被調用時,有可能沒有線程處于等待狀态。通知信号過後便丢棄了。是以,如果一個線程先于被通知線程調用 wait()前調用了 notify(),等待的線程将錯過這個信号。這可能是也可能不是個問題。不過,在某些情況下,這可能使等待線程永遠在等待,不再醒來,因為線程錯過了喚醒信号。

為了避免丢失信号,必須把它們儲存在信号類裡。在 MyWaitNotify 的例子中,通知信号應被存儲在 MyWaitNotify 執行個體的一個成員變量裡。以下是 MyWaitNotify 的修改版本:

java多線程-線程通信
java多線程-線程通信

留意 doNotify()方法在調用 notify()前把 wasSignalled 變量設為 true。同時,留意 doWait()方法在調用 wait()前會檢查 wasSignalled 變量。事實上,如果沒有信号在前一次 doWait()調用和這次 doWait()調用之間的時間段裡被接收到,它将隻調用 wait()。

(校注:為了避免信号丢失, 用一個變量來儲存是否被通知過。在 notify 前,設定自己已經被通知過。在 wait 後,設定自己沒有被通知過,需要等待通知。)

由于莫名其妙的原因,線程有可能在沒有調用過 notify()和 notifyAll()的情況下醒來。這就是所謂的假喚醒(spurious wakeups)。無端端地醒過來了。

如果在 MyWaitNotify2 的 doWait()方法裡發生了假喚醒,等待線程即使沒有收到正确的信号,也能夠執行後續的操作。這可能導緻你的應用程式出現嚴重問題。

為了防止假喚醒,儲存信号的成員變量将在一個 while 循環裡接受檢查,而不是在 if 表達式裡。這樣的一個 while 循環叫做自旋鎖(校注:這種做法要慎重,目前的 JVM 實作自旋會消耗 CPU,如果長時間不調用 doNotify 方法,doWait 方法會一直自旋,CPU 會消耗太大)。被喚醒的線程會自旋直到自旋鎖(while 循環)裡的條件變為 false。以下 MyWaitNotify2 的修改版本展示了這點:

java多線程-線程通信
java多線程-線程通信

留意 wait()方法是在 while 循環裡,而不在 if 表達式裡。如果等待線程沒有收到信号就喚醒,wasSignalled 變量将變為 false,while 循環會再執行一次,促使醒來的線程回到等待狀态。

如果你有多個線程在等待,被 notifyAll()喚醒,但隻有一個被允許繼續執行,使用 while 循環也是個好方法。每次隻有一個線程可以獲得螢幕對象鎖,意味着隻有一個線程可以退出 wait()調用并清除 wasSignalled 标志(設為 false)。一旦這個線程退出 doWait()的同步塊,其他線程退出 wait()調用,并在 while 循環裡檢查 wasSignalled 變量值。但是,這個标志已經被第一個喚醒的線程清除了,是以其餘醒來的線程将回到等待狀态,直到下次信号到來。

(校注:本章說的字元串常量指的是值為常量的變量)

本文早期的一個版本在 MyWaitNotify 例子裡使用字元串常量(””)作為管程對象。以下是那個例子:

java多線程-線程通信
java多線程-線程通信

在空字元串作為鎖的同步塊(或者其他常量字元串)裡調用 wait()和 notify()産生的問題是,JVM/編譯器内部會把常量字元串轉換成同一個對象。這意味着,即使你有 2 個不同的 MyWaitNotify 執行個體,它們都引用了相同的空字元串執行個體。同時也意味着存在這樣的風險:在第一個 MyWaitNotify 執行個體上調用 doWait()的線程會被在第二個 MyWaitNotify 執行個體上調用 doNotify()的線程喚醒。這種情況可以畫成以下這張圖:

java多線程-線程通信

起初這可能不像個大問題。畢竟,如果 doNotify()在第二個 MyWaitNotify 執行個體上被調用,真正發生的事不外乎線程 A 和 B 被錯誤的喚醒了 。這個被喚醒的線程(A 或者 B)将在 while 循環裡檢查信号值,然後回到等待狀态,因為 doNotify()并沒有在第一個 MyWaitNotify 執行個體上調用,而這個正是它要等待的執行個體。這種情況相當于引發了一次假喚醒。線程 A 或者 B 在信号值沒有更新的情況下喚醒。但是代碼處理了這種情況,是以線程回到了等待狀态。記住,即使 4 個線程在相同的共享字元串執行個體上調用 wait()和 notify(),doWait()和 doNotify()裡的信号還會被 2 個 MyWaitNotify 執行個體分别儲存。在 MyWaitNotify1 上的一次 doNotify()調用可能喚醒 MyWaitNotify2 的線程,但是信号值隻會儲存在 MyWaitNotify1 裡。

問題在于,由于 doNotify()僅調用了 notify()而不是 notifyAll(),即使有 4 個線程在相同的字元串(空字元串)執行個體上等待,隻能有一個線程被喚醒。是以,如果線程 A 或 B 被發給 C 或 D 的信号喚醒,它會檢查自己的信号值,看看有沒有信号被接收到,然後回到等待狀态。而 C 和 D 都沒被喚醒來檢查它們實際上接收到的信号值,這樣信号便丢失了。這種情況相當于前面所說的丢失信号的問題。C 和 D 被發送過信号,隻是都不能對信号作出回應。

如果 doNotify()方法調用 notifyAll(),而非 notify(),所有等待線程都會被喚醒并依次檢查信号值。線程 A 和 B 将回到等待狀态,但是 C 或 D 隻有一個線程注意到信号,并退出 doWait()方法調用。C 或 D 中的另一個将回到等待狀态,因為獲得信号的線程在退出 doWait()的過程中清除了信号值(置為 false)。

看過上面這段後,你可能會設法使用 notifyAll()來代替 notify(),但是這在性能上是個壞主意。在隻有一個線程能對信号進行響應的情況下,沒有理由每次都去喚醒所有線程。

是以:在 wait()/notify()機制中,不要使用全局對象,字元串常量等。應該使用對應唯一的對象。例如,每一個 MyWaitNotify3 的執行個體擁有一個屬于自己的螢幕對象,而不是在空字元串上調用 wait()/notify()。

轉自 http://www.cnblogs.com/houziwty/p/5826598.html(寫的很好)

QQ:519841366

本頁版權歸作者和部落格園所有,歡迎轉載,但未經作者同意必須保留此段聲明,

且在文章頁面明顯位置給出原文連結,否則保留追究法律責任的權利