多線程還是多程序的差別

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

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

對比次元

多程序

多線程

總結

資料共享、同步

資料共享複雜，需要用IPC；資料是分開的，同步簡單

因為共享程序資料，資料共享簡單，但也是因為這個原因導緻同步複雜

各有優勢

記憶體、CPU

占用記憶體多，切換複雜，CPU使用率低

占用記憶體少，切換簡單，CPU使用率高

線程占優

建立銷毀、切換

建立銷毀、切換複雜，速度慢

建立銷毀、切換簡單，速度很快

程式設計、調試

程式設計簡單，調試簡單

程式設計複雜，調試複雜

程序占優

可靠性

程序間不會互相影響

一個線程挂掉将導緻整個程序挂掉

分布式

适應于多核、多機分布式；如果一台機器不夠，擴充到多台機器比較簡單

适應于多核分布式

1）需要頻繁建立銷毀的優先用線程

原因請看上面的對比。

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

2）需要進行大量計算的優先使用線程

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

這種原則最常見的是圖像處理、算法處理。

3）強相關的處理用線程，弱相關的處理用程序

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

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

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

4）可能要擴充到多機分布的用程序，多核分布的用線程

原因請看上面對比。

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

至于“資料共享、同步”、“程式設計、調試”、“可靠性”這幾個次元的所謂的“複雜、簡單”應該怎麼取舍，我隻能說：沒有明确的選擇方法。但我可以告訴你一個選擇原則：如果多程序和多線程都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。 

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

若轉載請注明出處！若有疑問，請回複交流！