SELECT和EPOLL的区别 笔记

在linux中一切皆文件，socket在内核中都属于文件系统。多路IO复用，复用的是当前进程/线程，早期的多路IO为select和poll，两者的设计思想一样，poll只是在select的处理连接请求数量上有所拓展以及数据结构可复用，但还是达不到C10M(千万级别)需求，后期设计的epoll为啥可以达到这个量级，下面就用select和epoll做个对比。

简易select实现流程：

服务器进程执行select函数时，进程阻塞，阻塞期间不占用cpu资源，将需要监听的文件描述符集合拷贝到内核并交由内核监听事件请求，网卡将接收到的客户端socket数据后写入到内存中，内核会从内存中读取socket数据，并将服务器进程添加至socket文件系统中的等待队列中，每接收一个socket就会将服务器进程添加至等待队列中，当任意socket接收缓存区有数据时先移除等待队列中的进程并添加至运行队列中，再给cpu发送中断信号告知解除阻塞，将文件描述符事件集合拷贝至用户空间，轮询操作。

用现代眼光来看待select设计缺陷：

1. 内核在每接收一个socket数据时就会将当前进程添加到等待队列，最后再一一移除，高并发中此操作会占用内核资源。
2. cpu反复上下文切换，高并发中浪费大量的cpu时间片切换间隔资源。
3. 数据反复在用户空间和内核空间进行拷贝。
4. FDS集合使用的是bitmap数组，大小固定1024个，并且内核返回集合后用户态每次都是轮询整个集合，比如极端情况下集合中只有第1023位才是有效连接，那么需要遍历0-1022位，时间复杂度为0(N)。
5. FDS集合不可复用，每次添加集合前都需要将每一位置位后重新添加。

 

epoll其实就是select的世纪版大补丁版本

简易epoll实现流程：

用户进程调用epoll_create()时内核会创建一个eventepoll文件系统

 

用户进程调用epoll_ctl()时内核设置相应的监听事件

 

当网卡将客户端数据读到内存后，此时内核会触发ep_poll_callback回调函数将socket挂载到rbr红黑树上

 

用户进程调用epoll_wait()时内核会将eventepoll添加到每个socket的等待队列中，当socket缓存区有数据时rdllist就会去引用当前socket，而此时进程被挂起在eventepoll的等待队列中，当rdllist不为空时通知cpu执行当前进程，epoll_wait()返回rdllist就绪列表

 

争对select的改进：

1. select使用的bitmap来挂载socket，数量有限，并且需要在用户空间和内核空间反复的切换来设置集合，epoll使用的是红黑二叉树，大小可伸缩，结构可以复用，操作增删改查的效率较好，并且单独在内核中触发回调函数来挂载相应事件的集合。
2. select在内核中需要将进程和socket的等待队列反复添加和移除，epoll在内核中的eventepoll相当于socket和进程之间的中介，每次只需将eventepoll添加至socket的等待队列中，进程只需添加一次到eventepoll的等待队列中，rdllist不为空时再移除此进程。
3. Select()返回时并不知道集合中哪些为有效socket，需要从内核全部拷贝到用户态并且全部遍历，epoll_wait()返回的是就绪队列，此队列中存放的是有效socket，内核拷贝到用户态的数据大大减少并且遍历时间大大缩短。