Windows系统的select函数是否与Linux的epoll作用类似？

核心结论 #

Windows 平台的 select() 和 Linux 平台的 epoll() 都属于IO 多路复用机制，核心目标都是实现单线程/进程同时监听多个套接字的 IO 事件，但两者的实现逻辑、性能上限、使用方式差异极大，不属于同阶的技术方案。

你观察到的 fd_set 行为是符合规范的 #

select() 传入的 fd_set 是输入输出复用参数：

• 调用前你需要把所有需要监听的套接字写入 fd_set 传入内核
• 内核处理完成后会直接修改原 fd_set，仅保留触发了对应事件的套接字
  你调试看到的「靠前元素被修改为符合条件的套接字」是 Windows 对 fd_set 的标准实现逻辑：Windows 的 fd_set 底层用固定长度数组存储套接字，数组前半段存储有效套接字，后半段用 INVALID_SOCKET 填充，返回时会把触发事件的套接字全部移到数组前部，其余位置清空。

select() 与 epoll() 的核心差异 #

• 性能上限不同：select() 默认最多只能监听 64 个套接字（Windows 下默认 FD_SETSIZE 为 64，即使手动修改重编译，上限也远低于 epoll）；epoll 没有固定硬上限，支持十万级并发套接字监听。
• 开销逻辑不同：select() 每次调用都需要全量传入所有要监听的套接字，内核需要遍历全部传入的套接字检查事件，性能随监听数量增长线性下降；epoll 由内核维护常驻的事件监听表，无需每次调用全量传参，内核仅遍历有事件触发的套接字，高并发场景下性能几乎没有衰减。
• 使用逻辑不同：select() 返回后需要手动遍历整个 fd_set 才能判断哪些套接字触发了事件；epoll 会直接通过返回值输出所有触发事件的套接字和对应事件类型，无需额外全量遍历。
• 特性支持不同：select() 仅支持读、写、异常三类基础事件，仅支持水平触发模式；epoll 支持边缘触发、EPOLLONESHOT 等高级特性，可适配更多高性能场景。

如果要在 Windows 下做高并发网络编程，更推荐使用 IOCP 完成端口方案，它和 Linux 的 epoll、BSD 的 kqueue 属于同阶的高性能异步 IO 实现，性能远高于 select()。

内容的提问来源于stack exchange，提问作者code-whitezyj