選用多執行緒還是IO多路複用必須要看場景的！
選擇select還是epoll也是需要看場景的！
如果是短連線，伺服器使用執行緒池(多執行緒)處理完畢，馬上進行釋放，保證活躍的執行緒所需要的記憶體和CPU效率是在伺服器承受範圍之內，那麼多執行緒比IO多路複用效果要好，因為無論是select還是epoll都需要去額外的監聽，監聽到需要資料處理，才呼叫回撥函式，分配處理執行緒去執行，這段時間有效能和資源的消耗，這種情況無疑是多執行緒模型更有優勢！
如果是長連線，因為連線長時間不釋放，服務端需要保持執行緒去維護連線，這時候所有空閒的連線都相當於一個阻塞的狀態，而且多執行緒需要的記憶體資源比較多，高併發的情況伺服器直接宕機了！而使用IO多路複用，用來維持連線的執行緒只有一個(或幾個)，不會有多餘的記憶體開銷，這時候IO多路複用的優勢得以體現！
如果確定選擇IO多路複用，又該選擇select/epoll哪種模型呢？
首先來看下select和epoll的本質區別:都有一個監聽執行緒去監聽事件，但是select採取輪詢的方式，不管有多少連線過來都要一一輪詢，有通訊資料就處理，而epoll是把所有socket對應的檔案掛在紅黑樹上，而活躍的放在一張雙向連結串列中，只處理這個連結串列中的連線！如果有新的連線需要處理，從紅黑樹上塞到連結串列中進行處理！
比如1000個連線中，只有十個有資料傳輸，select需要從1000箇中遍歷出這10個，然後進行處理，而epoll模型只需要從連結串列中取出來即可使用！
由此可見，如果是少量連線，同時大量連線都是活躍的情況下，select可能稍微略勝一籌，但如果是大量連線，且活躍數佔比少的情況，epoll堪稱完美模型，在可預見的範圍中，epoll增加連線，效能幾乎不衰減！
寫一個類似epoll的處理模型，會對以後的高併發，多執行緒處理大有助益，更多的技術分享，敬請關注。。。
選用多執行緒還是IO多路複用必須要看場景的！
選擇select還是epoll也是需要看場景的！
如果是短連線，伺服器使用執行緒池(多執行緒)處理完畢，馬上進行釋放，保證活躍的執行緒所需要的記憶體和CPU效率是在伺服器承受範圍之內，那麼多執行緒比IO多路複用效果要好，因為無論是select還是epoll都需要去額外的監聽，監聽到需要資料處理，才呼叫回撥函式，分配處理執行緒去執行，這段時間有效能和資源的消耗，這種情況無疑是多執行緒模型更有優勢！
如果是長連線，因為連線長時間不釋放，服務端需要保持執行緒去維護連線，這時候所有空閒的連線都相當於一個阻塞的狀態，而且多執行緒需要的記憶體資源比較多，高併發的情況伺服器直接宕機了！而使用IO多路複用，用來維持連線的執行緒只有一個(或幾個)，不會有多餘的記憶體開銷，這時候IO多路複用的優勢得以體現！
如果確定選擇IO多路複用，又該選擇select/epoll哪種模型呢？
首先來看下select和epoll的本質區別:都有一個監聽執行緒去監聽事件，但是select採取輪詢的方式，不管有多少連線過來都要一一輪詢，有通訊資料就處理，而epoll是把所有socket對應的檔案掛在紅黑樹上，而活躍的放在一張雙向連結串列中，只處理這個連結串列中的連線！如果有新的連線需要處理，從紅黑樹上塞到連結串列中進行處理！
比如1000個連線中，只有十個有資料傳輸，select需要從1000箇中遍歷出這10個，然後進行處理，而epoll模型只需要從連結串列中取出來即可使用！
由此可見，如果是少量連線，同時大量連線都是活躍的情況下，select可能稍微略勝一籌，但如果是大量連線，且活躍數佔比少的情況，epoll堪稱完美模型，在可預見的範圍中，epoll增加連線，效能幾乎不衰減！
寫一個類似epoll的處理模型，會對以後的高併發，多執行緒處理大有助益，更多的技術分享，敬請關注。。。