魚還是熊掌：淺談多程序多執行緒的選擇

關於多程序和多執行緒，教科書上最經典的一句話是“程序是資源分配的最小單位，執行緒是CPU排程的最小單位”，這句話應付考試基本上夠了，但如果在工作中遇到類似的選擇問題，那就沒有這麼簡單了，選的不好，會讓你深受其害。

經常在網路上看到有的XDJM問“多程序好還是多執行緒好？”、“Linux下用多程序還是多執行緒？”等等期望一勞永逸的問題，我只能說：沒有最好，只有更好。根據實際情況來判斷，哪個更加合適就是哪個好。

我們按照多個不同的維度，來看看多執行緒和多程序的對比（注：因為是感性的比較，因此都是相對的，不是說一個好得不得了，另外一個差的無法忍受）。

對比維度	多程序	多執行緒	總結
資料共享、同步	資料共享複雜，需要用IPC；資料是分開的，同步簡單	因為共享程序資料，資料共享簡單，但也是因為這個原因導致同步複雜	各有優勢
記憶體、CPU	佔用記憶體多，切換複雜，CPU利用率低	佔用記憶體少，切換簡單，CPU利用率高	執行緒佔優
建立銷燬、切換	建立銷燬、切換複雜，速度慢	建立銷燬、切換簡單，速度很快	執行緒佔優
程式設計、除錯	程式設計簡單，除錯簡單	程式設計複雜，除錯複雜	程序佔優
可靠性	程序間不會互相影響	一個執行緒掛掉將導致整個程序掛掉	程序佔優
分散式	適應於多核、多機分散式；如果一臺機器不夠，擴充套件到多臺機器比較簡單	適應於多核分散式	程序佔優

1）需要頻繁建立銷燬的優先用執行緒

原因請看上面的對比。

這種原則最常見的應用就是Web伺服器了，來一個連線建立一個執行緒，斷了就銷燬執行緒，要是用程序，建立和銷燬的代價是很難承受的

2）需要進行大量計算的優先使用執行緒

所謂大量計算，當然就是要耗費很多CPU，切換頻繁了，這種情況下執行緒是最合適的。

這種原則最常見的是影象處理、演算法處理。

3）強相關的處理用執行緒，弱相關的處理用程序

什麼叫強相關、弱相關？理論上很難定義，給個簡單的例子就明白了。

一般的Server需要完成如下任務：訊息收發、訊息處理。“訊息收發”和“訊息處理”就是弱相關的任務，而“訊息處理”裡面可能又分為“訊息解碼”、“業務處理”，這兩個任務相對來說相關性就要強多了。因此“訊息收發”和“訊息處理”可以分程序設計，“訊息解碼”、“業務處理”可以分執行緒設計。

當然這種劃分方式不是一成不變的，也可以根據實際情況進行調整。

4）可能要擴充套件到多機分佈的用程序，多核分佈的用執行緒

原因請看上面對比。

5）都滿足需求的情況下，用你最熟悉、最拿手的方式

至於“資料共享、同步”、“程式設計、除錯”、“可靠性”這幾個維度的所謂的“複雜、簡單”應該怎麼取捨，我只能說：沒有明確的選擇方法。但我可以告訴你一個選擇原則：如果多程序和多執行緒都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。 

需要提醒的是：雖然我給了這麼多的選擇原則，但實際應用中基本上都是“程序+執行緒”的結合方式，千萬不要真的陷入一種非此即彼的誤區。

消耗資源：

從核心的觀點看，程序的目的就是擔當分配系統資源（CPU時間、記憶體等）的基本單位。執行緒是程序的一個執行流，是CPU排程和分派的基本單位，它是比程序更小的能獨立執行的基本單位。

執行緒，它們彼此之間使用相同的地址空間，共享大部分資料，啟動一個執行緒所花費的空間遠遠小於啟動一個程序所花費的空間，而且，執行緒間彼此切換所需的時間也遠遠小於程序間切換所需要的時間。據統計，總的說來，一個程序的開銷大約是一個執行緒開銷的30倍左右，當然，在具體的系統上，這個資料可能會有較大的區別。

通訊方式：

程序之間傳遞資料只能是通過通訊的方式，即費時又不方便。執行緒時間資料大部分共享（執行緒函式內部不共享），快捷方便。但是資料同步需要鎖對於static變數尤其注意

執行緒自身優勢：

提高應用程式響應；使多CPU系統更加有效。作業系統會保證當執行緒數不大於CPU數目時，不同的執行緒運行於不同的CPU上；

改善程式結構。一個既長又複雜的程序可以考慮分為多個執行緒，成為幾個獨立或半獨立的執行部分，這樣的程式會利於理解和修改。