魚還是熊掌：淺談多進程多線程的選擇

魚還是熊掌：淺談多進程多線程的選擇

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

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

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

對比維度	多進程	多線程	總結
數據共享、同步	數據共享複雜，需要用IPC；數據是分開的，同步簡單	因為共享進程數據，數據共享簡單，但也是因為這個原因導致同步複雜	各有優勢
內存、CPU	占用內存多，切換複雜，CPU利用率低	占用內存少，切換簡單，CPU利用率高	線程占優
創建銷毀、切換	創建銷毀、切換複雜，速度慢	創建銷毀、切換簡單，速度很快	線程占優
編程、調試	編程簡單，調試簡單	編程複雜，調試複雜	進程占優
可靠性	進程間不會互相影響	一個線程掛掉將導致整個進程掛掉	進程占優
分布式	適應於多核、多機分布式；如果一台機器不夠，擴展到多台機器比較簡單	適應於多核分布式	進程占優

看起來比較簡單，優勢對比上是“線程 3.5 v 2.5 進程”，我們隻管選線程就是了？

嗬嗬，有這麼簡單我就不用在這裏浪費口舌了，還是那句話，沒有絕對的好與壞，隻有哪個更加合適的問題。我們來看實際應用中究竟如何判斷更加合適。

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

原因請看上麵的對比。

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

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

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

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

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

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

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

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

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

原因請看上麵對比。

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

至於“數據共享、同步”、“編程、調試”、“可靠性”這幾個維度的所謂的“複雜、簡單”應該怎麼取舍，我隻能說：沒有明確的選擇方法。但我可以告訴你一個選擇原則：如果多進程和多線程都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。

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

最後更新：2017-04-02 04:26:02