關(guān)于多進(jìn)程和多線程，教科書上最經(jīng)典的一句話是“進(jìn)程是資源分配的最小單位，線程是CPU調(diào)度的最小單位”，這句話應(yīng)付考試基本上夠了，但如果在工作中遇到類似的選擇問題，那就沒有這么簡單了，選的不好，會讓你深受其害。

經(jīng)常在網(wǎng)絡(luò)上看到有的XDJM問“多進(jìn)程好還是多線程好？”、“Linux下用多進(jìn)程還是多線程？”等等期望一勞永逸的問題，我只能說：沒有最好，只有更好。根據(jù)實際情況來判斷，哪個更加合適就是哪個好。

我們按照多個不同的維度，來看看多線程和多進(jìn)程的對比（注：因為是感性的比較，因此都是相對的，不是說一個好得不得了，另外一個差的無法忍受）。

看起來比較簡單，優(yōu)勢對比上是“線程 3.5 v 2.5 進(jìn)程”，我們只管選線程就是了？

呵呵，有這么簡單我就不用在這里浪費口舌了，還是那句話，沒有絕對的好與壞，只有哪個更加合適的問題。我們來看實際應(yīng)用中究竟如何判斷更加合適。

1）需要頻繁創(chuàng)建銷毀的優(yōu)先用線程

原因請看上面的對比。

這種原則最常見的應(yīng)用就是Web服務(wù)器了，來一個連接建立一個線程，斷了就銷毀線程，要是用進(jìn)程，創(chuàng)建和銷毀的代價是很難承受的

2）需要進(jìn)行大量計算的優(yōu)先使用線程

所謂大量計算，當(dāng)然就是要耗費很多CPU，切換頻繁了，這種情況下線程是最合適的。

這種原則最常見的是圖像處理、算法處理。

3）強(qiáng)相關(guān)的處理用線程，弱相關(guān)的處理用進(jìn)程

什么叫強(qiáng)相關(guān)、弱相關(guān)？理論上很難定義，給個簡單的例子就明白了。

一般的Server需要完成如下任務(wù)：消息收發(fā)、消息處理?！跋⑹瞻l(fā)”和“消息處理”就是弱相關(guān)的任務(wù)，而“消息處理”里面可能又分為“消息解碼”、“業(yè)務(wù)處理”，這兩個任務(wù)相對來說相關(guān)性就要強(qiáng)多了。因此“消息收發(fā)”和“消息處理”可以分進(jìn)程設(shè)計，“消息解碼”、“業(yè)務(wù)處理”可以分線程設(shè)計。

當(dāng)然這種劃分方式不是一成不變的，也可以根據(jù)實際情況進(jìn)行調(diào)整。

4）可能要擴(kuò)展到多機(jī)分布的用進(jìn)程，多核分布的用線程

原因請看上面對比。

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

至于“數(shù)據(jù)共享、同步”、“編程、調(diào)試”、“可靠性”這幾個維度的所謂的“復(fù)雜、簡單”應(yīng)該怎么取舍，我只能說：沒有明確的選擇方法。但我可以告訴你一個選擇原則：如果多進(jìn)程和多線程都能夠滿足要求，那么選擇你最熟悉、最拿手的那個。

需要提醒的是：雖然我給了這么多的選擇原則，但實際應(yīng)用中基本上都是“進(jìn)程+線程”的結(jié)合方式，千萬不要真的陷入一種非此即彼的誤區(qū)。

1、進(jìn)程與線程

進(jìn)程是程序執(zhí)行時的一個實例，即它是程序已經(jīng)執(zhí)行到課中程度的數(shù)據(jù)結(jié)構(gòu)的匯集。從內(nèi)核的觀點看，進(jìn)程的目的就是擔(dān)當(dāng)分配系統(tǒng)資源（CPU時間、內(nèi)存等）的基本單位。

線程是進(jìn)程的一個執(zhí)行流，是CPU調(diào)度和分派的基本單位，它是比進(jìn)程更小的能獨立運行的基本單位。一個進(jìn)程由幾個線程組成（擁有很多相對獨立的執(zhí)行流的用戶程序共享應(yīng)用程序的大部分?jǐn)?shù)據(jù)結(jié)構(gòu)），線程與同屬一個進(jìn)程的其他的線程共享進(jìn)程所擁有的全部資源。

"進(jìn)程——資源分配的最小單位，線程——程序執(zhí)行的最小單位"

進(jìn)程有獨立的地址空間，一個進(jìn)程崩潰后，在保護(hù)模式下不會對其它進(jìn)程產(chǎn)生影響，而線程只是一個進(jìn)程中的不同執(zhí)行路徑。線程有自己的堆棧和局部變量，但線程沒有單獨的地址空間，一個線程死掉就等于整個進(jìn)程死掉，所以多進(jìn)程的程序要比多線程的程序健壯，但在進(jìn)程切換時，耗費資源較大，效率要差一些。但對于一些要求同時進(jìn)行并且又要共享某些變量的并發(fā)操作，只能用線程，不能用進(jìn)程。

總的來說就是：進(jìn)程有獨立的地址空間，線程沒有單獨的地址空間（同一進(jìn)程內(nèi)的線程共享進(jìn)程的地址空間）。

使用多線程的理由之一是和進(jìn)程相比，它是一種非常"節(jié)儉"的多任務(wù)操作方式。我們知道，在Linux系統(tǒng)下，啟動一個新的進(jìn)程必須分配給它獨立的地址空間，建立眾多的數(shù)據(jù)表來維護(hù)它的代碼段、堆棧段和數(shù)據(jù)段，這是一種"昂貴"的多任務(wù)工作方式。而運行于一個進(jìn)程中的多個線程，它們彼此之間使用相同的地址空間，共享大部分?jǐn)?shù)據(jù)，啟動一個線程所花費的空間遠(yuǎn)遠(yuǎn)小于啟動一個進(jìn)程所花費的空間，而且，線程間彼此切換所需的時間也遠(yuǎn)遠(yuǎn)小于進(jìn)程間切換所需要的時間。據(jù)統(tǒng)計，總的說來，一個進(jìn)程的開銷大約是一個線程開銷的30倍左右，當(dāng)然，在具體的系統(tǒng)上，這個數(shù)據(jù)可能會有較大的區(qū)別。

使用多線程的理由之二是線程間方便的通信機(jī)制。對不同進(jìn)程來說，它們具有獨立的數(shù)據(jù)空間，要進(jìn)行數(shù)據(jù)的傳遞只能通過通信的方式進(jìn)行，這種方式不僅費時，而且很不方便。線程則不然，由于同一進(jìn)程下的線程之間共享數(shù)據(jù)空間，所以一個線程的數(shù)據(jù)可以直接為其它線程所用，這不僅快捷，而且方便。當(dāng)然，數(shù)據(jù)的共享也帶來其他一些問題，有的變量不能同時被兩個線程所修改，有的子程序中聲明為static的數(shù)據(jù)更有可能給多線程程序帶來災(zāi)難性的打擊，這些正是編寫多線程程序時最需要注意的地方。

除了以上所說的優(yōu)點外，不和進(jìn)程比較，多線程程序作為一種多任務(wù)、并發(fā)的工作方式，當(dāng)然有以下的優(yōu)點：

• 提高應(yīng)用程序響應(yīng)。這對圖形界面的程序尤其有意義，當(dāng)一個操作耗時很長時，整個系統(tǒng)都會等待這個操作，此時程序不會響應(yīng)鍵盤、鼠標(biāo)、菜單的操作，而使用多線程技術(shù)，將耗時長的操作（time consuming）置于一個新的線程，可以避免這種尷尬的情況。
• 使多CPU系統(tǒng)更加有效。操作系統(tǒng)會保證當(dāng)線程數(shù)不大于CPU數(shù)目時，不同的線程運行于不同的CPU上。
• 改善程序結(jié)構(gòu)。一個既長又復(fù)雜的進(jìn)程可以考慮分為多個線程，成為幾個獨立或半獨立的運行部分，這樣的程序會利于理解和修改。

在linux上編程采用多線程還是多進(jìn)程的爭執(zhí)由來已久，這種爭執(zhí)最常見到在B/S通訊中服務(wù)端并發(fā)技術(shù) 的選型上，比如WEB服務(wù)器技術(shù)中，Apache是采用多進(jìn)程的（perfork模式，每客戶連接對應(yīng)一個進(jìn)程，每進(jìn)程中只存在唯一一個執(zhí)行線 程）。

從Unix發(fā)展歷史看，伴隨著Unix的誕生多進(jìn)程就出現(xiàn)了，而多線程很晚才被系統(tǒng)支持，例如Linux直到內(nèi)核2.6，才支持符合Posix規(guī)范的NPTL線程庫。進(jìn)程和線程的特點，也就是各自的優(yōu)缺點如下：

進(jìn)程優(yōu)點：編程、調(diào)試簡單，可靠性較高。進(jìn)程缺點：創(chuàng)建、銷毀、切換速度慢，內(nèi)存、資源占用大。線程優(yōu)點：創(chuàng)建、銷毀、切換速度快，內(nèi)存、資源占用小。線程缺點：編程、調(diào)試復(fù)雜，可靠性較差。

上面的對比可以歸結(jié)為一句話：“線程快而進(jìn)程可靠性高”。線程有個別名叫“輕量級進(jìn)程”，在有的書籍資料上介紹線程可以十倍、百倍的效率快于進(jìn)程；而進(jìn)程之間不共享數(shù)據(jù)，沒有鎖問題，結(jié)構(gòu)簡單，一個進(jìn)程崩潰不像線程那樣影響全局，因此比較可靠。我相信這個觀點可以被大部分人所接受，因為和我們所接受的知識概念是相符的。

在寫這篇文章前，我也屬于這“大部分人”，這兩年在用C語言編寫的幾個C/S通訊程序中，因時間緊總是采用多進(jìn)程并發(fā)技術(shù)，而且是比較簡單的現(xiàn)場為 每客戶fork()一個進(jìn)程，當(dāng)時總是擔(dān)心并發(fā)量增大時負(fù)荷能否承受，盤算著等時間充裕了將它改為多線程形式，或者改為預(yù)先創(chuàng)建進(jìn)程的形式，直到最近在網(wǎng)上看到了一篇論文《Linux系統(tǒng)下多線程與多進(jìn)程性能分析》才認(rèn)真思考這個問題，我自己也做了實驗。

下面是得出結(jié)論的實驗步驟和過程，結(jié)論究竟是怎樣的？感興趣就一起看看吧。

實驗代碼使用論文中的代碼樣例，做了少量修改，值得注意的是這樣的區(qū)別：

論文實驗和我的實驗時間不同，論文所處的年代linux內(nèi)核是2.4，我的實驗linux內(nèi)核是2.6，2.6使用的線程庫是NPTL，2.4使用的是老的Linux線程庫（用進(jìn)程模擬線程的那個LinuxThread）。論文實驗和我用的機(jī)器不同，論文描述了使用的環(huán)境：單cpu 機(jī)器基本配置為:celeron 2.0 GZ, 256M, Linux 9.2,內(nèi)核 2.4.8。我的環(huán)境是：雙核 Intel(R) Xeon(R) CPU 5130 @ 2.00GHz（做實驗時，禁掉了一核），512MG內(nèi)存，Red Hat Enterprise Linux ES release 4 (Nahant Update 4)，內(nèi)核2.6.9-42。

進(jìn)程實驗代碼（fork.c）：

線程實驗代碼（thread.c）：

兩段程序做的事情是一樣的，都是創(chuàng)建“若干”個進(jìn)程/線程，每個創(chuàng)建出的進(jìn)程/線程打印“若干”條“hello linux”字符串到控制臺和日志文件，兩個“若干”由兩個宏 P_NUMBER和COUNT分別定義，程序編譯指令如下：

gcc -o fork fork.c
gcc -lpthread -o thread thread.c

實驗通過time指令執(zhí)行兩個程序，抄錄time輸出的掛鐘時間（real時間）：

time ./fork
time ./thread

每批次的實驗通過改動宏 P_NUMBER和COUNT來調(diào)整進(jìn)程/線程數(shù)量和打印次數(shù)，每批次測試五輪，得到的結(jié)果如下：

一、重復(fù)論文實驗步驟

(注：本文平均值算法采用的是去掉一個最大值去掉一個最小值，然后平均)

本輪實驗是為了和論文作對比，因此將進(jìn)程/線程數(shù)量限制在255個，論文也是測試了255個進(jìn)程/線程分別進(jìn)行5次，10 次,50 次,100 次,500 次……10000 次打印的用時，論文得出的結(jié)果是：任務(wù)量較大時,多進(jìn)程比多線程效率高;而完成的任務(wù)量較小時,多線程比多進(jìn)程要快，重復(fù)打印 600 次時,多進(jìn)程與多線程所耗費的時間相同。

雖然我的實驗直到1000打印次數(shù)時，多進(jìn)程才開始領(lǐng)先，但考慮到使用的是NPTL線程庫的緣故，從而可以證實了論文的觀點。從我的實驗數(shù)據(jù)看，多線程和多進(jìn)程兩組數(shù)據(jù)非常接近，考慮到數(shù)據(jù)的提取具有瞬間性，因此可以認(rèn)為他們的速度是相同的。

是不是可以得出這樣的結(jié)論：多線程創(chuàng)建、銷毀速度快，而多線程切換速度快，這個結(jié)論我們會在第二個試驗中繼續(xù)試圖驗證

當(dāng)前的網(wǎng)絡(luò)環(huán)境中，我們更看中高并發(fā)、高負(fù)荷下的性能，縱觀前面的實驗步驟，最長的實驗周期不過2分鐘多一點，因此下面的實驗將向兩個方向延伸，第一，增加并發(fā)數(shù)量，第二，增加每進(jìn)程/線程的工作強(qiáng)度。

二、增加并發(fā)數(shù)量的實驗

下面的實驗打印次數(shù)不變，而進(jìn)程/線程數(shù)量逐漸增加。在實驗過程中多線程程序在后四組（線程數(shù)350，500，800,1000）的測試中都出現(xiàn)了“段錯誤”，出現(xiàn)錯誤的原因和多線程預(yù)分配線程棧有關(guān)。

實驗中的計算機(jī)CPU是32位，尋址最大范圍是4GB（2的32次方），Linux是按照3GB/1GB的方式來分配內(nèi)存，其中1GB屬于所有進(jìn)程共享的內(nèi)核空間，3GB屬于用戶空間（進(jìn)程虛擬內(nèi)存空間）。Linux2.6的默認(rèn)線程棧大小是8M（通過ulimit -a查看），對于多線程，在創(chuàng)建線程的時候系統(tǒng)會為每一個線程預(yù)分配線程棧地址空間，也就是8M的虛擬內(nèi)存空間。線程數(shù)量太多時，線程棧累計的大小將超過進(jìn)程虛擬內(nèi)存空間大小（計算時需要排除程序文本、數(shù)據(jù)、共享庫等占用的空間），這就是實驗中出現(xiàn)的“段錯誤”的原因。

Linux2.6的默認(rèn)線程棧大小可以通過 ulimit -s 命令查看或修改，我們可以計算出線程數(shù)的最大上線: (1024102410243) / (10241024*8) = 384，實際數(shù)字應(yīng)該略小與384，因為還要計算程序文本、數(shù)據(jù)、共享庫等占用的空間。在當(dāng)今的稍顯繁忙的WEB服務(wù)器上，突破384的并發(fā)訪問并不是稀 罕的事情，要繼續(xù)下面的實驗需要將默認(rèn)線程棧的大小減小，但這樣做有一定的風(fēng)險，比如線程中的函數(shù)分配了大量的自動變量或者函數(shù)涉及很深的棧幀（典型的是 遞歸調(diào)用），線程棧就可能不夠用了。可以配合使用POSIX.1規(guī)定的兩個線程屬性guardsize和stackaddr來解決線程棧溢出問 題，guardsize控制著線程棧末尾之后的一篇內(nèi)存區(qū)域，一旦線程棧在使用中溢出并到達(dá)了這片內(nèi)存，程序可以捕獲系統(tǒng)內(nèi)核發(fā)出的告警信號，然后使用 malloc獲取另外的內(nèi)存，并通過stackaddr改變線程棧的位置，以獲得額外的棧空間，這個動態(tài)擴(kuò)展棧空間辦法需要手工編程，而且非常麻煩。

有兩種方法可以改變線程棧的大小，使用 ulimit -s 命令改變系統(tǒng)默認(rèn)線程棧的大小，或者在代碼中創(chuàng)建線程時通過pthread_attr_setstacksize函數(shù)改變棧尺寸，在實驗中使用的是第一種，在程序運行前先執(zhí)行ulimit指令將默認(rèn)線程棧大小改為1M：

ulimit -s 1024
time ./thread

【實驗結(jié)論】

當(dāng)線程/進(jìn)程逐漸增多時，執(zhí)行相同任務(wù)時，線程所花費時間相對于進(jìn)程有下降的趨勢（本人懷疑后兩組數(shù)據(jù)受系統(tǒng)其他瓶頸的影響），這是不是進(jìn)一步驗證了多線程創(chuàng)建、銷毀速度快，而多進(jìn)程切換速度快。

三、增加每進(jìn)程/線程的工作強(qiáng)度的實驗

這次將程序打印數(shù)據(jù)增大，原來打印字符串為：

現(xiàn)在修改為每次打印256個字節(jié)數(shù)據(jù):

【實驗結(jié)論】

從上面的實驗比對結(jié)果看，即使Linux2.6使用了NPTL線程庫，多線程比較多進(jìn)程在效率上沒有任何的優(yōu)勢，在線程數(shù)增大時多線程程序還出現(xiàn)了運行錯誤，實驗可以得出下面的結(jié)論：

在Linux2.6上，多線程并不比多進(jìn)程速度快，考慮到線程棧的問題，多進(jìn)程在并發(fā)上有優(yōu)勢。

四、多進(jìn)程和多線程在創(chuàng)建和銷毀上的效率比較

預(yù)先創(chuàng)建進(jìn)程或線程可以節(jié)省進(jìn)程或線程的創(chuàng)建、銷毀時間，在實際的應(yīng)用中很多程序使用了這樣的策略，比如Apapche預(yù)先創(chuàng)建進(jìn)程、Tomcat 預(yù)先創(chuàng)建線程，通常叫做進(jìn)程池或線程池。在大部分人的概念中，進(jìn)程或線程的創(chuàng)建、銷毀是比較耗時的，在stevesn的著作《Unix網(wǎng)絡(luò)編程》中有這樣 的對比圖（第一卷 第三版 30章 客戶/服務(wù)器程序設(shè)計范式）：

stevens已駕鶴西去多年，但《Unix網(wǎng)絡(luò)編程》一書仍具有巨大的影響力，上表中stevens比較了三種服務(wù)器上多進(jìn)程和多線程的執(zhí)行效 率，因為三種服務(wù)器所用計算機(jī)不同，表中數(shù)據(jù)只能縱向比較，而橫向無可比性，stevens在書中提供了這些測試程序的源碼（也可以在網(wǎng)上下載）。書中介 紹了測試環(huán)境，兩臺與服務(wù)器處于同一子網(wǎng)的客戶機(jī)，每個客戶并發(fā)5個進(jìn)程（服務(wù)器同一時間最多10個連接），每個客戶請求從服務(wù)器獲取4000字節(jié)數(shù)據(jù)， 預(yù)先派生子進(jìn)程或線程的數(shù)量是15個。

第0行是迭代模式的基準(zhǔn)測試程序，服務(wù)器程序只有一個進(jìn)程在運行（同一時間只能處理一個客戶請求），因為沒有進(jìn)程或線程的調(diào)度切換，因此它的速度是 最快的，表中其他服務(wù)模式的運行數(shù)值是比迭代模式多出的差值。迭代模式很少用到，在現(xiàn)有的互聯(lián)網(wǎng)服務(wù)中，DNS、NTP服務(wù)有它的影子。第1～5行是多進(jìn) 程服務(wù)模式，期中第1行使用現(xiàn)場fork子進(jìn)程，2～5行都是預(yù)先創(chuàng)建15個子進(jìn)程模式，在多進(jìn)程程序中套接字傳遞不太容易（相對于多線 程），stevens在這里提供了4個不同的處理accept的方法。6～8行是多線程服務(wù)模式，第6行是現(xiàn)場為客戶請求創(chuàng)建子線程，7～8行是預(yù)先創(chuàng)建 15個線程。表中有的格子是空白的，是因為這個系統(tǒng)不支持此種模式，比如當(dāng)年的BSD不支持線程，因此BSD上多線程的數(shù)據(jù)都是空白的。

從數(shù)據(jù)的比對看，現(xiàn)場為每客戶fork一個進(jìn)程的方式是最慢的，差不多有20倍的速度差異，Solaris上的現(xiàn)場fork和預(yù)先創(chuàng)建子進(jìn)程的最大差別是504.2 ：21.5，但我們不能理解為預(yù)先創(chuàng)建模式比現(xiàn)場fork快20倍，原因有兩個：

1. stevens的測試已是十幾年前的了，現(xiàn)在的OS和CPU已起了翻天覆地的變化，表中的數(shù)值需要重新測試。
2. stevens沒有提供服務(wù)器程序整體的運行計時，我們無法理解504.2 ：21.5的實際運行效率，有可能是1504.2 : 1021.5，也可能是100503.2 : 100021.5，20倍的差異可能很大，也可能可以忽略。

因此我寫了下面的實驗程序，來計算在Linux2.6上創(chuàng)建、銷毀10萬個進(jìn)程/線程的絕對用時。

創(chuàng)建10萬個進(jìn)程（forkcreat.c）:

創(chuàng)建10萬個線程（pthreadcreat.c）:

從數(shù)據(jù)可以看出，多線程比多進(jìn)程在效率上有10多倍的優(yōu)勢，但不能讓我們在使用哪種并發(fā)模式上定性，這讓我想起多年前政治課上的一個場景：在講到優(yōu)越性時，面對著幾個對此發(fā)表質(zhì)疑評論的調(diào)皮男生，我們的政治老師發(fā)表了高見，“不能只橫向地和當(dāng)今的發(fā)達(dá)國家比，你應(yīng)該縱向地和過去中國幾十年的發(fā)展歷史 比”。政治老師的話套用在當(dāng)前簡直就是真理，我們看看，即使是在賽揚CPU上，創(chuàng)建、銷毀進(jìn)程/線程的速度都是空前的，可以說是有質(zhì)的飛躍的，平均創(chuàng)建銷毀一個進(jìn)程的速度是0.18毫秒，對于當(dāng)前服務(wù)器幾百、幾千的并發(fā)量，還有預(yù)先派生子進(jìn)程/線程的必要嗎？

預(yù)先派生子進(jìn)程/線程比現(xiàn)場創(chuàng)建子進(jìn)程/線程要復(fù)雜很多，不僅要對池中進(jìn)程/線程數(shù)量進(jìn)行動態(tài)管理，還要解決多進(jìn)程/多線程對accept的“搶” 問題，在stevens的測試程序中，使用了“驚群”和“鎖”技術(shù)。即使stevens的數(shù)據(jù)表格中，預(yù)先派生線程也不見得比現(xiàn)場創(chuàng)建線程快，在 《Unix網(wǎng)絡(luò)編程》第三版中，新作者參照stevens的測試也提供了一組數(shù)據(jù)，在這組數(shù)據(jù)中，現(xiàn)場創(chuàng)建線程模式比預(yù)先派生線程模式已有了效率上的優(yōu)勢。因此我對這一節(jié)實驗下的結(jié)論是：

預(yù)先派生進(jìn)程/線程的模式（進(jìn)程池、線程池）技術(shù)，不僅復(fù)雜，在效率上也無優(yōu)勢，在新的應(yīng)用中可以放心大膽地為客戶連接請求去現(xiàn)場創(chuàng)建進(jìn)程和線程。

我想，這是fork迷們最愿意看到的結(jié)論了。

五、雙核系統(tǒng)重復(fù)論文實驗步驟

【實驗結(jié)論】

雙核處理器在完成任務(wù)量較少時，沒有系統(tǒng)其他瓶頸因素影響時基本上是單核的兩倍，在任務(wù)量較多時，受系統(tǒng)其他瓶頸因素的影響，速度明顯趨近于單核的速度。

六、并發(fā)服務(wù)的不可測性

看到這里，你會感覺到我有挺進(jìn)程、貶線程的論調(diào)，實際上對于現(xiàn)實中的并發(fā)服務(wù)具有不可測性，前面的實驗和結(jié)論只可做參考，而不可定性。

結(jié)束語

本篇文章比較了Linux系統(tǒng)上多線程和多進(jìn)程的運行效率，在實際應(yīng)用時還有其他因素的影響，比如網(wǎng)絡(luò)通訊時采用長連接還是短連接，是否采用 select、poll，這些都可能影響到并發(fā)模式的選型。