程序是具有一定獨立功能的程式關於某個資料集合上的一次執行活動，程序是系統進行資源分配和排程的乙個獨立單位。
執行緒是程序的乙個實體，是cpu排程和分派的基本單位，它是比程序更小的能獨立執行的基本單位。執行緒自己基本上不擁有系統資源，只擁有一點在執行中必不可少的資源（如程式計數器，一組暫存器和棧），但是它可與同屬乙個程序的其他的執行緒共享程序所擁有的全部資源。
關於執行緒和程序，我們上大學時的教科書上最經典的一句話是「程序是資源分配的最小單位，執行緒是
cpu排程的最小單位」。當然了，這句話應付考試已經夠了，但是在工作中，光知道這句話是一點用都沒有的。
我們在做程式設計的時候，會糾結是用多執行緒還是用多程序，我可以告訴你，這個問題沒有標準答案，合理即正確。根據實際的專案需求，哪個合適選擇哪乙個。
下面對比一下多程序和多執行緒的區別
對比項多程序
多執行緒結論
資料共享
資料共享複雜，需要使用
ipc，同步簡單
資料是共享的，同步複雜
各有優勢
記憶體、cpu
占用記憶體多，切換耗費資源多
占用記憶體少，切換簡單
執行緒佔優
建立、銷毀和切換
建立、銷毀和切換耗費資源多
建立、銷毀和切換耗費資源少
執行緒佔優
程式設計、除錯
程式設計簡單、除錯簡單
程式設計複雜、除錯複雜
程序佔優
可靠性程序間相互獨立，不影響
乙個執行緒掛掉導致整個程序退出
程序佔優
分布式適用於多核心、多機分布式；如果一台機器不夠，擴充套件到多機比較簡單
適用於多核心分布式
程序佔優
從上表的比較結果來看，多程序和多執行緒是魚和熊掌的關係。
通過上面的比較，想必是選擇多程序還是多執行緒，大家心裡已經有些底了。
這種應用以
web伺服器為多，新的連線建立乙個執行緒，當處理完畢以後釋放執行緒，如果是程序的話，消耗還是比較大的。當然了，
apache使用的就是多程序，這裡不是不能用多程序，而是優先使用多執行緒。
大量計算肯定會占用大量的
cpu時間，這時候使用多執行緒減少切換的代價是比較合適的。
強相關，可以理解為業務聯絡緊密的處理，那麼弱相關就是業務聯絡不緊密的處理了。
弱相關，比如訊息的收發和訊息的處理，業務聯絡不緊密，可以使用多程序；強相關，比如訊息處理中包含了訊息解碼和訊息處理，這時候使用多執行緒較好。
當然了，這不是一成不變的方式，也可以根據實際情況進行調整。
當使用多程序和多執行緒都能夠滿足需求的時候，使用自己最拿手的方式。當然了，實際的開發中，多程序和多執行緒方式是並存的，兩種方式並不是對立的。適合及合理，合理即正確。
使用程序池或執行緒池，是為了降低程式在執行時建立或銷毀程序或執行緒消耗的資源，這種做法在計算機配置較低的年代有著很好的效果，可以提高程式的執行效率。
但是，預先生成子程序或子執行緒比用時建立子程序或子執行緒要複雜的多，不僅要對池中的程序
/執行緒數量進行管理，還要解決多程序
/多執行緒搶資源的問題，而且，在目前計算機的配置下，程序池或執行緒池在效率上不見得比用時建立程序或執行緒有優勢。
因此，使用程序池或執行緒池的技術，不僅複雜，從現階段來看也無優勢，在新的應用中，可以放心大膽的用時建立程序或執行緒。
多程序多執行緒的選擇
關於多程序和多執行緒，教科書上最經典的一句話是 程序是資源分配的最小單位，執行緒是cpu排程的最小單位 這句話應付考試基本上夠了，但如果在工作中遇到類似的選擇問題，那就沒有這麼簡單了，選的不好，會讓你深受其害。經常在網路上看到有的xdjm問 多程序好還是多執行緒好？linux下用多程序還是多執行緒？...
多程序多執行緒的選擇
程序是作業系統分配資源 cpu時間 記憶體 的基本單位，執行緒是排程執行的基本單元。乙個執行緒必定屬於乙個程序，乙個程序可包含多個執行緒。nginx redis是常見的多程序模型，tomcat memcached是多執行緒模型。多程序資料共享複雜，需要用管道，訊號，訊息佇列，共享記憶體，套接字等通訊...
多執行緒與多程序
程序 程序是程式的一次執行，在傳統的計算機中，程序既是基本的分配單元，也是基本的執行單元。執行緒 執行緒是可執行的實體單元，它是處理機排程的基本單位。由於執行緒在同一位址空間，因此建立和撤銷執行緒的開銷小，執行緒間的通訊效率高，切換迅速。在多處理機系統中，對程序的個數有所限制，但對執行緒的個數不存在...