多執行緒和多程序的使用場景

較輕的上下文切換開銷，不用切換位址空間，不用更改暫存器，不用重新整理tlb。

提供非均質的服務。如果全都是計算任務，但每個任務的耗時不都為1s，而是1ms-1s之間波動；這樣，多執行緒相比多程序的優勢就體現出來，它能有效降低「簡單任務被複雜任務壓住」的概率。

nginx主流的工作模式是多程序模式（也支援多執行緒模型）

幾乎所有的web server伺服器服務都有多程序的，至少有乙個守護程序配合乙個worker程序，例如apached,httpd等等以d結尾的程序包括init.d本身就是0級總程序，所有你認知的程序都是它的子程序；

chrome瀏覽器也是多程序方式。（原因：①可能存在一些網頁不符合程式設計規範，容易崩潰，採用多程序乙個網頁崩潰不會影響其他網頁；而採用多執行緒會。②網頁之間互相隔離，保證安全，不必擔心某個網頁中的惡意**會取得存放在其他網頁中的敏感資訊。）

redis也可以歸類到「多程序單執行緒」模型（平時工作是單個程序，涉及到耗時操作如持久化或aof重寫時會用到多個程序）

執行緒間有資料共享，並且資料是需要修改的（不同任務間需要大量共享資料或頻繁通訊時）。

提供非均質的服務（有優先順序任務處理）事件響應有優先順序。

單任務平行計算，在非cpu bound的場景下提高響應速度，降低時延。

在等待慢速i/o操作結束的同時，程式可以執行其他的計算任務。

計算密集型應用，為了能在多處理器系統上執行，將計算分解到多個執行緒中實現。

i/o密集型應用，為了提高效能，將i/o操作重疊。執行緒可以同時等待不同的i/o操作。

與人有io互動的應用，良好的使用者體驗（鍵盤滑鼠的輸入，立刻響應）

案例：桌面軟體，響應使用者輸入的是乙個執行緒，後台程式處理是另外的執行緒；

memcached

①需要頻繁建立銷毀的優先用執行緒（程序的建立和銷毀開銷過大）

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

②需要進行大量計算的優先使用執行緒（cpu頻繁切換）

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

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

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

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

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

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

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

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

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

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