【轉】多進程 & 多線程的區別與適用場景

關於多進程和多線程，教科書上最經典的一句話是「進程是資源分配的最小單位，線程是CPU調度的最小單位」，這句話應付考試基本上夠了，但若是在工做中遇到相似的選擇問題，那就沒有這麼簡單了，選的很差，會讓你深受其害。
常常在網絡上看到有的XDJM問「多進程好仍是多線程好？」、「Linux下用多進程仍是多線程？」等等指望一勞永逸的問題，我只能說：沒有最好，只有更好。根據實際狀況來判斷，哪一個更加合適就是哪一個好。
咱們按照多個不一樣的維度，來看看多線程和多進程的對比（注：由於是感性的比較，所以都是相對的，不是說一個好得不得了，另一個差的沒法忍受）。

看起來比較簡單，優點對比上是「線程 3.5 v 2.5 進程」，咱們只管選線程就是了？
呵呵，有這麼簡單我就不用在這裏浪費口舌了，仍是那句話，沒有絕對的好與壞，只有哪一個更加合適的問題。咱們來看實際應用中究竟如何判斷更加合適。
1）須要頻繁建立銷燬的優先用線程（進程的建立和銷燬開銷過大）
緣由請看上面的對比。
這種原則最多見的應用就是Web服務器了，來一個鏈接創建一個線程，斷了就銷燬線程，要是用進程，建立和銷燬的代價是很難承受的
2）須要進行大量計算的優先使用線程（CPU頻繁切換）
所謂大量計算，固然就是要耗費不少CPU，切換頻繁了，這種狀況下線程是最合適的。
這種原則最多見的是圖像處理、算法處理。
3）強相關的處理用線程，弱相關的處理用進程
什麼叫強相關、弱相關？理論上很難定義，給個簡單的例子就明白了。
通常的Server須要完成以下任務：消息收發、消息處理。「消息收發」和「消息處理」就是弱相關的任務，而「消息處理」裏面可能又分爲「消息解碼」、「業務處理」，這兩個任務相對來講相關性就要強多了。所以「消息收發」和「消息處理」能夠分進程設計，「消息解碼」、「業務處理」能夠分線程設計。
固然這種劃分方式不是一成不變的，也能夠根據實際狀況進行調整。
4）可能要擴展到多機分佈的用進程，多核分佈的用線程
緣由請看上面對比。
5）都知足需求的狀況下，用你最熟悉、最拿手的方式
至於「數據共享、同步」、「編程、調試」、「可靠性」這幾個維度的所謂的「複雜、簡單」應該怎麼取捨，我只能說：沒有明確的選擇方法。但我能夠告訴你一個選擇原則：若是多進程和多線程都可以知足要求，那麼選擇你最熟悉、最拿手的那個。
須要提醒的是：雖然我給了這麼多的選擇原則，但實際應用中基本上都是「進程+線程」的結合方式，千萬不要真的陷入一種非此即彼的誤區。

 

參考資料：http://www.2cto.com/kf/201007/53769.html