epoll和select，poll的区别

select、poll 和 epoll 都是 Linux 下的 I/O 多路复用技术，它们的核心作用都是让一个线程能够同时监控多个文件描述符（fd/socket），从而实现高并发的网络服务。

你可以把它们想象成老师检查学生作业：

• select/poll：老师挨个问全班 100 个学生“作业写完没？”，不管学生写没写完，必须从头问到尾（轮询机制）。
• epoll：写完作业的学生主动举手，老师只需要关注举手的学生即可（事件驱动/回调机制）。

为了让你更直观地理解，我们可以通过以下核心维度进行对比：

🔍 深入解析三者的区别

1. select：元老级选手，有硬伤

select 是最早出现的 I/O 多路复用方案。它使用 fd_set 位图来存储文件描述符。

• 致命缺陷：它默认只能监控 1024 个 fd（由 FD_SETSIZE 宏定义限制），想突破这个限制非常麻烦。
• 性能瓶颈：每次调用 select，都需要把整个 fd 集合从用户态拷贝到内核态。内核返回后，还需要再次遍历整个集合来找出哪些 fd 就绪了。当连接数很多但活跃数很少时，CPU 绝大部分时间都浪费在无效遍历上。
• 适用场景：需要跨平台（如同时兼容 Windows/Mac），且并发连接数很少（几百个）的简单应用。

2. poll：select 的改良版，但治标不治本

poll 的出现主要是为了解决 select 的 1024 连接数限制。它不再使用位图，而是使用 pollfd 结构体数组来存储 fd。

• 改进点：没有了 1024 的硬性限制，可以监控的连接数取决于系统内存。
• 遗留问题：虽然突破了数量限制，但它依然没有解决性能问题。每次调用 poll，内核依然需要线性扫描整个数组来检查就绪状态，时间复杂度依然是 O(n)。
• 适用场景：连接数超过 1024，但并发量依然不算特别巨大的中小型服务器。

3. epoll：高并发的终极武器

epoll 是 Linux 2.6 内核引入的终极方案，它彻底改变了前两者的工作模式。

• 核心优势：
  • 零拷贝与持久化：通过 epoll_ctl 将 fd 注册到内核的红黑树中后，后续调用 epoll_wait 不需要重复传递和拷贝 fd 集合。
  • 事件驱动：内核通过回调机制，只把真正“就绪”的 fd 放入就绪队列。epoll_wait 返回时，直接拿走这些就绪的 fd 即可，时间复杂度为 O(1)，与总连接数无关。
• 适用场景：海量并发连接（如 C10K、C100K 问题），且大部分连接处于空闲状态的场景。现代的 Nginx、Redis、Go 语言的网络库底层都 heavily 依赖 epoll。

💡 总结建议

• 如果你在做跨平台开发或者连接数极少，用 select。
• 如果你在 Linux 下开发，且对性能有一定要求，epoll 是绝对的首选。在现代高性能服务器开发中，epoll 已经完全取代了 select 和 poll。