多進程跟多線程如何取捨，在不同系統，不同場景下？

02-22

多進程與多線程各有優劣如何權衡，請各位大神共享自己的經驗？

一般來說，多進程容錯率高，隔離性好，寫程序不需要考慮太多內存鎖之類的問題。

而多線程在共享內存數據上相比多進程有無可比擬的優越性。

二者的性能差別根據實際情況不同，理論上進程切換更重，而線程切換也有降低分支預測命中率等缺點，二者差別不會太大。

所以簡單來說，如果你的程序需要大量共享內存數據，就用多線程，否則就用多進程。

有一篇文章是這麼寫的，原創作者是誰，沒找到，不過講的很好，轉來回答這個問題正好：

在Linux下編程多用多進程編程少用多線程編程。

IBM有個傢伙做了個測試，發現切換線程context的時候，windows比linux快一倍多。進出最快的鎖（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。當然這並不是說linux不好，而且在經過實際編程之後，綜合來看我覺得linux更適合做high performance server，不過在多線程這個具體的領域內，linux還是稍遜windows一點。這應該是情有可原的，畢竟unix家族都是從多進程過來的，而 windows從頭就是多線程的。

如果是UNIX/linux環境，採用多線程沒必要。

多線程比多進程性能高？誤導！

應該說，多線程比多進程成本低，但性能更低。

在UNIX環境，多進程調度開銷比多線程調度開銷，沒有顯著區別，就是說，UNIX進程調度效率是很高的。內存消耗方面，二者只差全局數據區，現在內存都很便宜，伺服器內存動輒若干G，根本不是問題。

多進程是立體交通系統，雖然造價高，上坡下坡多耗點油，但是不堵車。

多線程是平面交通系統，造價低，但紅綠燈太多，老堵車。

我們現在都開跑車，油（主頻）有的是，不怕上坡下坡，就怕堵車。

高性能交易伺服器中間件，如TUXEDO，都是主張多進程的。實際測試表明，TUXEDO性能和並發效率是非常高的。TUXEDO是貝爾實驗室的，與UNIX同宗，應該是對UNIX理解最為深刻的，他們的意見應該具有很大的參考意義。

====================================================================================================

多線程的優點：

無需跨進程邊界；程序邏輯和控制方式簡單；所有線程可以直接共享內存和變數等；線程方式消耗的總資源比進程方式好； 多線程缺點：

每個線程與主程序共用地址空間，受限於2GB地址空間；線程之間的同步和加鎖控制比較麻煩；一個線程的崩潰可能影響到整個程序的穩定性；到達一定的線程數程度後，即使再增加CPU也無法提高性能，例如Windows Server 2003，大約是1500個左右的線程數就快到極限了（線程堆棧設定為1M），如果設定線程堆棧為2M，還達不到1500個線程總數；線程能夠提高的總性能有限，而且線程多了之後，線程本身的調度也是一個麻煩事兒，需要消耗較多的CPU

多進程優點：

每個進程互相獨立，不影響主程序的穩定性，子進程崩潰沒關係；通過增加CPU，就可以容易擴充性能；可以盡量減少線程加鎖/解鎖的影響，極大提高性能，就算是線程運行的模塊演算法效率低也沒關係；每個子進程都有2GB地址空間和相關資源，總體能夠達到的性能上限非常大 多線程缺點：

邏輯控制複雜，需要和主程序交互；需要跨進程邊界，如果有大數據量傳送，就不太好，適合小數據量傳送、密集運算多進程調度開銷比較大；最好是多進程和多線程結合，即根據實際的需要，每個CPU開啟一個子進程，這個子進程開啟多線程可以為若干同類型的數據進行處理。當然你也可以利用多線程+多CPU+輪詢方式來解決問題……

方法和手段是多樣的，關鍵是自己看起來實現方便有能夠滿足要求，代價也合適。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

進程的優點：

1）順序程序的特點：具有封閉性和可再現性；

2）程序的並發執行和資源共享。多道程序設計出現後，實現了程序的並發執行和資源共享，提高了系統的效率和系統的資源利用率。 進程的缺點：

操作系統調度切換多個線程要比切換調度進程在速度上快的多。而且進程間內存無法共享，通訊也比較麻煩。

線程之間由於共享進程內存空間，所以交換數據非常方便；在創建或撤消進程時，由於系統都要為之分配和回收資源，導致系統的開銷明顯大於創建或撤消線程時的開銷。

線程的優點：

1）它是一種非常"節儉"的多任務操作方式。在Linux系統下，啟動一個新的進程必須分配給它獨立的地址空間，建立眾多的數據表來維護它的代碼段、堆棧段和數據段，這是一種"昂貴"的多任務工作方式。而運行於一個進程中的多個線程，它們彼此之間使用相同的地址空間，共享大部分數據，啟動一個線程所花費的空間遠遠小於啟動一個進程所花費的空間，而且，線程間彼此切換所需的時間也遠遠小於進程間切換所需要的時間。當然，在具體的系統上，這個數據可能會有較大的區別；

2）線程間方便的通信機制，由於同一進程下的線程之間共享數據空間，所以一個線程的數據可以直接為其它線程所用，這不僅快捷，而且方便；

3）使多CPU系統更加有效。操作系統會保證當線程數不大於CPU數目時，不同的線程運行於不同的CPU上；

4）改善程序結構。一個既長又複雜的進程可以考慮分為多個線程，成為幾個獨立或半獨立的運行部分，這樣的程序會利於理解和修改。 線程的缺點： 1.調度時, 要保存線程狀態，頻繁調度, 需要佔用大量的機時； 2.程序設計上容易出錯（線程同步問題）。

書第3章。

linux下，如果不用共享數據，就用多進程。

否則就多線程。

多進程的開銷和多線程的開銷相差不大。

win下多線程。

多進程才是王道，多線程並不是。多進程的核心優勢，死掉一個進程不會導致服務宕機，大不了重新啟動一個進程。多進程的超級核心，多進程可以在不同的機器運行，對，這才是一切服務的最終狀態，無數進程在不同機器運行，合作，每個進程都是可重啟的。

多線程，格局太小了，把優勢做到了極致。

多進程可以在多個主機上面跑，看看你有沒有這種需求。

個人經驗，除開apache的cgi，很少相同邏輯的程序用多進程，除非單進程監聽的fd的收包已成為瓶頸，可以多進程監聽相同的fd，也可監聽不同的fd。

能單線程解決的不用多線程，有些場景可用單線程非同步模式替代多線程；多線程一般作為處理線程，在前面加個隊列，方便控制。

一般問這個問題的時候，都不是必須考慮這個問題的時候

簡單來說多進程間資源相互隔離.. 大家的私密性比較好... 互相獨立.... 多線程共享大部分資源.....

redis和memcache同樣是KV存儲，性能都相當的好，一個是單進程一個是多線程...