假設你經營一家餐廳，服務員需要同時照顧100桌客人。如果每桌客人點菜都要服務員一直守候，餐廳早就倒閉了。而高并發服務器的設計同樣面臨類似問題——如何用最少的資源（線程）處理最多的請求（連接）？IO多路復用技術（select/poll/epoll） 就是解決這一難題的核心方案。

1.傳統阻塞模型的致命缺陷：資源浪費

想象一下，每個客戶進餐廳都必須配一個專屬服務員（線程）。當同時涌入1000名顧客時，餐廳需要雇傭1000名服務員，不僅人力成本爆炸，服務員之間還可能因協調混亂而撞車。這就是傳統阻塞IO模型的問題。

• 線程爆炸：每個連接獨占線程，1萬連接需1萬線程；
• 資源浪費：線程切換消耗CPU，內存占用飆升；
• 性能瓶頸：線程數超過CPU核數后，響應速度斷崖式下跌。

2.IO多路復用的核心思想：一個服務員看全場

IO多路復用就像給餐廳裝上智能呼叫鈴系統，服務員只需關注“亮燈”的桌子。其本質是讓單線程監控多個連接的就緒狀態，僅處理有數據到達的請求。實現這一目標的關鍵在于三種技術。

3.技術演進：從輪詢到事件驅動

select模型：全員點名式管理

工作原理

服務員手持一張座位表（fd_set），每次輪詢所有桌子（fd），挨個問“有菜要上嗎？”。

數據結構

• fd_set是1024位的位圖，每位代表一個文件描述符（如fd=3對應第3位）；
• 通過宏操作設置狀態：FD_SET(fd, &set)將對應位置1，FD_CLR置0。

代碼示例

fd_set read_fds;
FD_ZERO(&read_fds);    // 清空座位表
FD_SET(sockfd, &read_fds); 
select(max_fd+1, &read_fds, NULL, NULL, NULL); // 開始輪詢

致命缺陷

• 座位表最多1024桌（可調整但性能下降）；
• 每次輪詢需全表拷貝到內核（內存開銷大）；
• 時間復雜度O(n)，萬級連接下CPU占用率飆升。

poll模型：升級版輪詢

改進點

• 用動態數組（pollfd結構體）替代固定位圖，突破1024限制；
• 支持同時監聽讀、寫、異常事件。

代碼示例

struct pollfd fds[1000];
fds[0].fd = sockfd; 
fds[0].events = POLLIN; // 監聽讀事件
poll(fds, 1000, 500);  // 等待500ms

未解決問題

• 仍需全量遍歷所有fd（性能未質變）；
• 數據拷貝開銷依然存在。

epoll模型：事件驅動的終極形態

設計哲學給每桌裝上智能呼叫鈴（回調機制），服務員只需關注鈴響的桌子。

核心組件

• 紅黑樹：存儲所有監聽fd，插入/刪除時間復雜度O(log n)；
• 就緒隊列：僅存放已觸發事件的fd（直接處理無需遍歷）；
• 回調函數：數據到達時自動觸發，將fd加入就緒隊列。

觸發模式

• LT模式（默認）：鈴響后不關鈴，直到菜品取走（數據讀完）；
• ET模式：僅鈴響一次，需一次取完所有菜品（適合高性能場景）。

代碼流程

int epfd = epoll_create1(0); // 創建epoll實例
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET; // 邊緣觸發模式
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev); // 注冊到紅黑樹
while(1) {
  struct epoll_event events[100];
  int n = epoll_wait(epfd, events, 100, -1); // 等待事件
  for(int i=0; i<n; i++) {
    handle_event(events[i].data.fd); // 處理就緒fd
  }
}

性能優勢：

• 時間復雜度O(1)，百萬連接下仍能快速響應；
• 零拷貝技術：通過mmap共享內存，避免數據來回拷貝。

4.橫向對比：性能指數級躍遷

5.為何Redis、Nginx都選epoll？

Redis單線程扛10萬QPS

• 基于epoll的事件循環，單線程處理所有客戶端請求；
• 內存操作+IO多路復用，避免線程切換開銷。

Nginx反向代理百萬連接

• 每個worker進程獨立epoll實例，均衡負載；
• ET模式確保高吞吐，避免LT模式下的重復通知。

在線游戲服務器

• 使用ET模式處理玩家指令，確保毫秒級響應；
• 就緒隊列直接傳遞活躍玩家ID，避免遍歷全用戶列表。
• 
  

6.小結

• 傳統場景：連接數<1000，select/poll足矣（跨平臺兼容）；
• 高并發場景：Linux首選epoll，FreeBSD用kqueue，Windows用IOCP；
• 邊緣觸發陷阱：ET模式必須一次性讀完數據，否則會丟失事件。

未來趨勢：異步IO（如io_uring）正在崛起，但epoll在Linux中的地位十年內仍難撼動。理解多路復用，不僅是面試考點，更是構建高性能服務的基石。