Abhijit Belapurkar高級技術(shù)架構師, Infosys Technologies Limited

在 Java 平臺上進(jìn)行多線(xiàn)程編程是件讓人望而生畏的事，這一點(diǎn)得到了廣泛認可。實(shí)際上，一般的理論似乎是：最好把多線(xiàn)程編程留給 Java 高手。Sun Microsystems 通過(guò)把以下內容描述成 EJB 架構的目標之一，也間接地、更深入地討論了這個(gè)觀(guān)點(diǎn)：

應用程序開(kāi)發(fā)人員不必理解低級事務(wù)和狀態(tài)管理細節、不必理解多線(xiàn)程、連接池或者其他復雜的低級 API。

如果以這個(gè)觀(guān)念為起點(diǎn)，那么您也就不會(huì )驚訝為什么許多 Java 開(kāi)發(fā)人員要避開(kāi)設計和開(kāi)發(fā)多線(xiàn)程應用程序。但事實(shí)上，許多（即使不是大多數）企業(yè)級問(wèn)題使用某種形式的多線(xiàn)程來(lái)解決最合適，而 EJB 和類(lèi)似的框架并不像它們聲稱(chēng)的那樣，總是最容易的解決方案。

在這篇由三部分組成的系列文章中，我介紹了一個(gè)理論，該理論承認了并發(fā)編程的復雜性，并且沒(méi)有試圖隱藏這種復雜性，或者使它不那么難于學(xué)習和應用。通信順序進(jìn)程（Communicating Sequential Processes —— CSP） 是一個(gè)精確的并發(fā)數學(xué)理論，可以用來(lái)構建多線(xiàn)程應用程序，確保構建的程序中不出現并發(fā)的常見(jiàn)問(wèn)題，而且更重要的是，這一點(diǎn)能夠得到證實(shí)。

在介紹 CSP 理論和它基于 Java 語(yǔ)言的實(shí)現 —— JCSP 庫 —— 之前，我希望能夠確定我們有一個(gè)共同的討論框架。我先從 Java 平臺的并發(fā)編程技術(shù)概述開(kāi)始，接著(zhù)提供了多線(xiàn)程應用程序開(kāi)發(fā)缺陷的深入概述，這些缺陷包括：競爭冒險、死鎖、活動(dòng)鎖和資源耗盡等。最后，通過(guò)一些具體的討論結束本文，這些討論包括為什么 不能像您喜歡的那樣驗證多線(xiàn)程 Java 應用程序，并確定現有變通方法中您最偏愛(ài)的變通方法。

有了這些基礎，就可以完全地體會(huì ) JCSP 的好處了。這是 Java 平臺多線(xiàn)程編程的一個(gè)概念性和實(shí)踐性的解決方案，我將在第 2 部分對其進(jìn)行探討，還將在 第 3 部分 探討 Java 平臺上更高級的 CSP 應用程序。

本文假設讀者對于 Java 語(yǔ)言的并發(fā)編程有一般性的了解，雖然我在文章中也提供了關(guān)于這一主題的一個(gè)概述。Java 語(yǔ)言的并發(fā)編程
就其自身來(lái)說(shuō)，并發(fā)編程是一種技術(shù)，提供了操作的同時(shí)執行，不論是在單一系統上還是分布在大量系統上。這類(lèi)操作實(shí)際是一些指令順序，例如單獨某個(gè)頂級任務(wù)的子任務(wù)，這類(lèi)操作能夠并行執行，或者是作為線(xiàn)程，或者是作為進(jìn)程。線(xiàn)程和進(jìn)程之間的本質(zhì)區別在于：進(jìn)程通常是獨立的（例如獨立的地址空間），所以只能通過(guò)系統提供的進(jìn)程間通信機制進(jìn)行交互，而線(xiàn)程通常共享單一進(jìn)程的狀態(tài)信息，能夠直接共享系統資源和內存中的對象。

可以使用下面兩種方法之一，通過(guò)多個(gè)進(jìn)程來(lái)實(shí)現并發(fā)。第一種方法是在同一個(gè)處理器上運行進(jìn)程，由操作系統處理進(jìn)程之間的上下文環(huán)境切換。（可以理解，這種切換要比同一進(jìn)程內多線(xiàn)程之間的上下文環(huán)境切換更慢。）第二種方法是構建大規模的并行和復雜的分布式系統，在不同的物理處理器上運行多個(gè)進(jìn)程。

從內建支持的角度來(lái)說(shuō)，Java 語(yǔ)言通過(guò)線(xiàn)程提供并發(fā)編程；每個(gè) JVM 都能支持許多線(xiàn)程同時(shí)執行?？梢杂靡韵聝煞N方法之一在 Java 語(yǔ)言中創(chuàng )建線(xiàn)程：

• 繼承 java.lang.Thread 類(lèi)。在這種情況下，已經(jīng)重寫(xiě)的子類(lèi)的 run() 方法必須包含實(shí)現線(xiàn)程運行時(shí)行為的代碼。要執行這個(gè)代碼，需要實(shí)例化子類(lèi)對象，然后調用對象的 start() 方法，這樣就可以在內部執行 run() 方法了。
• 創(chuàng )建 Runnable 接口的定制實(shí)現。這個(gè)接口只包含一個(gè) run() 方法，在這個(gè)方法中，要放置應用程序代碼。要執行這個(gè)代碼，需要實(shí)例化實(shí)現類(lèi)的對象，然后在創(chuàng )建新 Thread 時(shí)，把對象作為構造函數的參數傳入。然后調用新創(chuàng )建的線(xiàn)程對象的 start() 方法，開(kāi)始執行控制的新線(xiàn)程。

線(xiàn)程安全性和同步
如果 Java 對象中的某個(gè)方法能夠安全地運行在多線(xiàn)程環(huán)境中，那么就稱(chēng)該方法是 線(xiàn)程安全的。要獲得這種安全性，必須有一種機制，通過(guò)該機制，運行同一方法的多個(gè)線(xiàn)程就能夠同步其操作，這樣，在訪(fǎng)問(wèn)相同的對象或代碼行時(shí)，就會(huì )只允許一個(gè)線(xiàn)程被處理。這種同步要求線(xiàn)程使用叫作 信號 的對象彼此進(jìn)行溝通。

有一種類(lèi)型的信號叫作 互斥信號 或 互斥體。顧名思義，這個(gè)信號對象的擁有權是互斥的，也就是說(shuō)，在任意指定時(shí)間，只有一個(gè)線(xiàn)程能夠擁有互斥體。其他想獲得所有權的線(xiàn)程會(huì )被阻塞，它們必須等待，直到擁有互斥體的線(xiàn)程釋放互斥體。如果多個(gè)線(xiàn)程按順序排隊等候同一互斥體，那么在當前擁有者釋放它的時(shí)候，只有一個(gè)等候線(xiàn)程能夠得到它；其他線(xiàn)程將繼續阻塞。

在 1970 年代初，C.A.R. Hoare 和其他人共同開(kāi)發(fā)了一個(gè)叫作 監視器 的概念（請參閱 參考資料）。 一個(gè) 監視器 就是一個(gè)代碼主體，它的訪(fǎng)問(wèn)受到互斥體的保護。任何想執行這個(gè)代碼的線(xiàn)程，都必須在代碼塊頂部得到關(guān)聯(lián)的互斥體，然后在底部再釋放它。因為在指定時(shí)間只有一個(gè)線(xiàn)程能夠擁有互斥體，所以這就有效地保證了只有擁有它的線(xiàn)程才能執行監視器的代碼塊。（受保護的代碼不需要相鄰 —— 例如，Java 語(yǔ)言中的每個(gè)對象都有一個(gè)與之關(guān)聯(lián)的監視器。）

任何想在 Java 語(yǔ)言中進(jìn)行線(xiàn)程編程的開(kāi)發(fā)人員，都會(huì )立即把上面的內容當成 synchronized 關(guān)鍵字所帶來(lái)的效果?？梢源_保包含在 synchronized 塊中的 Java 代碼在指定時(shí)間只被一個(gè)線(xiàn)程執行。在內部，可以由運行時(shí)將 synchronized 關(guān)鍵字轉換成某一種情況：所有的競爭線(xiàn)程都試圖獲得與它們（指線(xiàn)程）正在操作的對象實(shí)例關(guān)聯(lián)的那個(gè)（惟一的一個(gè)）互斥體。成功得到互斥體的線(xiàn)程將運行代碼，然后在退出 synchronized 塊時(shí)釋放互斥體。

等候和通知
wait/notify 構造在 Java 語(yǔ)言的線(xiàn)程間通信機制中也扮演了重要的角色?；镜南敕ㄊ牵阂粋€(gè)線(xiàn)程需要的某個(gè)條件可以由另外一個(gè)線(xiàn)程促成。這樣，條件的 wait 就可以得到滿(mǎn)足。一旦條件為真，那么引發(fā)條件的線(xiàn)程就會(huì ) notify 等候線(xiàn)程蘇醒，并從中止的地方繼續進(jìn)行。

wait/notify 機制要比 synchronized 機制更難理解和判斷。要想判斷出使用 wait/notify 的方法的行為邏輯，就要求判斷出使用它的所有方法的邏輯。一次判斷一個(gè)方法，把該方法和其他方法隔離開(kāi)，是對整體系統行為得出錯誤結論的可靠方式。顯然，這樣做的復雜性會(huì )隨著(zhù)要判斷的方法的數量增長(cháng)而迅速提高。

線(xiàn)程狀態(tài)
我前面提到過(guò)，必須調用新創(chuàng )建的線(xiàn)程的 start() 方法來(lái)啟動(dòng)它的執行。但是，僅僅是調用 start() 方法并不意味著(zhù)線(xiàn)程會(huì )立即開(kāi)始運行。這個(gè)方法只是把線(xiàn)程的狀態(tài)從 new 變成 runnable。只有在操作系統真正安排線(xiàn)程執行的時(shí)候，線(xiàn)程狀態(tài)才會(huì )變成 running （從 runnable）。

典型的操作系統支持兩種線(xiàn)程模型 —— 協(xié)作式和搶占式。在協(xié)作式 模型中，每個(gè)線(xiàn)程對于自己對 CPU 的控制權要保留多久、什么時(shí)候放棄有最終意見(jiàn)。在這個(gè)模型中，因為可能存在某個(gè)無(wú)賴(lài)線(xiàn)程占住控制權不放，所以其他線(xiàn)程可能永遠無(wú)法得到運行。在 搶占式 模型中，操作系統本身采用基于時(shí)鐘“滴答”的計時(shí)器，基于這個(gè)計時(shí)器，操作系統可以強制把控制權從一個(gè)線(xiàn)程轉移到另外一個(gè)線(xiàn)程。在這種情況下，決定哪個(gè)線(xiàn)程會(huì )得到下一次控制權的調度策略就有可能基于各種指標，例如相對優(yōu)先級、某個(gè)線(xiàn)程已經(jīng)等待執行的時(shí)間長(cháng)短，等等。

如果出于某些原因，處在 running 狀態(tài)的線(xiàn)程需要等候某個(gè)資源（例如，等候設備的輸入數據到達，或者等候某些條件已經(jīng)設定的通知），或者在試圖獲得互斥體的時(shí)候被阻塞，因此線(xiàn)程決定睡眠，那么這時(shí)它可以進(jìn)入 blocked 狀態(tài)。當睡眠周期到期、預期輸入到達，或者互斥體當前的擁有者將其釋放并通知等候線(xiàn)程可以再次奪取互斥體時(shí)，阻塞的線(xiàn)程重新進(jìn)入 runnable 狀態(tài)。

當線(xiàn)程的 run() 方法完成時(shí)（或者正常返回，或者拋出 RuntimeException 這樣的未檢測到異常），線(xiàn)程將終止。這時(shí)，線(xiàn)程的狀態(tài)是 dead。當線(xiàn)程死亡時(shí)，就不能通過(guò)再次調用它的 start() 方法來(lái)重新啟動(dòng)它，如果那么做，則會(huì )拋出 InvalidThreadStateException 異常。

四個(gè)常見(jiàn)缺陷
正如我已經(jīng)展示過(guò)的，Java 語(yǔ)言中的多線(xiàn)程編程是通過(guò)語(yǔ)言支持的大量精心設計的構造實(shí)現的。另外，還設計了大量設計模式和指導原則，來(lái)幫助人們了解這種復雜性帶來(lái)的許多缺陷。除此之外，多線(xiàn)程編程會(huì )很容易地在不經(jīng)意間把細微的 bug 帶進(jìn)多線(xiàn)程代碼，而且更重要的是，這類(lèi)問(wèn)題分析和調試起來(lái)非常困難。接下來(lái)要介紹的是用 Java 語(yǔ)言進(jìn)行多線(xiàn)程編程時(shí)將會(huì )遇到（或者可能已經(jīng)遇到過(guò)）的最常見(jiàn)問(wèn)題的一個(gè)列表。

爭用條件
據說(shuō) 爭用條件 存在于這樣的系統中：多個(gè)線(xiàn)程之間存在對共享資源的競爭，而勝出者決定系統的行為。Allen Holub 在他撰寫(xiě)的文章 “programming Java threads in the real world” （請參閱 參考資料）提供了一個(gè)帶有這樣 bug 的簡(jiǎn)單的多線(xiàn)程程序示例。在沖突的訪(fǎng)問(wèn)請求之間進(jìn)行不正確同步的另一個(gè)更可怕的后果是 數據崩潰，此時(shí)，共享的數據結構有一部分由一個(gè)線(xiàn)程更新，而另一部分由另一個(gè)線(xiàn)程更新。在這種情況下，系統的行為不是按照勝出線(xiàn)程的意圖進(jìn)行，系統根本不按照任何一個(gè)線(xiàn)程的意圖行動(dòng)，所以?xún)蓚€(gè)線(xiàn)程最后都將以失敗告終。

死鎖
死鎖 的情況是指：線(xiàn)程由于等候某種條件變成真（例如資源可以使用），但是它等候的條件無(wú)法變成真，因為能夠讓條件變成真的線(xiàn)程在等候第一個(gè)線(xiàn)程“做某件事”。這樣，兩個(gè)線(xiàn)程都在等候對方先采取第一步，所以都無(wú)法做事。請參閱 Allen Holub 撰寫(xiě)的文章，以獲得在多線(xiàn)程 Java 代碼中如何發(fā)生死鎖的示例。

活動(dòng)鎖
活動(dòng)鎖 與 死鎖 不同，它是在線(xiàn)程實(shí)際工作的時(shí)候發(fā)生的，但這時(shí)還沒(méi)有完成工作。這通常是在兩個(gè)線(xiàn)程交叉工作的時(shí)候發(fā)生，所以第一個(gè)線(xiàn)程做的工作被另一個(gè)線(xiàn)程取消。一個(gè)簡(jiǎn)單的示例就是：每個(gè)線(xiàn)程已經(jīng)擁有了一個(gè)對象，同時(shí)需要另外一個(gè)線(xiàn)程擁有的另外一個(gè)對象?？梢韵胂襁@樣的情況：每個(gè)線(xiàn)程放下自己擁有的對象，撿起另外一個(gè)線(xiàn)程放下的對象。顯然，這兩個(gè)線(xiàn)程會(huì )永遠都運行在上鎖這一步操作上，結果是什么都做不成。（常見(jiàn)的真實(shí)示例就是，兩個(gè)人在狹窄的走廊相遇。每個(gè)人都禮貌地讓到另一邊讓對方先行，但卻在相同的時(shí)間都讓到同一邊了，所以?xún)蓚€(gè)人還都沒(méi)法通過(guò)。這種情況會(huì )持續一些時(shí)間，然后兩個(gè)人都從這邊閃到那邊，結果還是一點(diǎn)進(jìn)展也沒(méi)有。）

資源耗盡
資源耗盡，又稱(chēng)為 線(xiàn)程耗盡，是 Java 語(yǔ)言的 wait/notify 原語(yǔ)無(wú)法保證 live-ness 的后果。Java 強制這些方法要擁有它們等候或通知的對象的鎖。在某個(gè)線(xiàn)程上調用的 wait() 方法在開(kāi)始等候之前必須釋放監視器鎖，然后在從方法返回并獲得通知之后，必須再次重新獲得鎖。因此，Java 語(yǔ)言規范（請參閱 參考資料） 在鎖本身之外，還描述了一套與每個(gè)對象相關(guān)的 等候集（wait set）。一旦線(xiàn)程釋放了對象上的鎖（在 wait 的調用之后），線(xiàn)程就會(huì )放在這個(gè)等候集上。

多數 JVM 實(shí)現把等候線(xiàn)程放在隊列中。所以，如果在通知發(fā)生的時(shí)候，還有其他線(xiàn)程在等候監視器，那么就會(huì )把一個(gè)新線(xiàn)程放在隊列尾部，而它并不是下一個(gè)獲得鎖的線(xiàn)程。所以，等到被通知線(xiàn)程實(shí)際得到監視器的時(shí)候，通知該線(xiàn)程的條件可能已經(jīng)不再為真，所以它不得不再次 wait。這種情況可能無(wú)限持續下去，從而造成運算工作上浪費（因為要反復把該線(xiàn)程放入等候集和從中取出）和線(xiàn)程耗盡。

貪心哲學(xué)家的寓言
演示這種行為的原型示例是 Peter Welch 教授描述的“聰明人沒(méi)有雞肉”（請參閱 參考資料）。在這個(gè)場(chǎng)景中考慮的系統是一所由五位哲學(xué)家、一位廚師和一個(gè)食堂組成的學(xué)院。所有的哲學(xué)家（除了一位）都要想想（在代碼示例中，考慮的時(shí)間是 3 秒）之后才去食堂取飯。而“貪心的”哲學(xué)家則不想把時(shí)間浪費在思考上 —— 相反，他一次又一次地回到食堂，企圖拿到雞肉來(lái)吃。

廚師按照一批四份的定量準備雞肉，每準備好一份，就送到食堂。貪心的哲學(xué)家不斷地去廚房，但他總是錯過(guò)食物！事情是這樣的：他第一次到的時(shí)候，時(shí)間太早，廚師還沒(méi)開(kāi)火。因此貪心的哲學(xué)家只好干等著(zhù)（通過(guò) wait() 方法調用）。在開(kāi)飯的時(shí)候（通過(guò) notify() 方法調用），貪心的哲學(xué)家再一次回到食堂排隊等候。但是這次，在他前來(lái)等候的時(shí)候，他的四位同事已經(jīng)到了，所以他在食堂隊列中的位置在他們后面。他的同事把廚房送來(lái)的一批四份雞肉全部拿走了，所以貪心的哲學(xué)家又要在一邊等著(zhù)了。 可憐（也可能是公平的） ，他永遠處在這個(gè)循環(huán)之外。

驗證的問(wèn)題
一般來(lái)說(shuō)，很難按照普通的規范對 Java 編程的多線(xiàn)程程序進(jìn)行驗證。同樣，開(kāi)發(fā)自動(dòng)化工具對于常見(jiàn)的并發(fā)問(wèn)題（例如死鎖、活動(dòng)鎖和資源耗盡）進(jìn)行完整而簡(jiǎn)單的分析也不太容易——特別是在任意 Java 程序中或者在缺乏并發(fā)的正式模型的時(shí)候。

更糟的是，并發(fā)性問(wèn)題出了名的變化多端、難于跟蹤。每個(gè) Java 開(kāi)發(fā)人員都曾經(jīng)聽(tīng)說(shuō)過(guò)（或者親自編寫(xiě)過(guò)）這樣的 Java 程序：經(jīng)過(guò)嚴格分析，而且正常運行了相當一段時(shí)間，沒(méi)有表現出潛在的死鎖。然后突然有一天，問(wèn)題發(fā)生了，結果弄得開(kāi)發(fā)團隊經(jīng)歷許多的不眠之夜來(lái)試圖發(fā)現并修補根本原因。

一方面，多線(xiàn)程 Java 程序容易發(fā)生的錯誤非常不明顯，有可能在任意什么時(shí)候發(fā)生。另一方面，完全有可能這些 bug 在程序中從不出現。問(wèn)題取決于一些不可知的因素。多線(xiàn)程程序的復雜本質(zhì)，使得人們很難有效地對其進(jìn)行驗證。沒(méi)有一套現成的規則可以找出多線(xiàn)程代碼中的這類(lèi)問(wèn)題，也無(wú)法確切地證明這些問(wèn)題不存在，這些導致許多 Java 開(kāi)發(fā)人員完全避開(kāi)多線(xiàn)程應用程序的設計和開(kāi)發(fā)，即使用并發(fā)和并行的方式對系統進(jìn)行建模會(huì )非常棒，他們也不使用多線(xiàn)程。

確實(shí)想進(jìn)行多線(xiàn)程編程的開(kāi)發(fā)人員通常準備好了以下一個(gè)或兩個(gè)解決方案（至少是一部分）：

• 長(cháng)時(shí)間艱苦地測試代碼，找出所有出現的并發(fā)性問(wèn)題，誠心地希望到應用程序真正運行地時(shí)候已經(jīng)發(fā)現并修復了所有這類(lèi)問(wèn)題。
• 大量運行設計模式和為多線(xiàn)程編程建立的指導原則。但是，這類(lèi)指導原則只在整個(gè)系統都按照它們的規范設計的時(shí)候才有效，沒(méi)有設計規則能夠覆蓋所有類(lèi)型的系統。

雖然知道的人不多，但是對于編寫(xiě)（然后驗證）正確的多線(xiàn)程應用程序這一問(wèn)題，還有第三個(gè)選項。使用稱(chēng)為通信順序進(jìn)程（ Communicating Sequential Processes，CSP）的精確的線(xiàn)程同步的數學(xué)理論，可以在設計時(shí)最好地處理死鎖和活動(dòng)鎖之類(lèi)的問(wèn)題。CSP 由 C.A.R. Hoare 與 20 世紀 70 年代后期設計，CSP 提供了有效的方法，證明用它的構造和工具構建的系統可以免除并發(fā)的常見(jiàn)問(wèn)題。

第 1 部分的結束語(yǔ)
在這份面向 Java 程序員的 CSP 全面介紹的第一部分中，我把重點(diǎn)放在克服多線(xiàn)程應用程序開(kāi)發(fā)常見(jiàn)問(wèn)題的第一步上，即了解這些問(wèn)題。我介紹了 Java 平臺上目前支持的多線(xiàn)程編程構造，解釋了它們的起源，討論了這類(lèi)程序可能會(huì )有的問(wèn)題。我還解釋了用正式理論在任意的、大型的和復雜的應用程序中清除這些問(wèn)題（即競爭冒險、死鎖、活動(dòng)鎖和資源耗盡）或者證明這些問(wèn)題不存在的困難。

在 第 2 部分 中，有了這個(gè)基本框架在腦子里，我將介紹 CSP 和它基于 Java 的實(shí)現 —— JCSP 庫。您會(huì )發(fā)現，CSP 是一個(gè)復雜的數學(xué)理論，有大量強大的應用程序 （我會(huì )在第 3 部分 將討論一些更高級的程序），其中包括多線(xiàn)程編程常見(jiàn)問(wèn)題的解決方法。

要想了解 JCSP 如何把 CSP 的精華提煉成一個(gè)好理解的 Java 構造框架，那么請您現在就跳轉至 “第 2 部分：用 JCSP 進(jìn)行并發(fā)編程”。

致謝
我非常感謝 Peter Welch 教授在我編寫(xiě)這個(gè)文章系列期間給予的鼓勵。他在百忙之中抽出時(shí)間，非常細致地審閱了本文的草稿，并提供了許多寶貴的提高本系列質(zhì)量和準確性的建議。文章中如果還存在錯誤，那么都是由于我的原因！我在文章中使用的示例基于或來(lái)自 JCSP 庫的 javadoc 中提供的示例，以及 JCSP Web 站點(diǎn)上提供的 Powerpoint 演示文稿。這兩個(gè)來(lái)源都提供了大量將探索的信息。

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。
• Brian Goetz 撰寫(xiě)的由三部分組成的 “Threading lightly”系列是解決 Java 平臺上同步問(wèn)題的巧妙而系統的方法。（developerWorks，2001 年 7 月）。
• Brian 的 Java theory and practice 專(zhuān)欄定期介紹多線(xiàn)程編程。 “并發(fā)在一定程度上使一切變得簡(jiǎn)單 ”（developerWorks，2002 年 11 月）首次研究了 util.concurrent，這是一個(gè)廣泛采用的用于 Java 平臺的并發(fā)工具包。
• Allen Holub 編程了大量 Java 平臺多線(xiàn)程編程的內容。他撰寫(xiě)的“Programming Java threads in the real world” （JavaWorld，1998 年 10 月）提供了線(xiàn)程問(wèn)題的示例，例如爭用條件和死鎖。
• 還請參閱 Holub 有名的苛評“v“ （developerWorks，2000 年 10 月）。
• 英國坎特伯雷市肯特大學(xué)的 Peter Welch 教授設計了“Wot, no chickens?”問(wèn)題，舉例說(shuō)明 Java 程序中的資源耗盡。
• C.A.R. Hoare 開(kāi)創(chuàng )性的論文“Communicating Sequential Processes”將通信順序進(jìn)程的并行組合作為一種基本的編程構造方法進(jìn)行介紹（Communications of the ACM Archive，1978）。
• Hoare 撰寫(xiě)的“Monitors:?an operating system structuring concept” （Communications of the ACM Archive,1974）第一次向全世界介紹了監視器的概念，他采用了非常有表現力的示例，包括單一資源調度器、有邊界緩存、鬧鐘、緩沖池、磁頭優(yōu)化器，以及一個(gè)有問(wèn)題的讀取器和寫(xiě)入器版本。
• Enterprise JavaBeans 是若干個(gè)試圖向 Java 程序員隱藏多線(xiàn)程編程復雜性的框架之一。
• 請參閱 Java Language Specification。