?

是很經典的領導者追隨者模型，因為不想命名太長，就叫xpool。多個工作線程同時accept競爭一個可用的連接，拿到連接后就自己進行處理。accept這個地方加了鎖是為了避免低版本內核上出現驚群效應. 一般認為在短連接的時候效果比較好，但如果同一時候連接數過多會造成沒有工作線程與客戶端進行連接，客戶端會出現大量的連接失敗。

cpool: 經典的生產者消費者模型，由一個線程不斷的建立連接，通過使用select判斷是否可讀，可讀放入等待隊列，多個工作線程從等待隊列里獲取連接進行處理。在大壓力下很少出現像xpool那樣出現連接失敗的問題。cpool的一個經典問題就是在長連接的時候的性能問題，如果長連接的連接數比工作線程還少的時候，當所有的連接都被處理了，有連接需要放回pool中，而這個時候如果正常建立連接的監聽線程正好處于select狀態，這個時候必須要等到select超時才能重新將連接放入select中進行監聽，因為這之前被放入select進行監聽的處理socket為空，不會有響應，這個時候由于時間的浪費造成cpool長連接的性能下降。過去的一些做法是控制連接數和服務端的工作線程數以及通過監聽一個管道fd,在工作線程結束每次都激活這個fd跳出這次select。

現在可以簡單換成epool就可以避免這個問題 epool: 這個只在2.6內核上支持，我們可以在2.4內核上編譯到2.6內核上運行。epool的模型與cpool是一樣的，只是使用epoll代替了select。提高了性能。另外由于epoll中監聽的socket是隨時放入，隨時可以被監聽到，所以不會出現上面cpool中的問題。 select 和 epoll的區別 select 和 epoll都是用來監聽套接字上是否有事件發生，簡單來講，select是輪詢方式，而epoll是觸發方式的,用回調把信息賦給event結構體。

轉載于:https://www.cnblogs.com/myyan/p/4791143.html

總結

以上是生活随笔為你收集整理的xpool, cpool，epoo的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。