在 Java 平台上進行多線程編程是件讓人望而生畏的事，這一點得到了廣泛認可。實際上，一般的理論似乎是：最好把多線程編程留給 Java 高手。Sun Microsystems 通過（在 EJB 規范中—— 請參閱參考資料）把以下內容描述成 EJB 架構的目標之一，也間接地、更深入地討論了這個觀點： 軟件開發網
應用程序開發人員不必理解低級事務和狀態管理細節、不必理解多線程、連接池或者其他復雜的低級 API。
如果以這個觀念為起點，那麼您也就不會驚訝為什麼許多 Java 開發人員要避開設計和開發多線程應用程序。但事實上，許多（即使不是大多數）企業級問題使用某種形式的多線程來解決最合適，而 EJB 和類似的框架並不像它們聲稱的那樣，總是最容易的解決方案。
在這篇由三部分組成的系列文章中，我介紹了一個理論，該理論承認了並發編程的復雜性，並且沒有試圖隱藏這種復雜性，或者使它不那麼難於學習和應用。通信順序進程（Communicating Sequential Processes —— CSP） 是一個精確的並發數學理論，可以用來構建多線程應用程序，確保構建的程序中不出現並發的常見問題，而且更重要的是，這一點能夠得到證實。
在介紹 CSP 理論和它基於 Java 語言的實現 —— JCSP 庫 —— 之前，我希望能夠確定我們有一個共同的討論框架。我先從 Java 平台的並發編程技術概述開始，接著提供了多線程應用程序開發缺陷的深入概述，這些缺陷包括：競爭冒險、死鎖、活動鎖和資源耗盡等。最後，通過一些具體的討論結束本文，這些討論包括為什麼 不能像您喜歡的那樣驗證多線程 Java 應用程序，並確定現有變通方法中您最偏愛的變通方法。
不要錯過連載剩下的部分！
“面向 Java 程序員的 CSP”是由三部分組成的、介紹通信順序進程（Communicating Sequential Processes —— CSP）的系列文章中的一篇。CSP 是並發編程的一個范式，它承認了並發編程的復雜性，卻並沒有把復雜性留給開發人員。請參閱本系列的其他部分：
第 2 部分：用 JCSP 進行並發編程
第 3 部分： JCSP 的高級主題
有了這些基礎，就可以完全地體會 JCSP 的好處了。這是 Java 平台多線程編程的一個概念性和實踐性的解決方案，我將在第 2 部分對其進行探討，還將在 第 3 部分 探討 Java 平台上更高級的 CSP 應用程序。
本文假設讀者對於 Java 語言的並發編程有一般性的了解，雖然我在文章中也提供了關於這一主題的一個概述。請參閱 參考資料 一節，以獲得更詳細的信息。
Java 語言的並發編程
就其自身來說，並發編程是一種技術，提供了操作的同時執行，不論是在單一系統上還是分布在大量系統上。這類操作實際是一些指令順序，例如單獨某個頂級任務的子任務，這類操作能夠並行執行，或者是作為線程，或者是作為進程。線程和進程之間的本質區別在於：進程通常是獨立的（例如獨立的地址空間），所以只能通過系統提供的進程間通信機制進行交互，而線程通常共享單一進程的狀態信息，能夠直接共享系統資源和內存中的對象。
可以使用下面兩種方法之一，通過多個進程來實現並發。第一種方法是在同一個處理器上運行進程，由操作系統處理進程之間的上下文環境切換。（可以理解，這種切換要比同一進程內多線程之間的上下文環境切換更慢。）第二種方法是構建大規模的並行和復雜的分布式系統，在不同的物理處理器上運行多個進程。
從內建支持的角度來說，Java 語言通過線程提供並發編程；每個 JVM 都能支持許多線程同時執行。可以用以下兩種方法之一在 Java 語言中創建線程：
Java.lang.Thread 類。在這種情況下，已經重寫的子類的 run() 方法必須包含實現線程運行時行為的代碼。要執行這個代碼，需要實例化子類對象，然後調用對象的 start() 方法，這樣就可以在內部執行 run() 方法了。Runnable 接口的定制實現。這個接口只包含一個 run() 方法，在這個方法中，要放置應用程序代碼。要執行這個代碼，需要實例化實現類的對象，然後在創建新 Thread 時，把對象作為構造函數的參數傳入。然後調用新創建的線程對象的 start() 方法，開始執行控制的新線程。
線程安全性和同步
如果 Java 對象中的某個方法能夠安全地運行在多線程環境中，那麼就稱該方法是 線程安全的。要獲得這種安全性，必須有一種機制，通過該機制，運行同一方法的多個線程就能夠同步其操作，這樣，在訪問相同的對象或代碼行時，就會只允許一個線程被處理。這種同步要求線程使用叫作 信號 的對象彼此進行溝通。
有一種類型的信號叫作 互斥信號 或 互斥體。顧名思義，這個信號對象的擁有權是互斥的，也就是說，在任意指定時間，只有一個線程能夠擁有互斥體。其他想獲得所有權的線程會被阻塞，它們必須等待，直到擁有互斥體的線程釋放互斥體。如果多個線程按順序排隊等候同一互斥體，那麼在當前擁有者釋放它的時候，只有一個等候線程能夠得到它；其他線程將繼續阻塞。
在 1970 年代初，C.A.R. Hoare 和其他人共同開發了一個叫作 監視器 的概念（請參閱 參考資料）。 一個 監視器 就是一個代碼主體，它的訪問受到互斥體的保護。任何想執行這個代碼的線程，都必須在代碼塊頂部得到關聯的互斥體，然後在底部再釋放它。因為在指定時間只有一個線程能夠擁有互斥體，所以這就有效地保證了只有擁有它的線程才能執行監視器的代碼塊。（受保護的代碼不需要相鄰 —— 例如，Java 語言中的每個對象都有一個與之關聯的監視器。）
任何想在 Java 語言中進行線程編程的開發人員，都會立即把上面的內容當成 synchronized 關鍵字所帶來的效果。可以確保包含在 synchronized 塊中的 Java 代碼在指定時間只被一個線程執行。在內部，可以由運行時將 synchronized 關鍵字轉換成某一種情況：所有的競爭線程都試圖獲得與它們（指線程）正在操作的對象實例關聯的那個（惟一的一個）互斥體。成功得到互斥體的線程將運行代碼，然後在退出 synchronized 塊時釋放互斥體。
等候和通知wait/notify 構造在 Java 語言的線程間通信機制中也扮演了重要的角色。基本的想法是：一個線程需要的某個條件可以由另外一個線程促成。這樣，條件的 wait 就可以得到滿足。一旦條件為真，那麼引發條件的線程就會 notify 等候線程蘇醒，並從中止的地方繼續進行。
wait/notify 機制要比 synchronized 機制更難理解和判斷。要想判斷出使用 wait/notify 的方法的行為邏輯，就要求判斷出使用它的所有方法的邏輯。一次判斷一個方法，把該方法和其他方法隔離開，是對整體系統行為得出錯誤結論的可靠方式。顯然，這樣做的復雜性會隨著要判斷的方法的數量增長而迅速提高。
線程狀態
我前面提到過，必須調用新創建的線程的 start() 方法來啟動它的執行。但是，僅僅是調用 start() 方法並不意味著線程會立即開始運行。這個方法只是把線程的狀態從 new 變成 runnable。只有在操作系統真正安排線程執行的時候，線程狀態才會變成 running （從 runnable）。
典型的操作系統支持兩種線程模型 —— 協作式和搶占式。在協作式 模型中，每個線程對於自己對 CPU 的控制權要保留多久、什麼時候放棄有最終意見。在這個模型中，因為可能存在某個無賴線程占住控制權不放，所以其他線程可能永遠無法得到運行。在 搶占式 模型中，操作系統本身采用基於時鐘“滴答”的計時器，基於這個計時器，操作系統可以強制把控制權從一個線程轉移到另外一個線程。在這種情況下，決定哪個線程會得到下一次控制權的調度策略就有可能基於各種指標，例如相對優先級、某個線程已經等待執行的時間長短，等等。
如果出於某些原因，處在 running 狀態的線程需要等候某個資源（例如，等候設備的輸入數據到達，或者等候某些條件已經設定的通知），或者在試圖獲得互斥體的時候被阻塞，因此線程決定睡眠，那麼這時它可以進入 blocked 狀態。當睡眠周期到期、預期輸入到達，或者互斥體當前的擁有者將其釋放並通知等候線程可以再次奪取互斥體時，阻塞的線程重新進入 runnable 狀態。
當線程的 run() 方法完成時（或者正常返回，或者拋出 RuntimeException 這樣的未檢測到異常），線程將終止。這時，線程的狀態是 dead。當線程死亡時，就不能通過再次調用它的 start() 方法來重新啟動它，如果那麼做，則會拋出 InvalidThreadStateException 異常。 軟件開發網
四個常見缺陷
正如我已經展示過的，Java 語言中的多線程編程是通過語言支持的大量精心設計的構造實現的。另外，還設計了大量設計模式和指導原則，來幫助人們了解這種復雜性帶來的許多缺陷。除此之外，多線程編程會很容易地在不經意間把細微的 bug 帶進多線程代碼，而且更重要的是，這類問題分析和調試起來非常困難。接下來要介紹的是用 Java 語言進行多線程編程時將會遇到（或者可能已經遇到過）的最常見問題的一個列表。
爭用條件
據說 爭用條件 存在於這樣的系統中：多個線程之間存在對共享資源的競爭，而勝出者決定系統的行為。Allen Holub 在他撰寫的文章 “programming Java threads in the real world” （請參閱 參考資料）提供了一個帶有這樣 bug 的簡單的多線程程序示例。在沖突的訪問請求之間進行不正確同步的另一個更可怕的後果是數據崩潰，此時，共享的數據結構有一部分由一個線程更新，而另一部分由另一個線程更新。在這種情況下，系統的行為不是按照勝出線程的意圖進行，系統根本不按照任何一個線程的意圖行動，所以兩個線程最後都將以失敗告終。
http://www.mscto.com
死鎖
死鎖 的情況是指：線程由於等候某種條件變成真（例如資源可以使用），但是它等候的條件無法變成真，因為能夠讓條件變成真的線程在等候第一個線程“做某件事”。這樣，兩個線程都在等候對方先采取第一步，所以都無法做事。請參閱 Allen Holub 撰寫的文章 （請參閱 參考資料），以獲得在多線程 Java 代碼中如何發生死鎖的示例。 軟件開發網
活動鎖
活動鎖 與 死鎖 不同，它是在線程實際工作的時候發生的，但這時還沒有完成工作。這通常是在兩個線程交叉工作的時候發生，所以第一個線程做的工作被另一個線程取消。一個簡單的示例就是：每個線程已經擁有了一個對象，同時需要另外一個線程擁有的另外一個對象。可以想像這樣的情況：每個線程放下自己擁有的對象，撿起另外一個線程放下的對象。顯然，這兩個線程會永遠都運行在上鎖這一步操作上，結果是什麼都做不成。（常見的真實示例就是，兩個人在狹窄的走廊相遇。每個人都禮貌地讓到另一邊讓對方先行，但卻在相同的時間都讓到同一邊了，所以兩個人還都沒法通過。這種情況會持續一些時間，然後兩個人都從這邊閃到那邊，結果還是一點進展也沒有。）
資源耗盡
資源耗盡，又稱為 線程耗盡，是 Java 語言的 wait/notify 原語無法保證 live-ness 的後果。Java 強制這些方法要擁有它們等候或通知的對象的鎖。在某個線程上調用的 wait() 方法在開始等候之前必須釋放監視器鎖，然後在從方法返回並獲得通知之後，必須再次重新獲得鎖。因此，Java 語言規范（請參閱 參考資料） 在鎖本身之外，還描述了一套與每個對象相關的 等候集（wait set）。一旦線程釋放了對象上的鎖（在 wait 的調用之後），線程就會放在這個等候集上。 軟件開發網
多數 JVM 實現把等候線程放在隊列中。所以，如果在通知發生的時候，還有其他線程在等候監視器，那麼就會把一個新線程放在隊列尾部，而它並不是下一個獲得鎖的線程。所以，等到被通知線程實際得到監視器的時候，通知該線程的條件可能已經不再為真，所以它不得不再次 wait。這種情況可能無限持續下去，從而造成運算工作上浪費（因為要反復把該線程放入等候集和從中取出）和線程耗盡。
貪心哲學家的寓言
演示這種行為的原型示例是 Peter Welch 教授描述的“聰明人沒有雞肉”（請參閱 參考資料）。在這個場景中考慮的系統是一所由五位哲學家、一位廚師和一個食堂組成的學院。所有的哲學家（除了一位）都要想想（在代碼示例中，考慮的時間是 3 秒）之後才去食堂取飯。而“貪心的”哲學家則不想把時間浪費在思考上 —— 相反，他一次又一次地回到食堂，企圖拿到雞肉來吃。
廚師按照一批四份的定量准備雞肉，每准備好一份，就送到食堂。貪心的哲學家不斷地去廚房，但他總是錯過食物！事情是這樣的：他第一次到的時候，時間太早，廚師還沒開火。因此貪心的哲學家只好干等著（通過 wait()方法調用）。在開飯的時候（通過 notify() 方法調用），貪心的哲學家再一次回到食堂排隊等候。但是這次，在他前來等候的時候，他的四位同事已經到了，所以他在食堂隊列中的位置在他們後面。他的同事把廚房送來的一批四份雞肉全部拿走了，所以貪心的哲學家又要在一邊等著了。 可憐（也可能是公平的） ，他永遠處在這個循環之外。 http://www.mscto.com
驗證的問題
一般來說，很難按照普通的規范對 Java 編程的多線程程序進行驗證。同樣，開發自動化工具對於常見的並發問題（例如死鎖、活動鎖和資源耗盡）進行完整而簡單的分析也不太容易——特別是在任意 Java 程序中或者在缺乏並發的正式模型的時候。
更糟的是，並發性問題出了名的變化多端、難於跟蹤。每個 Java 開發人員都曾經聽說過（或者親自編寫過）這樣的 Java 程序：經過嚴格分析，而且正常運行了相當一段時間，沒有表現出潛在的死鎖。然後突然有一天，問題發生了，結果弄得開發團隊經歷許多的不眠之夜來試圖發現並修補根本原因。
一方面，多線程 Java 程序容易發生的錯誤非常不明顯，有可能在任意什麼時候發生。另一方面，完全有可能這些 bug 在程序中從不出現。問題取決於一些不可知的因素。多線程程序的復雜本質，使得人們很難有效地對其進行驗證。沒有一套現成的規則可以找出多線程代碼中的這類問題，也無法確切地證明這些問題不存在，這些導致許多 Java 開發人員完全避開多線程應用程序的設計和開發，即使用並發和並行的方式對系統進行建模會非常棒，他們也不使用多線程。 軟件開發網
確實想進行多線程編程的開發人員通常准備好了以下一個或兩個解決方案（至少是一部分）：
雖然知道的人不多，但是對於編寫（然後驗證）正確的多線程應用程序這一問題，還有第三個選項。使用稱為通信順序進程（ Communicating Sequential Processes，CSP）的精確的線程同步的數學理論，可以在設計時最好地處理死鎖和活動鎖之類的問題。CSP 由 C.A.R. Hoare 與 20 世紀 70 年代後期設計，CSP 提供了有效的方法，證明用它的構造和工具構建的系統可以免除並發的常見問題。 軟件開發網
第 1 部分的結束語
在這份面向 Java 程序員的 CSP 全面介紹的第一部分中，我把重點放在克服多線程應用程序開發常見問題的第一步上，即了解這些問題。我介紹了 Java 平台上目前支持的多線程編程構造，解釋了它們的起源，討論了這類程序可能會有的問題。我還解釋了用正式理論在任意的、大型的和復雜的應用程序中清除這些問題（即競爭冒險、死鎖、活動鎖和資源耗盡）或者證明這些問題不存在的困難。
在 第 2 部分 中，有了這個基本框架在腦子裡，我將介紹 CSP 和它基於 Java 的實現 —— JCSP 庫。您會發現，CSP 是一個復雜的數學理論，有大量強大的應用程序 （我會在第 3 部分 將討論一些更高級的程序），其中包括多線程編程常見問題的解決方法。
要想了解 JCSP 如何把 CSP 的精華提煉成一個好理解的 Java 構造框架，那麼請您現在就跳轉至 “第 2 部分：用 JCSP 進行並發編程”。
致謝
我非常感謝 Peter Welch 教授在我編寫這個文章系列期間給予的鼓勵。他在百忙之中抽出時間，非常細致地審閱了本文的草稿，並提供了許多寶貴的提高本系列質量和准確性的建議。文章中如果還存在錯誤，那麼都是由於我的原因！我在文章中使用的示例基於或來自 JCSP 庫的 Javadoc 中提供的示例，以及 JCSP Web 站點上提供的 PowerPoint 演示文稿。這兩個來源都提供了大量將探索的信息。
參考資料 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
Brian Goetz 撰寫的由三部分組成的 “Threading lightly”系列是解決 Java 平台上同步問題的巧妙而系統的方法。（developerWorks，2001 年 7 月）。
Brian 的 Java theory and practice 專欄定期介紹多線程編程。 “並發在一定程度上使一切變得簡單 ”（developerWorks，2002 年 11 月）首次研究了 util.concurrent，這是一個廣泛采用的用於 Java 平台的並發工具包。
Allen Holub 編程了大量 Java 平台多線程編程的內容。他撰寫的“Programming Java threads in the real world” （JavaWorld，1998 年 10 月）提供了線程問題的示例，例如爭用條件和死鎖。
還請參閱 Holub 有名的苛評“v“ （developerWorks，2000 年 10 月）。
英國坎特伯雷市肯特大學的 Peter Welch 教授設計了“Wot, no chickens?”問題，舉例說明 Java 程序中的資源耗盡。
C.A.R. Hoare 開創性的論文“Communicating Sequential Processes”將通信順序進程的並行組合作為一種基本的編程構造方法進行介紹（Communications of the ACM Archive，1978）。
Hoare 撰寫的“Monitors:?an Operating system structuring concept” （Communications of the ACM Archive,1974）第一次向全世界介紹了監視器的概念，他采用了非常有表現力的示例，包括單一資源調度器、有邊界緩存、鬧鐘、緩沖池、磁頭優化器，以及一個有問題的讀取器和寫入器版本。
Enterprise JavaBeans 是若干個試圖向 Java 程序員隱藏多線程編程復雜性的框架之一。
請參閱 Java Language Specification。
在 developerWorks 的 Java 技術專區 中，可以找到 Java 編程各方面的文章。
請參閱 Developer Bookstore，以獲得技術書籍的完整清單，其中包括數百本 Java 相關主題 的書籍。
還請參閱 Java 技術專區教程頁，從 developerWorks 獲得免費的、以 Java 為重點的教程。
關於作者
Abhijit Belapurkar 從印度德裡市的印度理工學院（IIT）獲得了計算機科學方面的理工學士學位。在過去的 11 年中，他一直工作在分布式應用程序的架構和信息安全領域，並在使用 Java 平台構建 N-層應用程序方面擁有大約 6 年的經驗。他當前在印度班加羅爾市的 Infosys TechnologIEs Limited 擔任 J2EE 方面的高級技術架構師。
