如何理解服務(wù)器單I/O線程＋工作者線程池模型架構(gòu)及實現(xiàn)要點

如何理解服務(wù)器單I/O線程＋工作者線程池模型架構(gòu)及實現(xiàn)要點，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

我們知道，服務(wù)器并發(fā)模型通常可分為單線程和多線程模型，這里的線程通常是指“I/O線程”，即負責(zé)I/O操作，協(xié)調(diào)分配任務(wù)的“管理線程”，而實際的請求和任務(wù)通常交由所謂“工作者線程”處理。通常多線程模型下，每個線程既是I/O線程又是工作者線程。所以這里討論的是，單I/O線程+多工作者線程的模型，這也是最常用的一種服務(wù)器并發(fā)模型。我所在的項目中的server代碼中，這種模型隨處可見。它還有個名字，叫“半同步/半異步“模型，同時，這種模型也是生產(chǎn)者/消費者（尤其是多消費者）模型的一種表現(xiàn)。

這種架構(gòu)主要是基于I/O多路復(fù)用的思想（主要是epoll，select/poll已過時），通過單線程I/O多路復(fù)用，可以達到高效并發(fā)，同時避免了多線程I/O來回切換的各種開銷，思路清晰，易于管理，而基于線程池的多工作者線程，又可以充分發(fā)揮和利用多線程的優(yōu)勢，利用線程池，進一步提高資源復(fù)用性和避免產(chǎn)生過多線程。

1.模型架構(gòu)

2 實現(xiàn)要點

2.1 單I/O 線程epoll

實現(xiàn)單I/O線程的epoll模型是本架構(gòu)的第一個技術(shù)要點，主要思想如下：

單線程創(chuàng)建epoll并等待，有I/O請求（socket）到達時，將其加入epoll并從線程池中取一個空閑工作者線程，將實際的任務(wù)交由工作者線程處理。

偽碼：

偽碼可能寫的不太好，其實就是基本的epoll使用。

但要注意和線程池的配合使用，如果線程池取不到空閑的工作者線程，還需要做一些處理。

2.2 線程池實現(xiàn)要點

server啟動時，創(chuàng)建一定數(shù)量的工作者線程加入線程池，如（20個），供I/O線程來取用；

每當(dāng)I/O線程請求空閑工作者線程時，從池中取出一個空閑工作者線程，處理相應(yīng)請求；

當(dāng)請求處理完畢，關(guān)閉相應(yīng)I/O連接時，回收相應(yīng)線程并放回線程池中供下次使用；

若請求空閑工作者線程池時，沒有空閑工作者線程，可作如下處理：

(1)若池中”管理”的線程總數(shù)不超過最大允許值，可創(chuàng)建一批新的工作者線程加入池中，并返回其中一個供I/O線程使用；

(2)若池中”管理”的線程總數(shù)已經(jīng)達到最大值，不應(yīng)再繼續(xù)創(chuàng)建新線程， 則等待一小段時間并重試。注意因為I/O線程是單線程且不應(yīng)被阻塞等待在此處，所以其實對線程池的管理應(yīng)由一個專門的管理線程完成，包括創(chuàng)建新工作者線程等工作。此時管理線程阻塞等待（如使用條件變量并等待喚醒），一小段時間之后，線程池中應(yīng)有空閑工作者線程可使用。否則server負荷估計是出了問題。

看完上述內(nèi)容，你們掌握如何理解服務(wù)器單I/O線程＋工作者線程池模型架構(gòu)及實現(xiàn)要點的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！