**：
關於多程序和多執行緒，教科書上最經典的一句話是「程序是資源分配的最小單位，執行緒是cpu排程的最小單位」，這句話應付考試基本上夠了，但如果在工作中遇到類似的選擇問題，那就沒有這麼簡單了，選的不好，會讓你深受其害。
經常在網路上看到有的xdjm問「多程序好還是多執行緒好？」、「linux下用多程序還是多執行緒？」等等期望一勞永逸的問題，我只能說：沒有最好，只有更好。根據實際情況來判斷，哪個更加合適就是哪個好。
我們按照多個不同的維度，來看看多執行緒和多程序的對比（注：因為是感性的比較，因此都是相對的，不是說乙個好得不得了，另外乙個差的無法忍受）。
對比維度
多程序多執行緒
總結資料共享、同步
資料共享複雜，需要用
ipc；資料是分開的，同步簡單
因為共享程序資料，資料共享簡單，但也是因為這個原因導致同步複雜
各有優勢
記憶體、cpu
占用記憶體多，切換複雜，
cpu利用率低
占用記憶體少，切換簡單，
cpu利用率高
執行緒佔優
建立銷毀、切換
建立銷毀、切換複雜、速度慢
建立銷毀、切換簡單，速度很快
執行緒佔優
程式設計、除錯
程式設計簡單，除錯簡單
程式設計複雜、除錯複雜
程序佔優
可靠性程序間不會互相影響
乙個執行緒掛掉將導致整個程序掛掉
程序佔優
分布式適應於多核、多機分別式；如果一台機器不夠，擴充套件到多台機器比較簡單
適應於多核分布式
程序佔優
看起來比較簡單，優勢對比上是「執行緒 3.5 v 2.5 程序」，我們只管選線程就是了？
呵呵，有這麼簡單我就不用在這裡浪費口舌了，還是那句話，沒有絕對的好與壞，只有哪個更加合適的問題。我們來看實際應用中究竟如何判斷更加合適。
1）需要頻繁建立銷毀的優先用執行緒
原因請看上面的對比。
這種原則最常見的應用就是web伺服器了，來乙個連線建立乙個執行緒，斷了就銷毀執行緒，要是用程序，建立和銷毀的代價是很難承受的
2）需要進行大量計算的優先使用執行緒
所謂大量計算，當然就是要耗費很多cpu，切換頻繁了，這種情況下執行緒是最合適的。
這種原則最常見的是影象處理、演算法處理。
3）強相關的處理用執行緒，弱相關的處理用程序
什麼叫強相關、弱相關？理論上很難定義，給個簡單的例子就明白了。
一般的server需要完成如下任務：訊息收發、訊息處理。「訊息收發」和「訊息處理」就是弱相關的任務，而「訊息處理」裡面可能又分為「訊息解碼」、「業務處理」，這兩個任務相對來說相關性就要強多了。因此「訊息收發」和「訊息處理」可以分程序設計，「訊息解碼」、「業務處理」可以分執行緒設計。
當然這種劃分方式不是一成不變的，也可以根據實際情況進行調整。
4）可能要擴充套件到多機分布的用程序，多核分布的用執行緒
原因請看上面對比。
5）都滿足需求的情況下，用你最熟悉、最拿手的方式
至於「資料共享、同步」、「程式設計、除錯」、「可靠性」這幾個維度的所謂的「複雜、簡單」應該怎麼取捨，我只能說：沒有明確的選擇方法。但我可以告訴你乙個選擇原則：如果多程序和多執行緒都能夠滿足要求，那麼選擇你最熟悉、最拿手的那個。
需要提醒的是：雖然我給了這麼多的選擇原則，但實際應用中基本上都是「程序+執行緒」的結合方式，千萬不要真的陷入一種非此即彼的誤區。
多程序多執行緒的選擇
程序是作業系統分配資源 cpu時間 記憶體 的基本單位，執行緒是排程執行的基本單元。乙個執行緒必定屬於乙個程序，乙個程序可包含多個執行緒。nginx redis是常見的多程序模型，tomcat memcached是多執行緒模型。多程序資料共享複雜，需要用管道，訊號，訊息佇列，共享記憶體，套接字等通訊...
多程序與多執行緒的選擇 轉
程序是具有一定獨立功能的程式關於某個資料集合上的一次執行活動，程序是系統進行資源分配和排程的乙個獨立單位。執行緒是程序的乙個實體，是cpu排程和分派的基本單位，它是比程序更小的能獨立執行的基本單位。執行緒自己基本上不擁有系統資源，只擁有一點在執行中必不可少的資源 如程式計數器，一組暫存器和棧 但是它...
多執行緒 多程序？
這幾天在思考如何改進原型在多個客戶端的情況下的效能，特地溫習了一下多程序和多執行緒的一些知識。在linux下程序的程序和執行緒在核心看來區別很小，都是乙個可排程單元，都擁有記憶體管理結構等等。但是關鍵的差別是程序的資源都是私有的，而執行緒則是和別人共享的，所以執行緒的上下文切換可能比程序的開銷要小很...