本文原題“聊聊TCP連接耗時(shí)的那些事兒”，本次收錄已征得作者同意，轉(zhuǎn)載請(qǐng)聯(lián)系作者。有少許改動(dòng)。

1、系列文章引言

1.1 文章目的

作為即時(shí)通訊技術(shù)的開發(fā)者來說，高性能、高并發(fā)相關(guān)的技術(shù)概念早就了然與胸，什么線程池、零拷貝、多路復(fù)用、事件驅(qū)動(dòng)、epoll等等名詞信手拈來，又或許你對(duì)具有這些技術(shù)特征的技術(shù)框架比如：Java的Netty、Php的workman、Go的nget等熟練掌握。但真正到了面視或者技術(shù)實(shí)踐過程中遇到無法釋懷的疑惑時(shí)，方知自已所掌握的不過是皮毛。

返璞歸真、回歸本質(zhì)，這些技術(shù)特征背后的底層原理到底是什么？如何能通俗易懂、毫不費(fèi)力真正透徹理解這些技術(shù)背后的原理，正是《從根上理解高性能、高并發(fā)》系列文章所要分享的。

1.2 文章源起

我（Jack Jiang）為即時(shí)通訊網(wǎng)整理了相當(dāng)多有關(guān)IM、消息推送等即時(shí)通訊技術(shù)相關(guān)的資源和文章，從最開始的開源IM框架MobileIMSDK，到網(wǎng)絡(luò)編程經(jīng)典巨著《TCP/IP詳解》的在線版本，再到IM開發(fā)綱領(lǐng)性文章《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》，以及網(wǎng)絡(luò)編程由淺到深的《網(wǎng)絡(luò)編程懶人入門》、《腦殘式網(wǎng)絡(luò)編程入門》、《高性能網(wǎng)絡(luò)編程》、《不為人知的網(wǎng)絡(luò)編程》系列文章。

越往知識(shí)的深處走，越覺得對(duì)即時(shí)通訊技術(shù)了解的太少。于是后來，為了讓開發(fā)者門更好地從基礎(chǔ)電信技術(shù)的角度理解網(wǎng)絡(luò)（尤其移動(dòng)網(wǎng)絡(luò)）特性，我跨專業(yè)收集整理了《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門》系列高階文章。這系列文章已然是普通即時(shí)通訊開發(fā)者的網(wǎng)絡(luò)通信技術(shù)知識(shí)邊界，加上之前這些網(wǎng)絡(luò)編程資料，解決網(wǎng)絡(luò)通信方面的知識(shí)盲點(diǎn)基本夠用了。

對(duì)于即時(shí)通訊IM這種系統(tǒng)的開發(fā)來說，網(wǎng)絡(luò)通信知識(shí)確實(shí)非常重要，但回歸到技術(shù)本質(zhì)，實(shí)現(xiàn)網(wǎng)絡(luò)通信本身的這些技術(shù)特征：包括上面提到的線程池、零拷貝、多路復(fù)用、事件驅(qū)動(dòng)等等，它們的本質(zhì)是什么？底層原理又是怎樣？這就是整理本系列文章的目的，希望對(duì)你有用。

1.3 文章目錄

《從根上理解高性能、高并發(fā)(一)：深入計(jì)算機(jī)底層，理解線程與線程池》（* 本文）

《從根上理解高性能、高并發(fā)(二)：深入操作系統(tǒng)，理解I/O與零拷貝技術(shù) （稍后發(fā)布..）》

《從根上理解高性能、高并發(fā)(三)：深入操作系統(tǒng)，徹底理解I/O多路復(fù)用 （稍后發(fā)布..）》

《從根上理解高性能、高并發(fā)(四)：深入操作系統(tǒng)，徹底理解同步與異步 （稍后發(fā)布..）》

《從根上理解高性能、高并發(fā)(五)：高并發(fā)高性能服務(wù)器到底是如何實(shí)現(xiàn)的 （稍后發(fā)布..）》

1.4 本篇概述

本篇是該系列文章的開篇，主要是從CPU這一層來講解多線程以及線程池原理，力求避免復(fù)雜的技術(shù)概念羅列，盡量做到通俗易懂、老少皆宜。

2、本文作者

應(yīng)作者要求，不提供真名，也不提供個(gè)人照片。

本文作者主要技術(shù)方向?yàn)榛ヂ?lián)網(wǎng)后端、高并發(fā)高性能服務(wù)器、檢索引擎技術(shù)，網(wǎng)名是“碼農(nóng)的荒島求生”，公眾號(hào)“碼農(nóng)的荒島求生”。感謝作者的無私分享。

3、一切要從CPU說起

你可能會(huì)有疑問，講多線程為什么要從CPU說起呢？原因很簡單，在這里沒有那些時(shí)髦的概念，你可以更加清晰的看清問題的本質(zhì)。

實(shí)際情況是：CPU并不知道線程、進(jìn)程之類的概念。

CPU只知道兩件事：

• 1）從內(nèi)存中取出指令；
• 2）執(zhí)行指令，然后回到 1）。 

你看，在這里CPU確實(shí)是不知道什么進(jìn)程、線程之類的概念。

接下來的問題就是CPU從哪里取出指令呢？答案是來自一個(gè)被稱為Program Counter（簡稱PC）的寄存器，也就是我們熟知的程序計(jì)數(shù)器，在這里大家不要把寄存器想的太神秘，你可以簡單的把寄存器理解為內(nèi)存，只不過存取速度更快而已。

PC寄存器中存放的是什么呢？這里存放的是指令在內(nèi)存中的地址，什么指令呢？是CPU將要執(zhí)行的下一條指令。

那么是誰來設(shè)置PC寄存器中的指令地址呢？

原來PC寄存器中的地址默認(rèn)是自動(dòng)加1的，這當(dāng)然是有道理的，因?yàn)榇蟛糠智闆r下CPU都是一條接一條順序執(zhí)行，當(dāng)遇到if、else時(shí)，這種順序執(zhí)行就被打破了，CPU在執(zhí)行這類指令時(shí)會(huì)根據(jù)計(jì)算結(jié)果來動(dòng)態(tài)改變PC寄存器中的值，這樣CPU就可以正確的跳轉(zhuǎn)到需要執(zhí)行的指令了。

聰明的你一定會(huì)問，那么PC中的初始值是怎么被設(shè)置的呢？

在回答這個(gè)問題之前我們需要知道CPU執(zhí)行的指令來自哪里？是來自內(nèi)存，廢話，內(nèi)存中的指令是從磁盤中保存的可執(zhí)行程序加載過來的，磁盤中可執(zhí)行程序是編譯器生成的，編譯器又是從哪里生成的機(jī)器指令呢？答案就是我們定義的函數(shù)。

注意是函數(shù)，函數(shù)被編譯后才會(huì)形成CPU執(zhí)行的指令，那么很自然的，我們該如何讓CPU執(zhí)行一個(gè)函數(shù)呢？顯然我們只需要找到函數(shù)被編譯后形成的第一條指令就可以了，第一條指令就是函數(shù)入口。

現(xiàn)在你應(yīng)該知道了吧，我們想要CPU執(zhí)行一個(gè)函數(shù)，那么只需要把該函數(shù)對(duì)應(yīng)的第一條機(jī)器指令的地址寫入PC寄存器就可以了，這樣我們寫的函數(shù)就開始被CPU執(zhí)行起來啦。

你可能會(huì)有疑問，這和線程有什么關(guān)系呢？

4、從CPU到操作系統(tǒng)

上一小節(jié)中我們明白了CPU的工作原理，我們想讓CPU執(zhí)行某個(gè)函數(shù)，那么只需要把函數(shù)對(duì)應(yīng)的第一條機(jī)器執(zhí)行裝入PC寄存器就可以了，這樣即使沒有操作系統(tǒng)我們也可以讓CPU執(zhí)行程序，雖然可行但這是一個(gè)非常繁瑣的過程。

我們需要：

• 1）在內(nèi)存中找到一塊大小合適的區(qū)域裝入程序；
• 2）找到函數(shù)入口，設(shè)置好PC寄存器讓CPU開始執(zhí)行程序。

這兩個(gè)步驟絕不是那么容易的事情，如果每次在執(zhí)行程序時(shí)程序員自己手動(dòng)實(shí)現(xiàn)上述兩個(gè)過程會(huì)瘋掉的，因此聰明的程序員就會(huì)想干脆直接寫個(gè)程序來自動(dòng)完成上面兩個(gè)步驟吧。

機(jī)器指令需要加載到內(nèi)存中執(zhí)行，因此需要記錄下內(nèi)存的起始地址和長度；同時(shí)要找到函數(shù)的入口地址并寫到PC寄存器中，想一想這是不是需要一個(gè)數(shù)據(jù)結(jié)構(gòu)來記錄下這些信息。

數(shù)據(jù)結(jié)構(gòu)大致如下：

struct *** {

   void* start_addr;

   intlen;

   void* start_point;

   ...

};

接下來就是起名字時(shí)刻。

這個(gè)數(shù)據(jù)結(jié)構(gòu)總要有個(gè)名字吧，這個(gè)結(jié)構(gòu)體用來記錄什么信息呢？記錄的是程序在被加載到內(nèi)存中的運(yùn)行狀態(tài)，程序從磁盤加載到內(nèi)存跑起來叫什么好呢？干脆就叫進(jìn)程（Process）好了，我們的指導(dǎo)原則就是一定要聽上去比較神秘，總之大家都不容易弄懂就對(duì)了，我將其稱為“弄不懂原則”。

就這樣進(jìn)程誕生了。

CPU執(zhí)行的第一個(gè)函數(shù)也起個(gè)名字，第一個(gè)要被執(zhí)行的函數(shù)聽起來比較重要，干脆就叫main函數(shù)吧。

完成上述兩個(gè)步驟的程序也要起個(gè)名字，根據(jù)“弄不懂原則”這個(gè)“簡單”的程序就叫操作系統(tǒng)（Operating System）好啦。

就這樣操作系統(tǒng)誕生了，程序員要想運(yùn)行程序再也不用自己手動(dòng)加載一遍了。

現(xiàn)在進(jìn)程和操作系統(tǒng)都有了，一切看上去都很完美。

5、從單核到多核，如何充分利用多核

人類的一大特點(diǎn)就是生命不息折騰不止，從單核折騰到了多核。

這時(shí)，假設(shè)我們想寫一個(gè)程序并且要分利用多核該怎么辦呢？

有的同學(xué)可能會(huì)說不是有進(jìn)程嗎，多開幾個(gè)進(jìn)程不就可以了？

聽上去似乎很有道理，但是主要存在這樣幾個(gè)問題：

• 1）進(jìn)程是需要占用內(nèi)存空間的(從上一節(jié)能看到這一點(diǎn))，如果多個(gè)進(jìn)程基于同一個(gè)可執(zhí)行程序，那么這些進(jìn)程其內(nèi)存區(qū)域中的內(nèi)容幾乎完全相同，這顯然會(huì)造成內(nèi)存的浪費(fèi)；
• 2）計(jì)算機(jī)處理的任務(wù)可能是比較復(fù)雜的，這就涉及到了進(jìn)程間通信，由于各個(gè)進(jìn)程處于不同的內(nèi)存地址空間，進(jìn)程間通信天然需要借助操作系統(tǒng)，這就在增大編程難度的同時(shí)也增加了系統(tǒng)開銷。

該怎么辦呢？

6、從進(jìn)程到線程

讓我再來仔細(xì)的想一想這個(gè)問題，所謂進(jìn)程無非就是內(nèi)存中的一段區(qū)域，這段區(qū)域中保存了CPU執(zhí)行的機(jī)器指令以及函數(shù)運(yùn)行時(shí)的堆棧信息，要想讓進(jìn)程運(yùn)行，就把main函數(shù)的第一條機(jī)器指令地址寫入PC寄存器，這樣進(jìn)程就運(yùn)行起來了。

進(jìn)程的缺點(diǎn)在于只有一個(gè)入口函數(shù)，也就是main函數(shù)，因此進(jìn)程中的機(jī)器指令只能被一個(gè)CPU執(zhí)行，那么有沒有辦法讓多個(gè)CPU來執(zhí)行同一個(gè)進(jìn)程中的機(jī)器指令呢？

聰明的你應(yīng)該能想到，既然我們可以把main函數(shù)的第一條指令地址寫入PC寄存器，那么其它函數(shù)和main函數(shù)又有什么區(qū)別呢？

答案是沒什么區(qū)別，main函數(shù)的特殊之處無非就在于是CPU執(zhí)行的第一個(gè)函數(shù)，除此之外再無特別之處，我們可以把PC寄存器指向main函數(shù)，就可以把PC寄存器指向任何一個(gè)函數(shù)。

當(dāng)我們把PC寄存器指向非main函數(shù)時(shí)，線程就誕生了。

至此我們解放了思想，一個(gè)進(jìn)程內(nèi)可以有多個(gè)入口函數(shù)，也就是說屬于同一個(gè)進(jìn)程中的機(jī)器指令可以被多個(gè)CPU同時(shí)執(zhí)行。

注意：這是一個(gè)和進(jìn)程不同的概念，創(chuàng)建進(jìn)程時(shí)我們需要在內(nèi)存中找到一塊合適的區(qū)域以裝入進(jìn)程，然后把CPU的PC寄存器指向main函數(shù)，也就是說進(jìn)程中只有一個(gè)執(zhí)行流。

但是現(xiàn)在不一樣了，多個(gè)CPU可以在同一個(gè)屋檐下(進(jìn)程占用的內(nèi)存區(qū)域)同時(shí)執(zhí)行屬于該進(jìn)程的多個(gè)入口函數(shù)，也就是說現(xiàn)在一個(gè)進(jìn)程內(nèi)可以有多個(gè)執(zhí)行流了。

總是叫執(zhí)行流好像有點(diǎn)太容易理解了，再次祭出”弄不懂原則“，起個(gè)不容易懂的名字，就叫線程吧。

這就是線程的由來。

操作系統(tǒng)為每個(gè)進(jìn)程維護(hù)了一堆信息，用來記錄進(jìn)程所處的內(nèi)存空間等，這堆信息記為數(shù)據(jù)集A。

同樣的，操作系統(tǒng)也需要為線程維護(hù)一堆信息，用來記錄線程的入口函數(shù)或者棧信息等，這堆數(shù)據(jù)記為數(shù)據(jù)集B。

顯然數(shù)據(jù)集B要比數(shù)據(jù)A的量要少，同時(shí)不像進(jìn)程，創(chuàng)建一個(gè)線程時(shí)無需去內(nèi)存中找一段內(nèi)存空間，因?yàn)榫€程是運(yùn)行在所處進(jìn)程的地址空間的，這塊地址空間在程序啟動(dòng)時(shí)已經(jīng)創(chuàng)建完畢，同時(shí)線程是程序在運(yùn)行期間創(chuàng)建的（進(jìn)程啟動(dòng)后），因此當(dāng)線程開始運(yùn)行的時(shí)候這塊地址空間就已經(jīng)存在了，線程可以直接使用。這就是為什么各種教材上提的創(chuàng)建線程要比創(chuàng)建進(jìn)程快的原因（當(dāng)然還有其它原因）。

值得注意的是，有了線程這個(gè)概念后，我們只需要進(jìn)程開啟后創(chuàng)建多個(gè)線程就可以讓所有CPU都忙起來，這就是所謂高性能、高并發(fā)的根本所在。

很簡單，只需要?jiǎng)?chuàng)建出數(shù)量合適的線程就可以了。

另外值得注意的一點(diǎn)是：由于各個(gè)線程共享進(jìn)程的內(nèi)存地址空間，因此線程之間的通信無需借助操作系統(tǒng)，這給程序員帶來極大方便的同時(shí)也帶來了無盡的麻煩，多線程遇到的多數(shù)問題都出自于線程間通信簡直太方便了以至于非常容易出錯(cuò)。出錯(cuò)的根源在于CPU執(zhí)行指令時(shí)根本沒有線程的概念，多線程編程面臨的互斥與同步問題需要程序員自己解決，關(guān)于互斥與同步問題限于篇幅就不詳細(xì)展開了，大部分的操作系統(tǒng)資料都有詳細(xì)講解。

最后需要提醒的是：雖然前面關(guān)于線程講解使用的圖中用了多個(gè)CPU，但不是說一定要有多核才能使用多線程，在單核的情況下一樣可以創(chuàng)建出多個(gè)線程，原因在于線程是操作系統(tǒng)層面的實(shí)現(xiàn)，和有多少個(gè)核心是沒有關(guān)系的，CPU在執(zhí)行機(jī)器指令時(shí)也意識(shí)不到執(zhí)行的機(jī)器指令屬于哪個(gè)線程。即使在只有一個(gè)CPU的情況下，操作系統(tǒng)也可以通過線程調(diào)度讓各個(gè)線程“同時(shí)”向前推進(jìn)，方法就是將CPU的時(shí)間片在各個(gè)線程之間來回分配，這樣多個(gè)線程看起來就是“同時(shí)”運(yùn)行了，但實(shí)際上任意時(shí)刻還是只有一個(gè)線程在運(yùn)行。

7、線程與內(nèi)存

在前面的討論中我們知道了線程和CPU的關(guān)系，也就是把CPU的PC寄存器指向線程的入口函數(shù)，這樣線程就可以運(yùn)行起來了，這就是為什么我們創(chuàng)建線程時(shí)必須指定一個(gè)入口函數(shù)的原因。

無論使用任何編程語言，創(chuàng)建一個(gè)線程大體相同：

// 設(shè)置線程入口函數(shù)DoSomething

thread = CreateThread(DoSomething);

// 讓線程運(yùn)行起來

thread.Run();

那么線程和內(nèi)存又有什么關(guān)聯(lián)呢？

我們知道函數(shù)在被執(zhí)行的時(shí)產(chǎn)生的數(shù)據(jù)包括：函數(shù)參數(shù)、局部變量、返回地址等信息。這些信息是保存在棧中的，線程這個(gè)概念還沒有出現(xiàn)時(shí)進(jìn)程中只有一個(gè)執(zhí)行流，因此只有一個(gè)棧，這個(gè)棧的棧底就是進(jìn)程的入口函數(shù)，也就是main函數(shù)。

假設(shè)main函數(shù)調(diào)用了funA，funcA又調(diào)用了funcB，如圖所示：

那么有了線程以后了呢？

有了線程以后一個(gè)進(jìn)程中就存在多個(gè)執(zhí)行入口，即同時(shí)存在多個(gè)執(zhí)行流，那么只有一個(gè)執(zhí)行流的進(jìn)程需要一個(gè)棧來保存運(yùn)行時(shí)信息，那么很顯然有多個(gè)執(zhí)行流時(shí)就需要有多個(gè)棧來保存各個(gè)執(zhí)行流的信息，也就是說操作系統(tǒng)要為每個(gè)線程在進(jìn)程的地址空間中分配一個(gè)棧，即每個(gè)線程都有獨(dú)屬于自己的棧，能意識(shí)到這一點(diǎn)是極其關(guān)鍵的。

同時(shí)我們也可以看到，創(chuàng)建線程是要消耗進(jìn)程內(nèi)存空間的，這一點(diǎn)也值得注意。

8、線程的使用

現(xiàn)在有了線程的概念，那么接下來作為程序員我們該如何使用線程呢？

從生命周期的角度講，線程要處理的任務(wù)有兩類：長任務(wù)和短任務(wù)。

1）長任務(wù)（long-lived tasks）：

顧名思義，就是任務(wù)存活的時(shí)間很長，比如以我們常用的word為例，我們在word中編輯的文字需要保存在磁盤上，往磁盤上寫數(shù)據(jù)就是一個(gè)任務(wù)，那么這時(shí)一個(gè)比較好的方法就是專門創(chuàng)建一個(gè)寫磁盤的線程，該寫線程的生命周期和word進(jìn)程是一樣的，只要打開word就要?jiǎng)?chuàng)建出該寫線程，當(dāng)用戶關(guān)閉word時(shí)該線程才會(huì)被銷毀，這就是長任務(wù)。

這種場景非常適合創(chuàng)建專用的線程來處理某些特定任務(wù)，這種情況比較簡單。

有長任務(wù)，相應(yīng)的就有短任務(wù)。

2）短任務(wù)（short-lived tasks）：

這個(gè)概念也很簡單，那就是任務(wù)的處理時(shí)間很短，比如一次網(wǎng)絡(luò)請(qǐng)求、一次數(shù)據(jù)庫查詢等，這種任務(wù)可以在短時(shí)間內(nèi)快速處理完成。因此短任務(wù)多見于各種Server，像web server、database server、file server、mail server等，這也是互聯(lián)網(wǎng)行業(yè)的同學(xué)最常見的場景，這種場景是我們要重點(diǎn)討論的。

這種場景有兩個(gè)特點(diǎn)：一個(gè)是任務(wù)處理所需時(shí)間短；另一個(gè)是任務(wù)數(shù)量巨大。

如果讓你來處理這種類型的任務(wù)該怎么辦呢？

你可能會(huì)想，這很簡單啊，當(dāng)server接收到一個(gè)請(qǐng)求后就創(chuàng)建一個(gè)線程來處理任務(wù)，處理完成后銷毀該線程即可，So easy。

這種方法通常被稱為thread-per-request，也就是說來一個(gè)請(qǐng)求就創(chuàng)建一個(gè)線程：

如果是長任務(wù)，那么這種方法可以工作的很好，但是對(duì)于大量的短任務(wù)這種方法雖然實(shí)現(xiàn)簡單但是有缺點(diǎn)。

具體是以下這樣的缺點(diǎn)：

• 1）從前幾節(jié)我們能看到，線程是操作系統(tǒng)中的概念(這里不討論用戶態(tài)線程實(shí)現(xiàn)、協(xié)程之類)，因此創(chuàng)建線程天然需要借助操作系統(tǒng)來完成，操作系統(tǒng)創(chuàng)建和銷毀線程是需要消耗時(shí)間的；
• 2）每個(gè)線程需要有自己獨(dú)立的棧，因此當(dāng)創(chuàng)建大量線程時(shí)會(huì)消耗過多的內(nèi)存等系統(tǒng)資源。

這就好比你是一個(gè)工廠老板（想想都很開心有沒有），手里有很多訂單，每來一批訂單就要招一批工人，生產(chǎn)的產(chǎn)品非常簡單，工人們很快就能處理完，處理完這批訂單后就把這些千辛萬苦招過來的工人辭退掉，當(dāng)有新的訂單時(shí)你再千辛萬苦的招一遍工人，干活兒5分鐘招人10小時(shí)，如果你不是勵(lì)志要讓企業(yè)倒閉的話大概是不會(huì)這么做到的。

因此一個(gè)更好的策略就是招一批人后就地養(yǎng)著，有訂單時(shí)處理訂單，沒有訂單時(shí)大家可以閑呆著。

這就是線程池的由來。

9、從多線程到線程池

線程池的概念是非常簡單的，無非就是創(chuàng)建一批線程，之后就不再釋放了，有任務(wù)就提交給這些線程處理，因此無需頻繁的創(chuàng)建、銷毀線程，同時(shí)由于線程池中的線程個(gè)數(shù)通常是固定的，也不會(huì)消耗過多的內(nèi)存，因此這里的思想就是復(fù)用、可控。

10、線程池是如何工作的

可能有的同學(xué)會(huì)問，該怎么給線程池提交任務(wù)呢？這些任務(wù)又是怎么給到線程池中線程呢？

很顯然，數(shù)據(jù)結(jié)構(gòu)中的隊(duì)列天然適合這種場景，提交任務(wù)的就是生產(chǎn)者，消費(fèi)任務(wù)的線程就是消費(fèi)者，實(shí)際上這就是經(jīng)典的生產(chǎn)者-消費(fèi)者問題。

現(xiàn)在你應(yīng)該知道為什么操作系統(tǒng)課程要講、面試要問這個(gè)問題了吧，因?yàn)槿绻銓?duì)生產(chǎn)者-消費(fèi)者問題不理解的話，本質(zhì)上你是無法正確的寫出線程池的。

限于篇幅在這里不打算詳細(xì)的講解生產(chǎn)者消費(fèi)者問題，參考操作系統(tǒng)相關(guān)資料就能獲取答案。這里我打算講一講一般提交給線程池的任務(wù)是什么樣子的。

一般來說提交給線程池的任務(wù)包含兩部分：

• 1) 需要被處理的數(shù)據(jù)；
• 2) 處理數(shù)據(jù)的函數(shù)。

偽碼描述一下：

struct task {

    void* data;     // 任務(wù)所攜帶的數(shù)據(jù)

    handler handle; // 處理數(shù)據(jù)的方法

}

（注意：你也可以把代碼中的struct理解成class，也就是對(duì)象)

線程池中的線程會(huì)阻塞在隊(duì)列上，當(dāng)生產(chǎn)者向隊(duì)列中寫入數(shù)據(jù)后，線程池中的某個(gè)線程會(huì)被喚醒，該線程從隊(duì)列中取出上述結(jié)構(gòu)體(或者對(duì)象)，以結(jié)構(gòu)體(或者對(duì)象)中的數(shù)據(jù)為參數(shù)并調(diào)用處理函數(shù)。

偽碼如下：

while(true) {

  struct task = GetFromQueue(); // 從隊(duì)列中取出數(shù)據(jù)

  task->handle(task->data);     // 處理數(shù)據(jù)

}

以上就是線程池最核心的部分。

理解這些你就能明白線程池是如何工作的了。

11、線程池中線程的數(shù)量

現(xiàn)在線程池有了，那么線程池中線程的數(shù)量該是多少呢？

在接著往下看前先自己想一想這個(gè)問題。如果你能看到這里說明還沒有睡著。

要知道線程池的線程過少就不能充分利用CPU，線程創(chuàng)建的過多反而會(huì)造成系統(tǒng)性能下降，內(nèi)存占用過多，線程切換造成的消耗等等。因此線程的數(shù)量既不能太多也不能太少，那到底該是多少呢？

回答這個(gè)問題，你需要知道線程池處理的任務(wù)有哪幾類，有的同學(xué)可能會(huì)說你不是說有兩類嗎？長任務(wù)和短任務(wù)，這個(gè)是從生命周期的角度來看的，那么從處理任務(wù)所需要的資源角度看也有兩種類型，這就是沒事兒找抽型。。。啊不，是CPU密集型和I/O密集型。

1）CPU密集型：

所謂CPU密集型就是說處理任務(wù)不需要依賴外部I/O，比如科學(xué)計(jì)算、矩陣運(yùn)算等等。在這種情況下只要線程的數(shù)量和核數(shù)基本相同就可以充分利用CPU資源。

2）I/O密集型：

這一類任務(wù)可能計(jì)算部分所占用時(shí)間不多，大部分時(shí)間都用在了比如磁盤I/O、網(wǎng)絡(luò)I/O等。

這種情況下就稍微復(fù)雜一些了，你需要利用性能測試工具評(píng)估出用在I/O等待上的時(shí)間，這里記為WT(wait time)，以及CPU計(jì)算所需要的時(shí)間，這里記為CT（computing time），那么對(duì)于一個(gè)N核的系統(tǒng)，合適的線程數(shù)大概是 N * (1 + WT/CT) ，假設(shè)I/O等待時(shí)間和計(jì)算時(shí)間相同，那么你大概需要2N個(gè)線程才能充分利用CPU資源，注意這只是一個(gè)理論值，具體設(shè)置多少需要根據(jù)真實(shí)的業(yè)務(wù)場景進(jìn)行測試。

當(dāng)然充分利用CPU不是唯一需要考慮的點(diǎn)，隨著線程數(shù)量的增多，內(nèi)存占用、系統(tǒng)調(diào)度、打開的文件數(shù)量、打開的socker數(shù)量以及打開的數(shù)據(jù)庫鏈接等等是都需要考慮的。

因此這里沒有萬能公式，要具體情況具體分析。

12、線程池不是萬能的

線程池僅僅是多線程的一種使用形式，因此多線程面臨的問題線程池同樣不能避免，像死鎖問題、race condition問題等等，關(guān)于這一部分同樣可以參考操作系統(tǒng)相關(guān)資料就能得到答案，所以基礎(chǔ)很重要呀老鐵們。

13、線程池使用的最佳實(shí)踐

線程池是程序員手中強(qiáng)大的武器，互聯(lián)網(wǎng)公司的各個(gè)server上幾乎都能見到線程池的身影。

但使用線程池前你需要考慮：

• 1）充分理解你的任務(wù)，是長任務(wù)還是短任務(wù)、是CPU密集型還是I/O密集型，如果兩種都有，那么一種可能更好的辦法是把這兩類任務(wù)放到不同的線程池中，這樣也許可以更好的確定線程數(shù)量；
• 2）如果線程池中的任務(wù)有I/O操作，那么務(wù)必對(duì)此任務(wù)設(shè)置超時(shí)，否則處理該任務(wù)的線程可能會(huì)一直阻塞下去；
• 3）線程池中的任務(wù)最好不要同步等待其它任務(wù)的結(jié)果。

14、本文小結(jié)

本文我們從CPU開始一路來到常用的線程池，從底層到上層、從硬件到軟件。

注意：這里通篇沒有出現(xiàn)任何特定的編程語言，線程不是語言層面的概念（依然不考慮用戶態(tài)線程），但是當(dāng)你真正理解了線程后，相信你可以在任何一門語言下用好多線程，你需要理解的是道，此后才是術(shù)。

希望這篇文章對(duì)大家理解線程以及線程池有所幫助。

接下的一篇將是與線程池密切配合實(shí)現(xiàn)高性能、高并發(fā)的又一關(guān)鍵技術(shù)《從根上理解高性能、高并發(fā)(二)：深入操作系統(tǒng)，理解I/O與零拷貝技術(shù)》，敬請(qǐng)期待。

附錄：更多高性能、高并發(fā)方面的文章

[1] IM方面的高性能、高并發(fā)文章：

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》

《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》

《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》

《知乎技術(shù)分享：從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實(shí)踐之路》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》

《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》

《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫OceanBase的艱辛成長之路》

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》

《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》

《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》

《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對(duì)2020年春節(jié)紅包的技術(shù)實(shí)踐》

《社交軟件紅包技術(shù)解密(十一)：解密微信紅包隨機(jī)算法(含代碼實(shí)現(xiàn))》

《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》

《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》

《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》

《從游擊隊(duì)到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》

《從游擊隊(duì)到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實(shí)踐總結(jié)》

《從游擊隊(duì)到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實(shí)踐》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場演講，有配套PPT）》

《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過人之處》

《微信后臺(tái)基于時(shí)間序的新一代海量數(shù)據(jù)存儲(chǔ)架構(gòu)的設(shè)計(jì)實(shí)踐》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》

《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場景下的技術(shù)實(shí)踐》

>> 更多同類文章 ……

[2] 其它高性能、高并發(fā)設(shè)計(jì)相關(guān)文章：

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》

《知乎技術(shù)分享：從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實(shí)踐之路》

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》

《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》

《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫OceanBase的艱辛成長之路》

《達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力》

《優(yōu)秀后端架構(gòu)師必會(huì)知識(shí)：史上最全MySQL大表優(yōu)化方案總結(jié)》

《小米技術(shù)分享：解密小米搶購系統(tǒng)千萬高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐》

《一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見方案等》

《通俗易懂：如何設(shè)計(jì)能支撐百萬并發(fā)的數(shù)據(jù)庫架構(gòu)？》

《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》

《從新手到架構(gòu)師，一篇就夠：從100到1000萬高并發(fā)的架構(gòu)演進(jìn)之路》

《美團(tuán)技術(shù)分享：深度解密美團(tuán)的分布式ID生成算法》

《12306搶票帶來的啟示：看我如何用Go實(shí)現(xiàn)百萬QPS的秒殺系統(tǒng)(含源碼)》

>> 更多同類文章 ……

（本文已同步發(fā)布于：http://www.52im.net/thread-3272-1-1.html）