⑴ 面试必问的epoll技术，从内核源码出发彻底搞懂epoll
epoll是linux中IO多路复用的一种机制，I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。当然linux中IO多路复用不仅仅是epoll，其他多路复用机制还有select、poll，但是接下来介绍epoll的内核实现。
events可以是以下几个宏的集合：
epoll相比select/poll的优势 ：
epoll相关的内核代码在fs/eventpoll.c文件中，下面分别分析epoll_create、epoll_ctl和epoll_wait三个函数在内核中的实现，分析所用linux内核源码为4.1.2版本。
epoll_create用于创建一个epoll的句柄，其在内核的系统实现如下：
sys_epoll_create:
可见，我们在调用epoll_create时，传入的size参数，仅仅是用来判断是否小于等于0，之后再也没有其他用处。
整个函数就3行代码，真正的工作还是放在sys_epoll_create1函数中。
sys_epoll_create -> sys_epoll_create1:
sys_epoll_create1 函数流程如下：
sys_epoll_create -> sys_epoll_create1 -> ep_alloc:
sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags:
linux内核中，current是个宏，返回的是一个task_struct结构（我们称之为进程描述符）的变量，表示的是当前进程，进程打开的文件资源保存在进程描述符的files成员里面，所以current->files返回的当前进程打开的文件资源。rlimit(RLIMIT_NOFILE) 函数获取的是当前进程可以打开的最大文件描述符数，这个值可以设置，默认是1024。
相关视频推荐：
支撑亿级io的底层基石 epoll实战揭秘
网络原理tcp/udp，网络编程epoll/reactor，面试中正经“八股文”
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要更多C/C++ Linux服务器架构师学习资料加群 812855908 获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享
__alloc_fd的工作是为进程在[start,end)之间(备注：这里start为0， end为进程可以打开的最大文件描述符数)分配一个可用的文件描述符,这里就不继续深入下去了，代码如下：
sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags -> __alloc_fd:
然后，epoll_create1会调用anon_inode_getfile，创建一个file结构，如下：
sys_epoll_create -> sys_epoll_create1 -> anon_inode_getfile:
anon_inode_getfile函数中首先会alloc一个file结构和一个dentry结构，然后将该file结构与一个匿名inode节点anon_inode_inode挂钩在一起，这里要注意的是，在调用anon_inode_getfile函数申请file结构时，传入了前面申请的eventpoll结构的ep变量，申请的file->private_data会指向这个ep变量，同时，在anon_inode_getfile函数返回来后，ep->file会指向该函数申请的file结构变量。
简要说一下file/dentry/inode，当进程打开一个文件时，内核就会为该进程分配一个file结构，表示打开的文件在进程的上下文，然后应用程序会通过一个int类型的文件描述符来访问这个结构，实际上内核的进程里面维护一个file结构的数组，而文件描述符就是相应的file结构在数组中的下标。
dentry结构（称之为“目录项”）记录着文件的各种属性，比如文件名、访问权限等，每个文件都只有一个dentry结构，然后一个进程可以多次打开一个文件，多个进程也可以打开同一个文件，这些情况，内核都会申请多个file结构，建立多个文件上下文。但是，对同一个文件来说，无论打开多少次，内核只会为该文件分配一个dentry。所以，file结构与dentry结构的关系是多对一的。
同时，每个文件除了有一个dentry目录项结构外，还有一个索引节点inode结构，里面记录文件在存储介质上的位置和分布等信息，每个文件在内核中只分配一个inode。 dentry与inode描述的目标是不同的，一个文件可能会有好几个文件名（比如链接文件），通过不同文件名访问同一个文件的权限也可能不同。dentry文件所代表的是逻辑意义上的文件，记录的是其逻辑上的属性，而inode结构所代表的是其物理意义上的文件，记录的是其物理上的属性。dentry与inode结构的关系是多对一的关系。
sys_epoll_create -> sys_epoll_create1 -> fd_install:
总结epoll_create函数所做的事：调用epoll_create后，在内核中分配一个eventpoll结构和代表epoll文件的file结构，并且将这两个结构关联在一块，同时，返回一个也与file结构相关联的epoll文件描述符fd。当应用程序操作epoll时，需要传入一个epoll文件描述符fd，内核根据这个fd，找到epoll的file结构，然后通过file，获取之前epoll_create申请eventpoll结构变量，epoll相关的重要信息都存储在这个结构里面。接下来，所有epoll接口函数的操作，都是在eventpoll结构变量上进行的。
所以，epoll_create的作用就是为进程在内核中建立一个从epoll文件描述符到eventpoll结构变量的通道。
epoll_ctl接口的作用是添加/修改/删除文件的监听事件，内核代码如下：
sys_epoll_ctl:
根据前面对epoll_ctl接口的介绍，op是对epoll操作的动作（添加/修改/删除事件），ep_op_has_event(op)判断是否不是删除操作，如果op != EPOLL_CTL_DEL为true，则需要调用_from_user函数将用户空间传过来的event事件拷贝到内核的epds变量中。因为，只有删除操作，内核不需要使用进程传入的event事件。
接着连续调用两次fdget分别获取epoll文件和被监听文件（以下称为目标文件）的file结构变量（备注：该函数返回fd结构变量，fd结构包含file结构）。
接下来就是对参数的一些检查，出现如下情况，就可以认为传入的参数有问题，直接返回出错：
当然下面还有一些关于操作动作如果是添加操作的判断，这里不做解释，比较简单，自行阅读。
在ep里面，维护着一个红黑树，每次添加注册事件时，都会申请一个epitem结构的变量表示事件的监听项，然后插入ep的红黑树里面。在epoll_ctl里面，会调用ep_find函数从ep的红黑树里面查找目标文件表示的监听项，返回的监听项可能为空。
接下来switch这块区域的代码就是整个epoll_ctl函数的核心，对op进行switch出来的有添加(EPOLL_CTL_ADD)、删除(EPOLL_CTL_DEL)和修改(EPOLL_CTL_MOD)三种情况，这里我以添加为例讲解，其他两种情况类似，知道了如何添加监听事件，其他删除和修改监听事件都可以举一反三。
为目标文件添加监控事件时，首先要保证当前ep里面还没有对该目标文件进行监听，如果存在(epi不为空)，就返回-EEXIST错误。否则说明参数正常，然后先默认设置对目标文件的POLLERR和POLLHUP监听事件，然后调用ep_insert函数，将对目标文件的监听事件插入到ep维护的红黑树里面：
sys_epoll_ctl -> ep_insert:
前面说过，对目标文件的监听是由一个epitem结构的监听项变量维护的，所以在ep_insert函数里面，首先调用kmem_cache_alloc函数，从slab分配器里面分配一个epitem结构监听项，然后对该结构进行初始化，这里也没有什么好说的。我们接下来看ep_item_poll这个函数调用：
sys_epoll_ctl -> ep_insert -> ep_item_poll:
ep_item_poll函数里面，调用目标文件的poll函数，这个函数针对不同的目标文件而指向不同的函数，如果目标文件为套接字的话，这个poll就指向sock_poll，而如果目标文件为tcp套接字来说，这个poll就是tcp_poll函数。虽然poll指向的函数可能会不同，但是其作用都是一样的，就是获取目标文件当前产生的事件位，并且将监听项绑定到目标文件的poll钩子里面（最重要的是注册ep_ptable_queue_proc这个poll callback回调函数），这步操作完成后，以后目标文件产生事件就会调用ep_ptable_queue_proc回调函数。
接下来，调用list_add_tail_rcu将当前监听项添加到目标文件的f_ep_links链表里面，该链表是目标文件的epoll钩子链表，所有对该目标文件进行监听的监听项都会加入到该链表里面。
然后就是调用ep_rbtree_insert，将epi监听项添加到ep维护的红黑树里面,这里不做解释，代码如下：
sys_epoll_ctl -> ep_insert -> ep_rbtree_insert:
前面提到，ep_insert有调用ep_item_poll去获取目标文件产生的事件位，在调用epoll_ctl前这段时间，可能会产生相关进程需要监听的事件，如果有监听的事件产生，(revents & event->events 为 true)，并且目标文件相关的监听项没有链接到ep的准备链表rdlist里面的话，就将该监听项添加到ep的rdlist准备链表里面，rdlist链接的是该epoll描述符监听的所有已经就绪的目标文件的监听项。并且，如果有任务在等待产生事件时，就调用wake_up_locked函数唤醒所有正在等待的任务，处理相应的事件。当进程调用epoll_wait时，该进程就出现在ep的wq等待队列里面。接下来讲解epoll_wait函数。
总结epoll_ctl函数：该函数根据监听的事件，为目标文件申请一个监听项，并将该监听项挂人到eventpoll结构的红黑树里面。
epoll_wait等待事件的产生，内核代码如下：
sys_epoll_wait:
首先是对进程传进来的一些参数的检查：
参数全部检查合格后，接下来就调用ep_poll函数进行真正的处理：
sys_epoll_wait -> ep_poll:
ep_poll中首先是对等待时间的处理，timeout超时时间以ms为单位，timeout大于0，说明等待timeout时间后超时，如果timeout等于0，函数不阻塞，直接返回，小于0的情况，是永久阻塞，直到有事件产生才返回。
当没有事件产生时（(!ep_events_available(ep))为true）,调用__add_wait_queue_exclusive函数将当前进程加入到ep->wq等待队列里面，然后在一个无限for循环里面，首先调用set_current_state(TASK_INTERRUPTIBLE)，将当前进程设置为可中断的睡眠状态，然后当前进程就让出cpu，进入睡眠，直到有其他进程调用wake_up或者有中断信号进来唤醒本进程，它才会去执行接下来的代码。
如果进程被唤醒后，首先检查是否有事件产生，或者是否出现超时还是被其他信号唤醒的。如果出现这些情况，就跳出循环，将当前进程从ep->wp的等待队列里面移除，并且将当前进程设置为TASK_RUNNING就绪状态。
如果真的有事件产生，就调用ep_send_events函数，将events事件转移到用户空间里面。
sys_epoll_wait -> ep_poll -> ep_send_events:
ep_send_events没有什么工作，真正的工作是在ep_scan_ready_list函数里面：
sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list:
ep_scan_ready_list首先将ep就绪链表里面的数据链接到一个全局的txlist里面，然后清空ep的就绪链表，同时还将ep的ovflist链表设置为NULL，ovflist是用单链表，是一个接受就绪事件的备份链表，当内核进程将事件从内核拷贝到用户空间时，这段时间目标文件可能会产生新的事件，这个时候，就需要将新的时间链入到ovlist里面。
仅接着，调用sproc回调函数(这里将调用ep_send_events_proc函数)将事件数据从内核拷贝到用户空间。
sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list -> ep_send_events_proc:
ep_send_events_proc回调函数循环获取监听项的事件数据，对每个监听项，调用ep_item_poll获取监听到的目标文件的事件，如果获取到事件，就调用__put_user函数将数据拷贝到用户空间。
回到ep_scan_ready_list函数，上面说到，在sproc回调函数执行期间，目标文件可能会产生新的事件链入ovlist链表里面，所以，在回调结束后，需要重新将ovlist链表里面的事件添加到rdllist就绪事件链表里面。
同时在最后，如果rdlist不为空（表示是否有就绪事件），并且由进程等待该事件，就调用wake_up_locked再一次唤醒内核进程处理事件的到达（流程跟前面一样，也就是将事件拷贝到用户空间）。
到这，epoll_wait的流程是结束了，但是有一个问题，就是前面提到的进程调用epoll_wait后会睡眠，但是这个进程什么时候被唤醒呢？在调用epoll_ctl为目标文件注册监听项时，对目标文件的监听项注册一个ep_ptable_queue_proc回调函数，ep_ptable_queue_proc回调函数将进程添加到目标文件的wakeup链表里面，并且注册ep_poll_callbak回调，当目标文件产生事件时，ep_poll_callbak回调就去唤醒等待队列里面的进程。
总结一下epoll该函数： epoll_wait函数会使调用它的进程进入睡眠（timeout为0时除外），如果有监听的事件产生，该进程就被唤醒，同时将事件从内核里面拷贝到用户空间返回给该进程。
⑵ linux手册翻译——epoll(7)
epoll — I/O 事件通知机制
epoll API与poll具有相同功能：监视多个文件描述符，以查看这些文件描述符中任何一个上可以进行特定的I/O操作，如是否可读/可写。epoll API可以使用edge-triggered和level-triggered两种接口，并且可以高性能的同时监视大量的fd，这是对epoll相对鱼poll的核心优势。
epoll的核心概念是epoll instance，这是一种内核数据结构，从用户空间角度看，可以视为一个包含两种列表的容器：
提供以下3个系统调用来创建和管理epoll instance：
两种触发模式：level_triggered (LT)和 edge_triggered(ET)
假设发生如下场景：
如果使用ET触发，那么步骤5就会阻塞挂起，这是因为对于ET模式而言，只有当缓冲区数据发生变化时才会触发事件(对于读，“变化”指新数据到达)。而对于LT而言，只要缓冲区中存在数据，就会一直触发。
使用ET时应使用非阻塞的fd （即无法读写时返回EAGIN，而非阻塞），以避免task阻塞导教其他fd无法监控。
合理使用ET模式步骤：
1）修改fd为非阻塞(non-blocking)
2）在read或write操作返回EAGIN后再执行wait等待事件。
为何ET需要非阻塞呢？因为ET模式下要循环多次read，并通过阻塞（即是否返回EAGIN）来确定数据是否全部读完。第一次执行read是不可能阻塞的。
若使用LT模式(默认情况下，使用ET模式)，则可以将epoll看作是一个快速的poll，可以在任何地方使用epoll(LT)替换poll，因为他们的语义完全相同。
即使采用ET模式，在多线程的情况依然会导致产生多个事件（对于同一被监控的fd)，这将导致多个线程操作同一fd，可以使用EPOLLNESHOT标志避免，即在一次wait返回后禁止fd再产生事件，并在处理完成后使用epoll_ctl的MOD操作重新开启。
在多进程或多线程中，epoll_fd是共享的，这将导致所有线程都会知道事情的发生，但是epoll仅会唤醒一个线程，以规避“群惊”现象。
If the system is in autosleep mode via /sys/power/autosleep and an event happens which wakes the device from sleep, the device driver will keep the device awake only until that event is queued. To keep the device awake until the event has been processed, it is necessary to use the epoll_ctl(2) EPOLLWAKEUP flag.
When the EPOLLWAKEUP flag is set in the events field for a struct epoll_event, the system will be kept awake from the moment the event is queued, through the epoll_wait(2) call which returns the event until the subsequent epoll_wait(2) call. If the event should keep the system awake beyond that time, then a separate wake_lock should be taken before the second epoll_wait(2) call.
以下接口可用于限制 epoll 消耗的内核内存用量：
虽然 epoll 在用作级别触发接口时具有与 poll(2) 相同的语义，但边缘触发的用法需要更多说明以避免应用程序事件循环中的阻塞。
在下面例子中，listener 是一个非阻塞套接字，在它上面调用了 listen(2)。 函数 do_use_fd() 使用新的就绪文件描述符，直到 read(2) 或 write(2) 返回 EAGAIN。 事件驱动的状态机应用程序应该在收到 EAGAIN 后记录其当前状态，以便在下一次调用 do_use_fd() 时，它将继续从之前停止的位置read (2) 或write (2)。
当使用ET模式时，出于性能原因，可以通过EPOLL_CTL_ADD调用 epoll_ctl(2)指定 (EPOLLIN|EPOLLOUT)添加一次文件描述符。 避免使用 EPOLL_CTL_MOD 调用 epoll_ctl(2)在 EPOLLIN 和 EPOLLOUT 之间连续切换。
The epoll API is Linux-specific. Some other systems provide similar mechanisms, for example, FreeBSD has kqueue, and Solaris has /dev/poll.
通过 epoll 文件描述符监视的文件描述符集可以通过进程的 /proc/[pid]/fdinfo 目录中的 epoll 文件描述符条目查看。 有关更多详细信息，请参阅 proc(5)。
kcmp(2) KCMP_EPOLL_TFD 操作可用于测试文件描述符是否存在于 epoll 实例中。
⑶ 关于Linux下的select/epoll
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类型的数组当中。
⑷ epoll知识点总结
epoll是linux IO多路复用的管理机制，现在是linux平台高性能网络io必要的组件。
理解内核epoll的运行原理，需要从四方面来理解：
1.epoll的数据结构。2.epoll的线程安全。
3.epoll的内核回调。4.epoll的LT与ET。
主要两个结构体 eventpoll 与 epitem。
eventpoll是每一个epoll所对应的，epitem是每一个IO所对应的事件。
数据结构图下图所示
list用来存储准备就绪的IO，内核IO准备就绪的时候，会执行epoll_event_callback的回调函数，将epitem添加到list中；当epoll_wait激活重新运行的时候，将list的epitem逐一到events参数中。
rbtree用来存储所有的io数据，方便快速通过io_fd查找；epoll_ctl执行EPOLL_CTL_ADD操作时，将epitem添加到rbtree中；epoll_ctl执行EPOLL_CTL_DEL操作时，将epitem从retree中删除。
以下几个包括list操作，rbtree操作，epoll_wait的等待需要加锁。
list使用最小粒度的spinlock锁，避免多核竞争。
rbtree的添加使用互斥锁，
epoll_wait采用pthread_cond_wait;
1.tcp三次握手，对端反馈ack，socket进入rcvd状态，需要将监听的socket的event置为EPOLLIN，此时标识可以进入到accept读取socket数据。
2.established状态时，收到数据，将socket的event置为EPOLLIN状态。
3.established状态时 收到fin，socket进入close_Wait，需要将socket的event设置为EPOLLIN，读取断开信息
4 . 检测到socket的send状态，cwnd >0可以发送的数据，需要将socket置为EPOLLOUT。
LT（水平触发）：socket接收缓冲区不为空 有数据可读，读事件一直触发；socket发送缓冲区不满，可以继续写入数据，写事件一直触发。
ET（边缘触发）：socket接收缓冲区变化时触发读事件，空的接收缓冲区刚接收到数据时触发读事件；socket发送缓冲区状态发生变化时触发写事件，即满的缓冲区刚空出空间时触发读事件。
LT的处理过程：
accept一个连接，添加到epoll中监听EPOLLIN事件。
当EPOLLIN事件到达时，read fd中的数据并处理，
当需要写出数据时，把数据write到fd中；如果数据较大，无法一次性写出，那么在epoll中监听EPOLLOUT事件。
当EPOLLOUT事件到达时，继续把数据write到fd中 ；如果数据写出完毕，那么在epoll中关闭EPOLLOUT事件。
ET的处理过程：
accept一个连接，添加到epoll中监听EPOLLIN|EPOLLOUT事件
当EPOLLIN事件到达时，read fd中数据并处理，read需要一直读，直到返回EAGAIN为止
当需要写出数据时，把数据write到fd中，直到数据全部写完或者write返回EAGAIN
当EPOLLOUT事件到达时，继续把数据write到fd中，直到数据全部写完，或者write返回EAGAIN
accept要考虑两个问题：
阻塞模式accept存在的问题：TCP连接被客户端夭折，即服务器调用accept之前，客户端主动发送RST终止连接，导致刚刚建立的连接从就绪队列中移出，如果套接口被设置成阻塞模式，服务器就一直阻塞到accept调用上，直到其他某个客户建立一个新的连接为止。在此期间，服务器 单纯阻塞在accept调用上，就绪队列上其他描述符都得不到处理。解决办法是把监听的套接口设置成非阻塞的，客户端在在服务器端调用accept之前中止某个连接时，accept调用可以立即返回-1。
ET模式accept存在的问题：
多个连接同时到达，，服务器TCP就行连接瞬间积累多个就绪连接，由于是边缘触发模式，epoll只会通知一次，accept只处理一个连接，导致TCP就绪队列中剩下的连接都得不到处理，解决办法是，while循环 中accpet调用，处理完accept就绪队列中所有连接后再退出循环。如何知道是否处理完所有连接，accept返回-1并且error设置为errno设置为EAGAIN便是所有连接都处理完。
LT 只要event为EPOLLIN时就能不断调用回调函数
ET 如果从EPOLLOUT变化为EPOLLIN时候，就会触发。
⑸ 定时器实现 & 红黑树，跳表
跳表：是为一个有序的链表建立多级索引的数据结构叫做跳表。redis中zset数据量大时底层数据结构使用跳表。
redis中定时器使用的是无序的双向链表。时间复杂度为O(N),redis作者在定时器备注了可以适当优化的措施：
1 尽可能让数据有序，2 可以使用跳表完成
回归正题，跳表：
其他地方借图一张如下：
跳表是基于有序链表所实现的，为了实现快速的查找，在做节点比较的时候跳过一些节点以达到快速查找的目的，是一种空间换时间的思想。
如上图，此跳表总共三层（level = 3），redis中zset在数据量比较大时，采用的即是跳表实现 其最大层数是32，再插入节点的时候随机生成层数，最大不超过32；
如上图为例，头节点不保存数据，按照上图分析插入操作：
插入之前要先从上层到下层临时保存每一层的当前节点，然后随即生成新的newlevel，如果newlevel大于level，则对于（level-newlevel）层进行初始化头结点 。
插入14前，没有数据只有头结点 ，当前level默认是1，用temp[0]临时保存节点,
while循环是找到下一个节点，比如插入34时，while之后level1 层 x节点就是23；插入50时，while循环之后 level1层temp[0] = 43,level2层 temp[1]=34,level3层 temp[2]=14;
保存完临时节点后，随机生成新的层数，
14插入时随机层数是3，大于之前默认的level =1；对于level2 和level3就要进行头结点赋值，temp[1]=header；temp[2]=header；
然后进行新节点的插入，之前遍历都是从高层向底层扩展，插入操作要从底层向高层扩展。
插入操作之后，形成了temp[0]->next = 节点14，temp[1]->next = 节点14，temp[2]->next = 节点14即header[0]->next = 节点14，header[1]->next = 节点14，header[2]->next = 节点14；
14节点插入之后，链表长度+1（单指最底层的链表）；
接着插入节点23，临时变量temp值为temp[0]= 节点14，temp[1] = 节点14，temp[2] = 节点14； 随机新的newlevel =1，说明23 只出现在level1层，进行插入后temp[0]->next = 节点23,其他两个节点不变。
插入节点34后，各层链表为
header[2]->14
header[1]->14->34
header[0]->14->23->34
以上就是插入的大致逻辑分析。
删除操作类似，先从上层开始向后遍历然后向下，删除时从下层开始向上操作。
跳表实现定时器demo源码地址： 跳表实现定时器demo
红黑树：一颗节点非红即黑的平衡二叉树。epoll底层使用红黑树。
红黑树插入 查询，删除等基本操作时间复杂度为O（lgn），跳表搜索插入删除操作时间复杂度接近O（lgn），最坏情况下变成O（n）。
做范围查找的时候 ，平衡树比跳表操作要复杂，平衡树上，找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其他不超过大值的节点，相对而言，跳表的范围查询就比较简单，只要找到小值，在第一层链表进行若干层遍历就行。
从算法实现难度讲，跳表比红黑树要简单的多。
红黑树也是实现定时器的数据结构之一，具体实现不再详叙。
⑹ Handler消息机制（一）：Linux的epoll机制
在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。
相比select模型， poll使用链表保存文件描述符，因此没有了监视文件数量的限制 ，但其他三个缺点依然存在。
假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接
如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：
每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而所有 添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法 。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
epoll结构示意图
通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
events可以是以下几个宏的集合：
EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；
EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP： 表示对应的文件描述符被挂断；
EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。
示例：
ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)
LT(LevelTriggered) :缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！
1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)……
ET工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。
LT工作模式：
LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。
当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。
1.减少用户态和内核态之间的文件句柄拷贝；
2.减少对可读可写文件句柄的遍历。
https://cloud.tencent.com/developer/information/linux%20epoll%E6%9C%BA%E5%88%B6
https://blog.csdn.net/u010657219/article/details/44061629
https://jiahao..com/s?id=1609322251459722004&wfr=spider&for=pc
⑺ Node.js的心脏-epoll
我们都知道Node.js是异步的，那么Node.js为什么会是异步的呢？这是因为Node.js使用了LIBUV做为它的跨平台抽象层。具体请看 nodejs运行机制
select、poll、epoll是Linux平台下的IO多路复用机制，用来管理大量的文件描述符。但是select/poll相对于epoll来说效率是低下的。
1、linux内核在select的每次返回前都要对所有的描述符 循环遍历 ，将有事件发生的文件描述符放在一个集合里返回。在描述符不多的时候对性能影响不大，但是当描述符达到数十万甚至更多的时候，这种处理方式造成大量的浪费和资源开销，select的效率会急剧下降。这是因为每次select的时候，会将所有的文件描述符从用户态拷贝的内核态，在内核态进行循环，查看是否有事件发生。2、select默认的管理的最大文件描述符是1024个，当然可以对linux内核从新编译来改变这个限制。
原理和select相似也是使用循环遍历的方式管理文件描述符，不同的是管理的文件最大文件描述符的数量没有限制（根据系统限制来定）。
下文讲解epoll实现原理
epoll改进了select的两个缺点，从而能够在管理大量的描述符的情况下，对系统资源的使用并没有急剧的增加，而只是对内存的使用有所增加（毕竟存储大量的描述符的数据结构会占用大量内存）。epoll在实现上的三个核心点是：1、mmap，2、红黑树，3、rdlist(就绪描述符链表)接下来一一解释这三个并且解释为什么会高效。
mmap是共享内存，用户进程和内核有一段地址(虚拟存储器地址)映射到了同一块物理地址上，这样当内核要对描述符上的事件进行检查的时候就不用来回的拷贝了。
红黑树是用来存储这些描述符的。当内核初始化epoll的时候（当调用epoll_create的时候内核也是个epoll描述符创建了一个文件，毕竟在Linux中一切都是文件，而epoll面对的是一个特殊的文件，和普通文件不同），会开辟出一块内核缓冲区，这块区域用来存储我们要监管的所有的socket描述符，当然在这里面存储有一个数据结构，这就是红黑树，由于红黑树的接近平衡的查找，插入，删除能力，在这里显着的提高了对描述符的管理。
rdlist就绪描述符链表这是一个双链表，epoll_wait()函数返回的也是这个就绪链表。当内核创建了红黑树之后，同时也会建立一个双向链表rdlist，用于存储准备就绪的描述符，当调用epoll_wait的时候在timeout时间内，只是简单的去管理这个rdlist中是否有数据，如果没有则睡眠至超时，如果有数据则立即返回并将链表中的数据赋值到events数组中。这样就能够高效的管理就绪的描述符，而不用去轮询所有的描述符。
当执行epoll_ctl时除了把socket描述符放入到红黑树中之外，还会给内核中断处理程序注册一个回调函数，告诉内核，当这个描述符上有事件到达（或者说中断了）的时候就调用这个回调函数。这个回调函数的作用就是将描述符放入到rdlist中，所以当一个socket上的数据到达的时候内核就会把网卡上的数据复制到内核，然后把socket描述符插入就绪链表rdlist中。
Epoll的两种模式：
1. 水平触发（LT）：使用此种模式，当数据可读的时候，epoll_wait()将会一直返回就绪事件。如果你没有处理完全部数据，并且再次在该epoll实例上调用epoll_wait()才监听描述符的时候，它将会再次返回就绪事件，因为有数据可读。
2. 边缘触发（ET）：使用此种模式，只能获取一次就绪通知，如果没有处理完全部数据，并且再次调用epoll_wait()的时候，它将会阻塞，因为就绪事件已经释放出来了。
ET的效能更高，但是对程序员的要求也更高。在ET模式下，我们必须一次干净而彻底地处理完所有事件。
epoll的linux实现
⑻ epoll底层原理总结
1 epoll一种网络模式，采用的是 IO多路复用技术（就是可以监控多个文件描述符），相比较于select 和poll是非常快的；
首先看这三个函数:
1 int epoll_create(int size);
2 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
3 int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);
函数用法不在这里讲解；
首先epoll_create创建一个epoll文件描述符，底层同时创建一个 红黑树 ，和一个 就绪链表 ；红黑树存储所监控的文件描述符的节点数据，就绪链表存储就绪的文件描述符的节点数据；epoll_ctl将会添加新的描述符，首先判断是红黑树上是否有此文件描述符节点，如果有，则立即返回。如果没有， 则在树干上插入新的节点，并且告知 内核注册回调函数 。当接收到某个文件描述符过来数据时，那么内核将该节点插入到就绪链表里面。epoll_wait将会接收到消息，并且将数据拷贝到用户空间，清空链表。对于LT模式epoll_wait清空就绪链表之后会检查该文件描述符是哪一种模式， 如果为LT模式，且必须该节点确实有事件未处理，那么就会把该节点重新放入到刚刚删除掉的且刚准备好的就绪链表，epoll_wait马上返回。 ET 模式不会检查，只会调用一次
每个epollfd在内核中有一个对应的eventpoll结构对象.其中关键的成员是一个readylist(eventpoll:rdllist)
和一棵红黑树(eventpoll:rbr).
一个fd被添加到epoll中之后(EPOLL_ADD),内核会为它生成一个对应的epitem结构对象.epitem被添加到
eventpoll的红黑树中.红黑树的作用是使用者调用EPOLL_MOD的时候可以快速找到fd对应的epitem。
调用epoll_wait的时候,将readylist中的epitem出列,将触发的事件拷贝到用户空间.之后判断epitem是否需
要重新添加回readylist.
epitem重新添加到readylist必须满足下列条件:
1) epitem上有用户关注的事件触发.
2) epitem被设置为水平触发模式(如果一个epitem被设置为边界触发则这个epitem不会被重新添加到readylist
中，在什么时候重新添加到readylist请继续往下看).
注意，如果epitem被设置为EPOLLONESHOT模式，则当这个epitem上的事件拷贝到用户空间之后,会将
这个epitem上的关注事件清空(只是关注事件被清空,并没有从epoll中删除，要删除必须对那个描述符调用
EPOLL_DEL)，也就是说即使这个epitem上有触发事件，但是因为没有用户关注的事件所以不会被重新添加到
readylist中.
epitem被添加到readylist中的各种情况(当一个epitem被添加到readylist如果有线程阻塞在epoll_wait中,那
个线程会被唤醒):
1)对一个fd调用EPOLL_ADD，如果这个fd上有用户关注的激活事件，则这个fd会被添加到readylist.
2)对一个fd调用EPOLL_MOD改变关注的事件，如果新增加了一个关注事件且对应的fd上有相应的事件激活，
则这个fd会被添加到readylist.
3)当一个fd上有事件触发时(例如一个socket上有外来的数据)会调用ep_poll_callback(见eventpoll::ep_ptable_queue_proc),
如果触发的事件是用户关注的事件，则这个fd会被添加到readylist中.
了解了epoll的执行过程之后,可以回答一个在使用边界触发时常见的疑问.在一个fd被设置为边界触发的情况下,
调用read/write,如何正确的判断那个fd已经没有数据可读/不再可写.epoll文档中的建议是直到触发EAGAIN
错误.而实际上只要你请求字节数小于read/write的返回值就可以确定那个fd上已经没有数据可读/不再可写.
最后用一个epollfd监听另一个epollfd也是合法的,epoll通过调用eventpoll::ep_eventpoll_poll来判断一个
epollfd上是否有触发的事件(只能是读事件).