第二課 重要范式(4）
2.4 並發范式——合作與競爭
在合作中競爭，在競爭中合作 ——《競合》
關鍵詞：編程范式,並發式編程,線程,進程,過程式,函數式,邏輯式,對象式
摘要：並發式編程簡談
？提問
並發式編程有何特點？
並發式編程有哪些好處？
合理的並發式編程設計應滿足哪些條件？
：講解
逗號好奇地問：“還有其他類型的編程范式嗎？”
“不但有，而且有很多。”冒號喝了一口水，悠悠地說，“並發式編程（concurrent programming）就是其中之一。”
歎號有些驚訝：“並發式編程也算一種范式？它似乎更像是提供運行效率的一種手段。”
“大謬不然。”冒號搖搖頭，“真正的並發式編程，絕不只是調用線程[1]API或使用synchronized、lock之類的關鍵字那麼簡單。從宏觀的架構設計，到微觀的數據結構、流程控制乃至算法，相比通常的串行式編程都可能發生變化。隨著硬件性能和用戶需求的雙重提升，並發式編程已成為不可回避的主題。毫不誇張地說，並發式編程是繼OOP之後又一場思想和技術上的革命。只是相比OOP，盡管年齡相仿，但語言上不夠支持，標准上不夠統一，理論上不夠完善，因而這場革命更具破壞性和建設性。現在我們來看一個例子，比較兩種燒水泡茶的方案。”
說著冒號在黑板上寫下——
方案一：洗茶杯；放茶葉；灌水壺；燒水；水開後泡茶。
方案二：灌水壺；在燒水的同時，洗茶杯；放茶葉；水開後泡茶。
引號見多識廣：“我記得這好像是運籌學中的例子，顯然方案二更佳。從編程的角度來看，方案一是串行式編程，方案二是並發式編程——燒水的線程與洗茶杯放茶葉的線程是同時進行的。”
“如果方案一也用並發式編程呢？”冒號追問。
引號一愣，隨即道：“必須先洗茶杯後放茶葉，洗茶杯放茶葉的同時也沒法燒水，至於泡茶，更得等水開之後了。”
句號明白了冒號的用意：“這就是說，單憑並發式編程並不能保證提高程序性能，還必須在程序設計上下功夫。”
問號繼續深究：“即便如此，如果硬件不支持，並發式編程也未必能提高效率啊。比如在一台單處理器的主機上，多個線程只能是模擬的、邏輯上的並行，而非真正物理上的並行。”
“這話有一定道理。”冒號有限度地表示贊同，“但設計者應該未雨綢缪，總不能等到有了多處理器才想到並發式編程吧？再者，沒有多處理器，是不是可以利用多台單處理器的主機同時運算呢？退一步講，即使在一台單處理器的情況下，並發式編程同樣可能提高性能。最典型的一個例子：當一個線程因為等待某種資源而被堵塞時，可以切換到其他線程而不至讓CPU閒置。更重要的一點是，難道除了縮短程序運行時間外，並發式編程就沒有別的好處嗎？譬如打開一個網頁，你是希望浏覽器邊下載邊顯示網頁呢，還是下載完成後再顯示？”
“當然是邊下載邊顯示啦。” 歎號毫不猶豫地說，“如果每個網頁都是下載完成後再顯示，那還不把人給憋壞了！”
逗號加了一句：“浏覽器加載文字和加載圖像也應分開在不同的線程，如果用戶對文字部分不感興趣，不等圖像顯示就可直接關閉網頁了。”
“如果網頁被提前關閉，那也是假用戶之手變相縮短了程序運行時間。”冒號接過話來，“還有一個常見的例子，包括浏覽器在內的許多應用軟件在運行中都會顯示一個進程條。該進程條的更新需要一個單獨的線程，從效率上看它起的作用是負面的，但大大提高了用戶體驗，是軟件人性化的表現。再舉一例，媒體播放器一般都會提供暫停、快進、倒退、快放、慢放等按鈕，如果不采用多線程，它們將形同虛設。此處並發式編程的作用在於提高了軟件的響應能力，也改善了用戶體驗——有誰願意駕駛一輛啟動後不能剎車、不能倒車、不能變速、油盡方停的汽車呢？”
“豈止是不願意，簡直是恐怖！”歎號加重了語氣。
“對於操作系統、各種實時系統和諸如數據庫、網絡服務器等基於服務的系統來說，在響應用戶請求的時間上和資源的合理分配上有著極高的要求，並發式編程更是不可或缺。”句號接著補充。
問號隨即又問：“並發式編程還有其他用處嗎？”
冒號應道：“不同編程范式采用不同的視角和方法來設計和開發軟件。並發式編程以進程為導向（Process-Oriented）、以任務為中心將系統模塊化。我們都知道，模塊化在編程中是個好東西。”
引號心存疑惑：“過程式中引入了函數模塊，對象式中引入了對象模塊，但並發式似乎沒有在語法上引入新型模塊，比如C和Java中的線程其實不過是函數或方法的包裝而已。”
“我猜你的意思是：在定義一個線程之前，其主函數已經模塊化了，不能把功勞記在並發式編程上，對吧？”冒號笑問，“你不能孤立靜止地看待每個模塊，還要考慮到模塊之間的相互關聯和作用。相比串行式，並發式在模塊之間引入了新的通訊和控制方式。也就是說，原先的一些模塊的定義和劃分一定是建立在線程機制的基礎上的。如果失去線程的支持，它們的合理性自然會打上問號，說不定整體設計都會受到牽連。這也體現了編程范式的滲透性和全局影響力。”
教室上空彌漫的疑雲一消而散。
冒號進一步指出：“除了用戶主觀上的需求和硬件客觀上的可能外，並發式顯得格外重要的另一深層原因是：許多程序是現實世界的模擬，而我們生活的世界不折不扣是並發式的。從某種意義上看，並發式的模擬比對象式的模擬更貼近世界。”
引號再次提問：“並發式編程在設計上有什麼要求？”
“並發式編程以資源共享與競爭為主線——又是對當今世界形勢的一個逼真模擬。這意味著程序設計將圍繞進程的劃分與調度、進程之間的通訊與同步等等來展開。合理的並發式設計需要諸多方面的權衡考量。”冒號說著，放出一段幻燈片——
軟件易於重用、維護、測試
公平有效地利用資源，優化程序性能如增大吞吐量、減少響應時間、提高效率等
保障進程安全，防止競態條件（Race Condition）
保持進程活性，避免死鎖、饑餓、活鎖、資源枯竭等
減少鎖開銷、上下文切換等帶來的性能損失
妥善處理多進程在算法、調試等方面帶來的復雜性
歎號蹙眉：“並發式編程好是好，就是太復雜。”
“天下沒有免費的午餐。有所得，必有所失。” 冒號淡淡地說，“並發式編程當然不容易，但也並非難以掌握。最重要的是，作為一個程序員，你不得不面對它。即使你不直接用並發式編程，你依賴的代碼和依賴你的代碼也可能用到；即使現在沒有用並發式，將來也可能用到。如果采取避而不理的鴕鳥政策，早晚會被人點中你的死穴。雖然目前不會對並發式編程作更深入的探討，但希望能引起你們足夠的重視。”
句號談及他的感受：“相比OOP在語言上得到的支持，並發式的支持力度好像很不夠。”
冒號點頭稱是：“這是由並發式的復雜性和成熟度決定的。另外，在究竟是在語言級別上支持並發、還是交由操作系統處理的問題上，仁者見仁，智者見智。Ada、Java和C#等選擇前者，在語法上對並發式編程有一定的支持；C和C++等選擇後者，除了關鍵字volatile外，主要靠庫函數支持。專門為並發式而設計的語言大多僅限於學術研究而非商業應用，Erlang語言[2]是少數的例外。順帶提一下，前面提到的聲明式語言具有無副作用的特性，尤其適合於並發式編程。”
問號提了一個聽似奇怪的問題：“並發式與前面提到的對象式有無共通之處？”
“並發式與對象式雖是互相正交的兩種范式，倒真有些相通呢。”冒號回答，“它們均與三大核心范式正交，並且越來越廣泛地向它們滲透著；均為傳統編程的一種推廣——並發式進程的個數為一時即為傳統的串行式編程，對象的方法個數為為零即為傳統的數據類型；均將整個程序系統分解為若干獨立的子系統，不同的是一個以任務為單位，一個以對象為單位；子系統之間均能交流與合作，不同的是一個以競爭為主題，一個以服務為主題。如果將程序系統視作公司，那麼並發式系統是產品型公司，每個進程是一名工人，其職責是執行單一任務；對象式系統是服務型公司，每個對象是一名服務員，其職責是提供系列服務。由此可見，一名優秀的程序設計師也應該是一名優秀的管理者。”
句號提出：“迄今為止我們談到了五種范式，能否對它們簡單概括一下？”
“你提問的時機把握得不錯嘛。”冒號開始如數家珍，“為便於記憶，我們不妨用‘一二三四五’來概括編程范式之最：最傳統的一個是命令式；最基本的兩個是命令式和聲明式；最核心的三個是命令式、函數式和邏輯式；最主要的四個是命令式、函數式、邏輯式和對象式；最重要的五個是命令式、函數式、邏輯式、對象式和並發式。最後，我們來對比一下五大范式。”
少頃，黑板上出現幾行排比句——
過程式：以過程為模塊的君主體系，模塊之間互相授命與聽命
函數式：以函數為模塊的數學體系，模塊之間互相替換與合成
邏輯式：以斷言為模塊的邏輯體系，模塊之間互相歸納與演繹
對象式：以對象為模塊的民主體系，模塊之間互相交流與服務
並發式：以進程為模塊的生產體系，模塊之間互相競爭與合作
“說回並發式編程，它要求我們擺脫以往習慣的按部就班的思維方式，對編程提出了更高的挑戰。程序世界與現實世界一樣，呈百舸爭流、千帆競發之勢，不進則退啊！”言訖，冒號宣布，“第二堂課到此為止，歡迎下次光臨。”
，插語
[1] 並發式編程中以進程（process）或線程（thread）為基本單位。盡管它們有很大的差異，但為簡明起見，這裡不加區分地交替使用兩個術語。
[2] Erlang是由愛立信開發的一種通用編程語言，支持函數式和並發式。
。總結
並發式編程以進程為導向、以任務為中心、以資源共享與競爭為主線。
並發式編程有助於提高運行效率、充分利用資源、提高軟件的響應能力、改善用戶體驗，同時以進程為單位將系統模塊化，更加真實地模擬現實世界。
合理的並發式設計應該做到：軟件易於重用、維護和測試；有效地利用資源，優化程序性能；保障進程安全和活性；減少性能損失和復雜度。
對象式和並發式在傳統編程的基礎上，分別從不同的方向進行拓展：對象式在數據類型上進行推廣——允許運算作為數據類型的成員；並發式在執行順序上進行推廣——允許不同運算的執行在時間上交替或者重合。它們與三大核心范式一道，組成了最重要的五大編程范式。
五大重要范式對比：
范式 體系 模塊 模塊關系 過程式 君主體系 過程 授命與聽命 函數式 數學體系 函數 替換與合成 邏輯式 邏輯體系 斷言 歸納與演繹 對象式 民主體系 對象 交流與服務 並發式 生產體系 進程 競爭與合作“”參考
[1] Abraham Silberschatz，Peter Galvin．Operating System Concepts，5ed.．Reading,MA：Addison-Wesley，1998．155-235
課後思考
在你所掌握的語言當中，有哪些是命令式的？哪些是聲明式的？其中，命令式語言裡有哪些聲明式的特征？聲明式的語言裡有哪些命令式的特征？它們各自有哪些優點和缺點？
你編寫的程序符合結構化編程的原則嗎？
你接觸過函數式語言和邏輯式語言嗎？如果沒有，試著閱讀相關的入門書籍，體會它們與過程式迥然不同的風味。（函數式語言推薦Haskell和 Scheme，邏輯式語言推薦Prolog）
相比純過程式的編程語言（如C語言），你認為OO語言主要有哪些優勢？又有哪些劣勢？
你認為在並發式編程設計中，最重要的是什麼？最困難的是什麼？
