POLL：
先说poll，poll或select为大部分Unix/Linux程序员所熟悉，这俩个东西原理类似，性能上也不存在明显差异，但select对所监控的文件描述符数量有限制，所以这里选用poll做说明。
poll是一个系统调用，其内核入口函数为sys_poll，sys_poll几乎不做任何处理直接调用do_sys_poll，do_sys_poll的执行过程可以分为三个部分：
1，将用户传入的pollfd数组拷贝到内核空间，因为拷贝 *** 作和数组长度相关，时间上这是一个O（n） *** 作，这一步的代码在do_sys_poll中包括从函数开始到调用do_poll前的部分。
2，查询每个文件描述符对应设备的状态，如果该设备尚未就绪，则在该设备的等待队列中加入一项并继续查询下一设备的状态。查询完所有设备后如果没有一个设备就绪，这时则需要挂起当前进程等待，直到设备就绪或者超时，挂起 *** 作是通过调用schedule_timeout执行的。设备就绪后进程被通知继续运行，这时再次遍历所有设备，以查找就绪设备。这一步因为两次遍历所有设备，时间复杂度也是O（n），这里面不包括等待时间。相关代码在do_poll函数中。
3，将获得的数据传送到用户空间并执行释放内存和剥离等待队列等善后工作，向用户空间拷贝数据与剥离等待队列等 *** 作的的时间复杂度同样是O（n），具体代码包括do_sys_poll函数中调用do_poll后到结束的部分。
EPOLL：
接下来分析epoll，与poll/select不同，epoll不再是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样做的好处。
先来看sys_epoll_create(epoll_create对应的内核函数），这个函数主要是做一些准备工作，比如创建数据结构，初始化数据并最终返回一个文件描述符（表示新创建的虚拟epoll文件），这个 *** 作可以认为是一个固定时间的 *** 作。
epoll是做为一个虚拟文件系统来实现的，这样做至少有以下两个好处：
1，可以在内核里维护一些信息，这些信息在多次epoll_wait间是保持的，比如所有受监控的文件描述符。
2， epoll本身也可以被poll/epoll
具体epoll的虚拟文件系统的实现和性能分析无关，不再赘述。
在sys_epoll_create中还能看到一个细节，就是epoll_create的参数size在现阶段是没有意义的，只要大于零就行。
接着是sys_epoll_ctl(epoll_ctl对应的内核函数），需要明确的是每次调用sys_epoll_ctl只处理一个文件描述符，这里主要描述当op为EPOLL_CTL_ADD时的执行过程，sys_epoll_ctl做一些安全性检查后进入ep_insert，ep_insert里将 ep_poll_callback做为回掉函数加入设备的等待队列（假定这时设备尚未就绪），由于每次poll_ctl只 *** 作一个文件描述符，因此也可以认为这是一个O(1) *** 作
ep_poll_callback函数很关键，它在所等待的设备就绪后被系统回掉，执行两个 *** 作：
1，将就绪设备加入就绪队列，这一步避免了像poll那样在设备就绪后再次轮询所有设备找就绪者，降低了时间复杂度，由O（n）到O（1）
2，唤醒虚拟的epoll文件
最后是sys_epoll_wait，这里实际执行 *** 作的是ep_poll函数。该函数等待将进程自身插入虚拟epoll文件的等待队列，直到被唤醒（见上面ep_poll_callback函数描述），最后执行ep_events_transfer将结果拷贝到用户空间。由于只拷贝就绪设备信息，所以这里的拷贝是一个O(1） *** 作。
还有一个让人关心的问题就是epoll对EPOLLET的处理，即边沿触发的处理，粗略看代码就是把一部分水平触发模式下内核做的工作交给用户来处理，直觉上不会对性能有太大影响，感兴趣的朋友欢迎讨论。
POLL/EPOLL对比：
表面上poll的过程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系统调用构成，实际上epoll将poll分成若干部分实现的原因正是因为服务器软件中使用poll的特点（比如Web服务器）：
1，需要同时poll大量文件描述符
2，每次poll完成后就绪的文件描述符只占所有被poll的描述符的很少一部分。
3，前后多次poll调用对文件描述符数组（ufds）的修改只是很小
理解Linux的IO模型之前，首先要了解一些基本概念，才能理解这些IO模型设计的依据
*** 作系统使用虚拟内存来映射物理内存，对于32位的 *** 作系统来说，虚拟地址空间为4G（2^32）。 *** 作系统的核心是内核，为了保护用户进程不能直接 *** 作内核，保证内核安全， *** 作系统将虚拟地址空间划分为内核空间和用户空间。内核可以访问全部的地址空间，拥有访问底层硬件设备的权限，普通的应用程序需要访问硬件设备必须通过 系统调用 来实现。
对于Linux系统来说，将虚拟内存的最高1G字节的空间作为内核空间仅供内核使用，低3G字节的空间供用户进程使用，称为用户空间。
又被称为标准I/O，大多数文件系统的默认I/O都是缓存I/O。在Linux系统的缓存I/O机制中， *** 作系统会将I/O的数据缓存在页缓存（内存）中，也就是数据先被拷贝到内核的缓冲区（内核地址空间），然后才会从内核缓冲区拷贝到应用程序的缓冲区（用户地址空间）。
这种方式很明显的缺点就是数据传输过程中需要再应用程序地址空间和内核空间进行多次数据拷贝 *** 作，这些 *** 作带来的CPU以及内存的开销是非常大的。
由于Linux系统采用的缓存I/O模式，对于一次I/O访问，以读 *** 作举例，数据先会被拷贝到内核缓冲区，然后才会从内核缓冲区拷贝到应用程序的缓存区，当一个read系统调用发生的时候，会经历两个阶段：
正是因为这两个状态，Linux系统才产生了多种不同的网络I/O模式的方案
Linux系统默认情况下所有socke都是blocking的，一个读 *** 作流程如下：
以UDP socket为例，当用户进程调用了recvfrom系统调用，如果数据还没准备好，应用进程被阻塞，内核直到数据到来且将数据从内核缓冲区拷贝到了应用进程缓冲区，然后向用户进程返回结果，用户进程才解除block状态，重新运行起来。
阻塞模行下只是阻塞了当前的应用进程，其他进程还可以执行，不消耗CPU时间，CPU的利用率较高。
Linux可以设置socket为非阻塞的，非阻塞模式下执行一个读 *** 作流程如下：
当用户进程发出recvfrom系统调用时，如果kernel中的数据还没准备好，recvfrom会立即返回一个error结果，不会阻塞用户进程，用户进程收到error时知道数据还没准备好，过一会再调用recvfrom，直到kernel中的数据准备好了，内核就立即将数据拷贝到用户内存然后返回ok，这个过程需要用户进程去轮询内核数据是否准备好。
非阻塞模型下由于要处理更多的系统调用，因此CPU利用率比较低。
应用进程使用sigaction系统调用，内核立即返回，等到kernel数据准备好时会给用户进程发送一个信号，告诉用户进程可以进行IO *** 作了，然后用户进程再调用IO系统调用如recvfrom，将数据从内核缓冲区拷贝到应用进程。流程如下：
相比于轮询的方式，不需要多次系统调用轮询，信号驱动IO的CPU利用率更高。
异步IO模型与其他模型最大的区别是，异步IO在系统调用返回的时候所有 *** 作都已经完成，应用进程既不需要等待数据准备，也不需要在数据到来后等待数据从内核缓冲区拷贝到用户缓冲区，流程如下：
在数据拷贝完成后，kernel会给用户进程发送一个信号告诉其read *** 作完成了。
是用select、poll等待数据，可以等待多个socket中的任一个变为可读，这一过程会被阻塞，当某个套接字数据到来时返回，之后再用recvfrom系统调用把数据从内核缓存区复制到用户进程，流程如下：
流程类似阻塞IO，甚至比阻塞IO更差，多使用了一个系统调用，但是IO多路复用最大的特点是让单个进程能同时处理多个IO事件的能力，又被称为事件驱动IO，相比于多线程模型，IO复用模型不需要线程的创建、切换、销毁，系统开销更小，适合高并发的场景。
select是IO多路复用模型的一种实现，当select函数返回后可以通过轮询fdset来找到就绪的socket。
优点是几乎所有平台都支持，缺点在于能够监听的fd数量有限，Linux系统上一般为1024，是写死在宏定义中的，要修改需要重新编译内核。而且每次都要把所有的fd在用户空间和内核空间拷贝，这个 *** 作是比较耗时的。
poll和select基本相同，不同的是poll没有最大fd数量限制（实际也会受到物理资源的限制，因为系统的fd数量是有限的），而且提供了更多的时间类型。
总结：select和poll都需要在返回后通过轮询的方式检查就绪的socket，事实上同时连的大量socket在一个时刻只有很少的处于就绪状态，因此随着监视的描述符数量的变多，其性能也会逐渐下降。
epoll是select和poll的改进版本，更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
epoll_create()用来创建一个epoll句柄。
epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个就绪链表中管理。
epoll_wait() 可以从就绪链表中得到事件完成的描述符，因此进程不需要通过轮询来获得事件完成的描述符。
当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序可以不立即处理该事件，下次调用epoll_wait还会再次通知该事件，支持block和nonblocking socket。
当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序需要立即处理该事件，如果不立即处理，下次调用epoll_wait不会再次通知该事件。
ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用nonblocking socket，以避免由于一个文件句柄的阻塞读/阻塞写 *** 作把处理多个文件描述符的任务饿死。
【segmentfault】 Linux IO模式及 select、poll、epoll详解
【GitHub】 CyC2018/CS-Notes
select这个系统调用的原型如下
第一个参数nfds用来告诉内核 要扫描的socket fd的数量+1 ，select系统调用最大接收的数量是1024，但是如果每次都去扫描1024，实际上的数量并不多，则效率太低，这里可以指定需要扫描的数量。 最大数量为1024，如果需要修改这个数量，则需要重新编译Linux内核源码。
第2、3、4个参数分别是readfds、writefds、exceptfds，传递的参数应该是fd_set 类型的引用，内核会检测每个socket的fd， 如果没有读事件，就将对应的fd从第二个参数传入的fd_set中移除，如果没有写事件，就将对应的fd从第二个参数的fd_set中移除，如果没有异常事件，就将对应的fd从第三个参数的fd_set中移除 。这里我们应该 要将实际的readfds、writefds、exceptfds拷贝一份副本传进去，而不是传入原引用，因为如果传递的是原引用，某些socket可能就已经丢失 。
最后一个参数是等待时间， 传入0表示非阻塞，传入>0表示等待一定时间，传入NULL表示阻塞，直到等到某个socket就绪 。
FD_ZERO()这个函数将fd_set中的所有bit清0，一般用来进行初始化等。
FD_CLR()这个函数用来将bitmap(fd_set )中的某个bit清0，在客户端异常退出时就会用到这个函数，将fd从fd_set中删除。
FD_ISSET()用来判断某个bit是否被置1了，也就是判断某个fd是否在fd_set中。
FD_SET()这个函数用来将某个fd加入fd_set中，当客户端新加入连接时就会使用到这个函数。
epoll_create系统调用用来创建epfd，会在开辟一块内存空间(epoll的结构空间)。size为epoll上能关注的最大描述符数，不够会进行扩展，size只要＞0就行，早期的设计size是固定大小，但是现在size参数没什么用，会自动扩展。
返回值是epfd，如果为-1则说明创建epoll对象失败 。
第一个参数epfd传入的就是epoll_create返回的epfd。
第二个参数传入对应 *** 作的宏，包括 增删改(EPOLL_CTL_ADD、EPOLL_CTL_DEL、EPOLL_CTL_MOD) 。
第三个参数传入的是 需要增删改的socket的fd 。
第四个参数传入的是 需要 *** 作的fd的哪些事件 ，具体的事件可以看后续。
返回值是一个int类型，如果为-1则说明 *** 作失败 。
第一个参数是epfd，也就是epoll_create的返回值。
第二个参数是一个epoll_event类型的指针，也就是传入的是一个数组指针。 内核会将就绪的socket的事件拷贝到这个数组中，用户可以根据这个数组拿到事件和消息等 。
第三个参数是maxevents，传入的是 第二个参数的数组的容量 。
第四个参数是timeout， 如果设为-1一直阻塞直到有就绪数据为止，如果设为0立即返回，如果＞0那么阻塞一段时间 。
返回值是一个int类型，也就是就绪的socket的事件的数量(内核拷贝给用户的events的元素的数量)，通过这个数量可以进行遍历处理每个事件 。
一般需要传入 ev.data.fd 和 ev.events ，也就是fd和需要监控的fd的事件。事件如果需要传入多个，可以通过按位与来连接，比如需要监控读写事件，只需要像如下这样 *** 作即可： ev.events=EPOLLIN | EPOLLOUT 。
LT(水平触发)， 默认 的工作模式， 事件就绪后用户可以选择处理和不处理，如果用户不处理，内核会对这部分数据进行维护，那么下次调用epoll_wait()时仍旧会打包出来 。
ET(边缘触发)，事件就绪之后， 用户必须进行处理 ，因为内核把事件打包出来之后就把对应的就绪事件给清掉了， 如果不处理那么就绪事件就没了 。ET可以减少epoll事件被重复触发的次数，效率比LT高。
如果需要设置为边缘触发只需要设置事件为类似 ev.events=EPOLLIN | EPOLLET 即可 。
select/poll/epoll是nio多路复用技术， 传统的bio无法实现C10K/C100K ，也就是无法满足1w/10w的并发量，在这么高的并发量下，在进行上下文切换就很容易将服务器的负载拉飞。
1.将fd_set从用户态拷贝到内核态
2.根据fd_set扫描内存中的socket的fd的状态，时间复杂度为O(n)
3.检查fd_set，如果有已经就绪的socket，就给对应的socket的fd打标记，那么就return 就绪socket的数量并唤醒当前线程，如果没有就绪的socket就继续阻塞当前线程直到有socket就绪才将当前线程唤醒。
4.如果想要获取当前已经就绪的socket列表，则还需要进行一次系统调用，使用O(n)的时间去扫描socket的fd列表，将已经打上标记的socket的fd返回。
CPU在同一个时刻只能执行一个程序，通过RR时间片轮转去切换执行各个程序。没有被挂起的进程(线程)则在工作队列中排队等待CPU的执行，将进程(线程)从工作队列中移除就是挂起，反映到Java层面的就是线程的阻塞。
什么是中断？当我们使用键盘、鼠标等IO设备的时候，会给主板一个电流信号，这个电流信号就给CPU一个中断信号，CPU执行完当前的指令便会保存现场，然后执行键盘/鼠标等设备的中断程序，让中断程序获取CPU的使用权，在中断程序后又将现场恢复，继续执行之前的进程。
如果第一次没检测到就绪的socket，就要将其进程(线程)从工作队列中移除，并加入到socket的等待队列中。
socket包含读缓冲区+写缓冲区+等待队列(放线程或eventpoll对象)
当从客户端往服务器端发送数据时，使用TCP/IP协议将通过物理链路、网线发给服务器的网卡设备，网卡的DMA设备将接收到的的数据写入到内存中的一块区域(网卡缓冲区)，然后会给CPU发出一个中断信号，CPU执行完当前指令则会保存现场，然后网卡的中断程序就获得了CPU的使用权，然后CPU便开始执行网卡的中断程序，将内存中的缓存区中的数据包拿出，判断端口号便可以判断它是哪个socket的数据，将数据包写入对应的socket的读(输入)缓冲区，去检查对应的socket的等待队列有没有等待着的进程(线程)，如果有就将该线程(进程)从socket的等待队列中移除，将其加入工作队列，这时候该进程(线程)就再次拥有了CPU的使用权限，到这里中断程序就结束了。
之后这个进程(线程)就执行select函数再次去检查fd_set就能发现有socket缓冲区中有数据了，就将该socket的fd打标记，这个时候select函数就执行完了，这时候就会给上层返回一个int类型的数值，表示已经就绪的socket的数量或者是发生了错误。这个时候就再进行内核态到用户态的切换，对已经打标记的socket的fd进行处理。
将原本1024bit长度的bitmap(fd_set)换成了数组的方式传入 ，可以 解决原本1024个不够用的情况 ，因为传入的是数组，长度可以不止是1024了，因此socket数量可以更多，在Kernel底层会将数组转换成链表。
在十多年前，linux2.6之前，不支持epoll，当时可能会选择用Windows/Unix用作服务器，而不会去选择Linux，因为select/poll会随着并发量的上升，性能变得越来越低，每次都得检查所有的Socket列表。
1.select/poll每次调用都必须根据提供所有的socket集合，然后就 会涉及到将这个集合从用户空间拷贝到内核空间，在这个过程中很耗费性能 。但是 其实每次的socket集合的变化也许并不大，也许就1-2个socket ，但是它会全部进行拷贝，全部进行遍历一一判断是否就绪。
2.select/poll的返回类型是int，只能代表当前的就绪的socket的数量/发生了错误， 如果还需要知道是哪些socket就绪了，则还需要再次使用系统调用去检查哪些socket是就绪的，又是一次O(n)的 *** 作，很耗费性能 。
1.epoll在Kernel内核中存储了对应的数据结构(eventpoll)。我们可以 使用epoll_create()这个系统调用去创建一个eventpoll对象 ，并返回eventpoll的对象id(epfd)，eventpoll对象主要包括三个部分：需要处理的正在监听的socket_fd列表(红黑树结构)、socket就绪列表以及等待队列(线程)。
2.我们可以使用epoll_ctl()这个系统调用对socket_fd列表进行CRUD *** 作，因为可能频繁地进行CRUD，因此 socket_fd使用的是红黑树的结构 ，让其效率能更高。epoll_ctl()传递的参数主要是epfd(eventpoll对象id)。
3.epoll_wait()这个系统调用默认会 将当前进程(线程)阻塞，加入到eventpoll对象的等待队列中，直到socket就绪列表中有socket，才会将该进程(线程)重新加入工作队列 ，并返回就绪队列中的socket的数量。
socket包含读缓冲区、写缓冲区和等待队列。当使用epoll_ctl()系统调用将socket新加入socket_fd列表时，就会将eventpoll对象引用加到socket的等待队列中， 当网卡的中断程序发现socket的等待队列中不是一个进程(线程)，而是一个eventpoll对象的引用，就将socket引用追加到eventpoll对象的就绪列表的尾部 。而eventpoll对象中的等待队列存放的就是调用了epoll_wait()的进程(线程)，网卡的中断程序执行会将等待队列中的进程(线程)重新加入工作队列，让其拥有占用CPU执行的资格。epoll_wait()的返回值是int类型，返回的是就绪的socket的数量/发生错误，-1表示发生错误。
epoll的参数有传入一个epoll_event的数组指针(作为输出参数)，在调用epoll_wait()返回的同时，Kernel内核还会将就绪的socket列表添加到epoll_event类型的数组当中。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）