並發范式
在合作中競爭，在競爭中合作 ——《競合》
逗號好奇地問：“還有其他類型的編程范式嗎？”
“不但有，而且有很多。”冒號喝了一口水，悠悠地說，“並發式編程就是其中之一。”
歎號有些驚訝：“並發式編程也算一種范式？它似乎更像是提供運行效率的一種手段。”
“大謬不然。”冒號搖搖頭，“真正的並發式編程，絕不只是調用線程API或使用synchronized、lock之類的關鍵字那麼簡單。從宏觀的架構設計，到微觀的數據結構、流程控制乃至算法，相比通常的串行式編程都可能發生變化。隨著硬件性能和用戶需求的雙重提升，並發式編程已成為不可回避的主題。毫不誇張地說，並發式編程是繼OOP之後又一場思想和技術上的革命。只是相比OOP，盡管年齡相仿，但語言上不夠支持，標准上不夠統一，理論上不夠完善，因而這場革命更具破壞性和建設性。現在我們來看一個例子，比較兩種燒水泡茶的方案。”
說著冒號在黑板上寫下——
方案一：洗茶杯；放茶葉；灌水壺；燒水；水開後泡茶。
方案二：灌水壺；在燒水的同時，洗茶杯；放茶葉；水開後泡茶。
引號見多識廣：“我記得這好像是運籌學中的例子，顯然方案二更佳。從編程的角度來看，方案一是串行式編程，方案二是並發式編程——燒水的線程與洗茶杯放茶葉的線程是同時進行的。”
“如果方案一也用並發式編程呢？”冒號追問。
引號一愣，隨即道：“必須先洗茶杯後放茶葉，洗茶杯放茶葉的同時也沒法燒水，至於泡茶，更得等水開之後了。”
“由此可見，單憑並發式編程並不能保證提高效率，還必須在程序設計上作改進。”冒號說道，“並發式編程以進程為導向（Process-Oriented），以資源共享與競爭為主線——與當今世界形勢何其相似乃爾！這意味著程序設計將圍繞進程的劃分與調度、進程之間的通訊與同步等等來展開。合理的進程設計應該能做到——”
軟件易於重用、維護、測試
公平有效地利用資源，優化程序性能如增大吞吐量、減少響應時間、提高效率等
保障進程安全，防止競態條件（Race Condition）
保持進程活性，避免死鎖、饑餓、活鎖、資源枯竭等
減少鎖開銷、上下文切換等帶來的性能損失
妥善處理多進程在算法、調試等方面帶來的復雜性
歎號蹙眉：“並發式編程好是好，就是太復雜。”
冒號淡淡地說：“天下沒有免費的午餐。並發式編程當然不容易，但也並非難以掌握。最重要的是，作為一個程序員，你不得不面對它。即使你不直接用並發式編程，你依賴的代碼和依賴你的代碼也可能用到；即使現在沒有用並發式，將來也可能用到。如果采取避而不理的鴕鳥政策，早晚會被人點中你的死穴。”
句號談及他的感受：“相比OOP在語言上得到的支持，並發式的支持力度好像很不夠。”
冒號點頭稱是：“這是由並發式的復雜性和成熟度決定的。主流語言中Java和C#對並發式編程在語法上有一定的支持，而C與C++除了關鍵字volatile外，主要靠library支持。專門為並發式而設計的語言大多僅限於學術研究而非商業應用，Erlang語言是少數的例外。”
問號提了一個聽似奇怪的問題：“並發式與前面提到的對象式有無共通之處？”
“並發式與對象式雖是互相正交的兩種范式，倒真有些相通呢。”冒號回答，“它們均與三大基本范式正交，並且越來越廣泛地向它們滲透著；均為傳統編程的一種推廣——並發式進程的個數為一時即為傳統的串行式編程，對象的方法個數為為零即為傳統的數據結構；均將整個程序系統分解為若干獨立的子系統，不同的是一個以任務為單位，一個以對象為單位；子系統之間均能交流與合作，不同的是一個以競爭為主題，一個以服務為主題。如果將程序系統視作公司，那麼並發式系統是產品型公司，每個進程是一名工人，其職責是執行單一任務；對象式系統是服務型公司，每個對象是一名服務員，其職責是提供系列服務。由此可見，一名優秀的程序設計師也應該是一名優秀的管理者。”
句號提出：“迄今為止我們談到了五種范式，能否對它們簡單概括一下？”
少頃，黑板上出現幾行排比句——
過程式：以過程為模塊的君主體系，模塊之間互相授命與聽命
函數式：以函數為模塊的數學體系，模塊之間互相替換與合成
邏輯式：以斷言為模塊的邏輯體系，模塊之間互相歸納與演繹
對象式：以對象為模塊的民主體系，模塊之間互相交流與服務
並發式：以進程為模塊的生產體系，模塊之間互相競爭與合作
“並發式編程要求我們擺脫以往習慣的按部就班的思維方式，對編程提出了更高的挑戰。程序世界與現實世界一樣，呈百舸爭流、千帆競發之勢，不進則退啊！”言訖，冒號宣布，“第二堂課到此為止，歡迎下次光臨。”
