前段時間將新的web模型辦到Linux上來，用epoll代替了IOCP，經測試確實性能提高了很多，吞吐量也寓所提高，對于Linux下面的網絡編程不是三言兩語就能說得透的了，加上多線程就更麻煩了，但是epoll模型的精髓就是事件驅動，這種模型提供了保持連接socket直線增漲而性能不會直線下降的特性，縱觀epoll kueuen select等等，所有都是在解決一個socket不需要一個線程的問題，將事件去分開來。

在ningx(有人用他同時保持了3萬個處理連接)上的到了一些體會，這些不僅使用于web這樣模型的server，同樣適合于所有其他的比如游戲、ftp服務器等。

維持高在線人數的關鍵問題在于事件處理模型需要m：n,m遠

nginx的做法是將處理程序嚴格區分開來(本次我作的Flower web server也是基于此原理)，等待epoll等事件通知，他在全局范圍內維護了兩個鏈表，一個讀連表，一個寫鏈表，epoll等系統網絡通知通知了某個socket可操作后他便將狀態保存在相應的變量里面，然后采取m個線程輪詢執行任務，這樣線程就不用等待網絡io堵塞，正常的一個read socket數據需要循環，直到數據讀完或者產生錯誤，但我的處理不是這樣的，我在全局范圍內維護一個統一的socket fd表，這是Linux的特性決定的，因為Linux的socket fd是從很小的值開始的，并且同一時間內不會重復(估計內部有線程鎖)，所有fd本身就是一個重要的標識量，并且一個大的fd釋放后還會從小的開始重復利用，winsows下的就不一樣，他是一個長長的指針，所有我的全局狀態表就需要一個用fd作為索引的標識就可以了，最大的fd也就是同時保持在線人數的大體數字，我設置了一個20000的狀態表，暫用棧內存很小，基本上不會被用完。

然后我同樣對read和write設置兩個獨立的狀態鏈表，用m個線程來處理，所不同的是這兩個表只有一個fd項，其余的數據都是保存在堆分配的全局狀態表中，我對全局狀態表設置很多的狀態值，比如：read write readed writed needRepetRead needrepetWrite restart等等，這樣我可以將其他的處理分別用新的狀態鏈表來保持，鎖不同的是全局表的狀態不一樣，從而達到多個處理程序協作的問題，互斥鎖只存在于各個處理環節，如果讀的環節慢了就可以加大讀的線程數，寫的慢了可以加大寫的，處理的過程慢了可以加大處理的，這樣方便系統后期調試優化，但是每一個環節都不會影響全局表的處理，不會因為一個線程堵塞或則死掉導致全局的狀態都沒法進行。

初步作出來的模型同樣采用sendfile+epoll情況下，經測試我的server已經略微超過nginx，下面就是進一步的規范和優化擴展的部分了。(出自：凌曉web部落)

總結

以上是生活随笔為你收集整理的linux c 多线程socket编程,Linux多线程socket编程一些心得的全部內容，希望文章能夠幫你解決所遇到的問題。

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