18、I/O复用综合对比：select vs poll vs epoll 性能对比、适用场景分析

说到网络编程，I/O复用是个绕不开的话题。很多新手问我：“老师，select、poll、epoll到底该用哪个？”说实话，这个问题我当年也纠结过。记得我第一次做高并发服务器时，傻乎乎地用了select，结果连接数一上千，CPU直接飙到100%。嗯，那次教训挺深刻的。

今天咱们就把这三个家伙彻底掰扯清楚。我会结合自己的踩坑经历，告诉你什么场景该选谁。

先说说它们是什么

I/O复用，说白了就是一个线程能同时监控多个文件描述符。你想想看，如果没有它，每个连接都得开一个线程，那服务器还不得炸了？

这三个工具就是干这个活的——帮你盯着成百上千个socket，哪个有数据来了，就通知你去处理。

select：老前辈，但别小看它

select是最早出现在POSIX标准里的。它的工作方式很简单：你把一堆fd丢给它，它帮你盯着，有动静了就告诉你。

但它的缺点也很明显：

• 最大连接数有限：默认1024，想改还得重新编译内核
• 每次都要全量拷贝：你把所有fd从用户态拷到内核态，内核再拷回来，开销不小
• 线性扫描：内核不知道哪个fd就绪了，得一个个查

我个人习惯在连接数不超过几百的场景下用select。比如嵌入式设备、简单的聊天室，它完全够用。我曾经在一个物联网网关项目里用过select，管理200多个传感器连接，跑了好几年没出过问题。

// select 典型用法
fd_set readfds;
struct timeval tv;
int ret;

FD_ZERO(&readfds);
FD_SET(sockfd, &readfds);
tv.tv_sec = 5;
tv.tv_usec = 0;

ret = select(sockfd + 1, &readfds, NULL, NULL, &tv);
if (ret == -1) {
    perror("select error");
} else if (ret == 0) {
    printf("超时了，没有数据\n");
} else {
    if (FD_ISSET(sockfd, &readfds)) {
        // 有数据可读
    }
}

poll：改进版，但没解决根本问题

poll的出现解决了select的两个痛点：没有最大连接数限制，而且用pollfd结构体更清晰。但它依然存在全量拷贝和线性扫描的问题。

poll用链表管理fd，理论上可以监控任意数量。但性能嘛……连接数一多，照样拉胯。

// poll 典型用法
struct pollfd fds[1024];
int ret;

fds[0].fd = sockfd;
fds[0].events = POLLIN;

ret = poll(fds, 1, 5000);  // 超时5秒
if (ret == -1) {
    perror("poll error");
} else if (ret == 0) {
    printf("超时\n");
} else {
    if (fds[0].revents & POLLIN) {
        // 有数据可读
    }
}

说实话，poll在我眼里就是个过渡产品。它比select好那么一丢丢，但跟epoll比还是差远了。我一般只在跨平台代码里用poll，因为Windows不支持epoll。

epoll：Linux下的王者

epoll是Linux特有的，也是目前高性能服务器的标配。它的设计思路完全不同：

• 事件驱动：不是全量扫描，而是哪个fd有事件就通知哪个
• mmap共享内存：用户态和内核态共享一块内存，省去了数据拷贝
• O(1)复杂度：不管监控多少个fd，效率都一样

我做过一个测试：同样是10万个连接，select直接崩了，poll卡了十几秒，epoll毫秒级返回。差距就是这么夸张。

// epoll 典型用法
int epfd = epoll_create1(0);
struct epoll_event ev, events[1024];

ev.events = EPOLLIN;
ev.data.fd = sockfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);

while (1) {
    int nfds = epoll_wait(epfd, events, 1024, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].events & EPOLLIN) {
            // 处理数据
        }
    }
}

性能对比：数据说话

下面这张表是我在实际项目中测试出来的数据，测试环境是4核8G的云服务器：

适用场景分析

说了这么多，到底该怎么选？我总结了几条经验：

• 连接数 < 500，且需要跨平台：用select。简单、稳定、够用。
• 连接数 500-5000，跨平台：用poll。比select灵活，但别指望它扛大并发。
• 连接数 > 5000，且是Linux：必须用epoll。没有第二个选择。
• 嵌入式或资源受限环境：select更轻量，epoll的epoll_create会占用额外资源。

一张图看懂三者的核心区别

下面这张SVG图展示了select、poll、epoll的工作流程差异，你可以直观地看到为什么epoll在高并发下表现更好：

避坑总结

最后，我把自己这些年踩过的坑整理一下：

• 别在select里用大数组：fd_set默认1024位，你硬塞10000个fd进去，程序直接崩。我曾经犯过这个错，排查了半小时才发现是select溢出了。
• epoll的ET模式要配合非阻塞IO：否则一个recv没读完，下次epoll_wait就不通知你了。数据就卡在那里，客户端等半天没响应。
• poll的events和revents要分清：events是你想监听的事件，revents是实际发生的事件。我见过有人把revents当events用，结果监听了个寂寞。
• epoll_wait返回后要遍历所有就绪fd：别只处理第一个就返回了，否则其他连接会饿死。

好了，关于select、poll、epoll的对比就聊到这里。这三种模型各有千秋，选对了事半功倍，选错了……嗯，你可能会像我一样熬夜排查bug。记住一句话：小项目用select，大项目上epoll，poll就当个备胎。