‘壹’ linux select/poll/epoll 原理（一）实现基础
本序列涉及的 Linux 源码都是基于 linux-4.14.143 。
1.1 文件抽象
在 Linux 内核里，文件是一个抽象，设备是个文件，网络套接字也是个文件。
文件抽象必须支持的能力定义在 file_operations 结构体里。
在 Linux 里，一个打开的文件对应一个文件描述符 file descriptor/FD，FD 其实是一个整数，内核把进程打开的文件维护在一个数组里，FD 对应的是数组的下标。
文件抽象的能力定义：
1.2 文件 poll 操作
poll 函数的原型：
文件抽象 poll 函数的具体实现必须完成两件事（这两点算是规范了）：
1. 在 poll 函数敢兴趣的等待队列上调用 poll_wait 函数，以接收到唤醒；具体的实现必须把 poll_table 类型的参数作为透明对象来使用，不需要知道它的具体结构。
2. 返回比特掩码，表示当前可立即执行而不会阻塞的操作。
下面是某个驱动的 poll 实现示例，来自：https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch05s03.html：
poll 函数接收的 poll_table 只有一个队列处理函数 _qproc 和感兴趣的事件属性 _key。
文件抽象的具体实现在构建时会初始化一个或多个 wait_queue_head_t 类型的事件等待队列 。
poll 等待的过程：
事件发生时的唤醒过程：
一个小困惑：
‘贰’ 关于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类型的数组当中。
‘叁’ Linux下各种锁的理解和使用及总结解决epoll惊群问题(面试常考)-
锁出现的原因
临界资源是什么: 多线程执行流所共享的资源
锁的作用是什么, 可以做原子操作, 在多线程中针对临界资源的互斥访问... 保证一个时刻只有一个线程可以持有锁对于临界资源做修改操作...
任何一个线程如果需要修改，向临界资源做写入操作都必须持有锁，没有持有锁就不能对于临界资源做写入操作.
锁 ： 保证同一时刻只能有一个线程对于临界资源做写入操作 (锁地功能)
再一个直观地代码引出问题，再从指令集的角度去看问题
上述一个及其奇怪的结果，这个结果每一次运行都可能是不一样的，Why ？ 按照我们本来的想法是每一个线程 + 20000000 结果肯定应该是60000000呀，可以就是达不到这个值
为何？ (深入汇编指令来看) 一定将过程放置到汇编指令上去看就可以理解这个过程了.
a++; 或者 a += 1; 这些操作的汇编操作是几个步骤?
其实是三个步骤：
正常情况下，数据少，操作的线程少，问题倒是不大，想一想要是这样的情况下，操作次数大，对齐操作的线程多，有些线程从中间切入进来了，在运算之后还没写回内存就另外一个线程切入进来同时对于之前的数据进行++ 再写回内存, 啥效果，多次++ 操作之后结果确实一次加加操作后的结果。 这样的操作 (术语叫做函数的重入) 我觉得其实就是重入到了汇编指令中间了，还没将上一次运算的结果写回内存就重新对这个内存读取再运算写入，结果肯定和正常的逻辑后的结果不一样呀
来一幅图片解释一下
咋办? 其实问题很清楚，我们只需要处理的是多条汇编指令不能让它中间被插入其他的线程运算. （要想自己在执行汇编指令的时候别人不插入进来） 将多条汇编指令绑定成为一条指令不就OK了嘛。
也就是原子操作！！！
不会原子操作？操作系统给咱提供了线程的 绑定方式工具呀：mutex 互斥锁(互斥量)， 自旋锁(spinlock)， 读写锁（readers-writer lock） 他们也称作悲观锁. 作用都是一个样，将多个汇编指令锁成为一条原子操作 (此处的汇编指令也相当于如下的临界资源)
悲观锁：锁如其名，每次都悲观地认为其他线程也会来修改数据，进行写入操作，所以会在取数据前先加锁保护，当其他线程想要访问数据时，被阻塞挂起
乐观锁：每次取数据的时候，总是乐观地认为数据不会被其他线程修改，因此不上锁。但是在更新数据前， 会判断其他数据在更新前有没有对数据进行修改。
互斥锁
最为常见使用地锁就是互斥锁, 也称互斥量. mutex
特征，当其他线程持有互斥锁对临界资源做写入操作地时候，当前线程只能挂起等待，让出CPU，存在线程间切换工作
解释一下存在线程间切换工作 : 当线程试图去获取锁对临界资源做写入操作时候，如果锁被别的线程正在持有，该线程会保存上下文直接挂起，让出CPU，等到锁被释放出来再进行线程间切换，从新持有CPU执行写入操作
互斥锁需要进行线程间切换，相比自旋锁而言性能会差上许多，因为自旋锁不会让出CPU, 也就不需要进行线程间切换的步骤，具体原理下一点详述
加互斥量(互斥锁)确实可以达到要求，但是会发现运行时间非常的长，因为线程间不断地切换也需要时间, 线程间切换的代价比较大.
相关视频推荐
你绕不开的组件—锁，4个方面手撕锁的多种实现
“惊群”原理、锁的设计方案及绕不开的“死锁”问题
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
自旋锁
spinlock.自旋锁.
对比互斥量(互斥锁)而言，获取自旋锁不需要进行线程间切换，如果自旋锁正在被别的线程占用，该线程也不会放弃CPU进行挂起休眠，而是恰如其名的在哪里不断地循环地查看自旋锁保持者(持有者)是否将自旋锁资源释放出来... （自旋地原来就是如此）
口语解释自旋：持有自旋锁的线程不释放自旋锁，那也没有关系呀，我就在这里不断地一遍又一遍地查询自旋锁是否释放出来，一旦释放出来我立马就可以直接使用 (因为我并没有挂起等待，不需要像互斥锁还需要进行线程间切换，重新获取CPU，保存恢复上下文等等操作)
哪正是因为上述这些特点，线程尝试获取自旋锁，获取不到不会采取休眠挂起地方式，而是原地自旋（一遍又一遍查询自旋锁是否可以获取）效率是远高于互斥锁了. 那我们是不是所有情况都使用自旋锁就行了呢，互斥锁就可以放弃使用了吗????
解释自旋锁地弊端：如果每一个线程都仅仅只是需要短时间获取这个锁，那我自旋占据CPU等待是没啥问题地。要是线程需要长时间地使用占据（锁）。。。 会造成过多地无端占据CPU资源，俗称站着茅坑不拉屎... 但是要是仅仅是短时间地自旋，平衡CPU利用率 + 程序运行效率 （自旋锁确实是在有些时候更加合适）
自旋锁需要场景：内核可抢占或者SMP(多处理器)情况下才真正需求 (避免死锁陷入死循环，疯狂地自旋，比如递归获取自旋锁. 你获取了还要获取，但是又没法释放)
自旋锁的使用函数其实和互斥锁几乎是一摸一样地，仅仅只是需要将所有的mutex换成spin即可
仅仅只是在init存在些许不同
何为惊群，池塘一堆, 我瞄准一条插过去，但是好似所有的都像是觉着自己正在被插一样的四处逃窜。 这个就是惊群的生活一点的理解
惊群现象其实一点也不少，比如说 accept pthread_cond_broadcast 还有多个线程共享epoll监视一个listenfd 然后此刻 listenfd 说来 SYN了，放在了SYN队列中，然后完成了三次握手放在了 accept队列中了, 现在问题是这个connect我应该交付给哪一个线程处理呢.
多个epoll监视准备工作的线程 就是这群 ()，然后connet就是鱼叉，这一叉下去肯定是所有的 epoll线程都会被惊醒 (多线程共享listenfd引发的epoll惊群)
同样如果将上述的多个线程换成多个进程共享监视 同一个 listenfd 就是(多进程的epoll惊群现象)
咱再画一个草图再来理解一下这个惊群:
如果是多进程道理是一样滴，仅仅只是将所有的线程换成进程就OK了
终是来到了今天的正题了: epoll惊群问题地解决上面了...
首先 先说说accept的惊群问题，没想到吧accept 平时大家写它的多线程地时候，多个线程同时accept同一个listensock地时候也是会存在惊群问题地，但是accept地惊群问题已经被Linux内核处理了: 当有新的连接进入到accept队列的时候，内核唤醒且仅唤醒一个进程来处理
但是对于epoll的惊群问题，内核却没有直接进行处理。哪既然内核没有直接帮我们处理，我们应该如何针对这种现象做出一定的措施呢?
惊群效应带来的弊端: 惊群现象会造成epoll的伪唤醒，本来epoll是阻塞挂起等待着地，这个时候因为挂起等待是不会占用CPU地。。。 但是一旦唤醒就会占用CPU去处理发生地IO事件， 但是其实是一个伪唤醒，这个就是对于线程或者进程的无效调度。然而进程或者线程地调取是需要花费代价地，需要上下文切换。需要进行进程(线程)间的不断切换... 本来多核CPU是用来支持高并发地，但是现在却被用来无效地唤醒，对于多核CPU简直就是一种浪费 （浪费系统资源） 还会影响系统的性能.
解决方式（一般是两种）
Nginx的解决方式:
加锁：惊群问题发生的前提是多个进程（线程）监听同一个套接字(listensock)上的事件，所以我们只让一个进程（线程）去处理监听套接字就可以了。
画两张图来理解一下：
上述还没有进行一个每一个进程都对应一个listensock 而是多线程共享一个listensock 运行结果如下
所有的线程同时被唤醒了，但是实际上会处理连接的仅仅只是一个线程，
咱仅仅只是将主线程做如上这样一个简单的修改，每一个线程对应一个listensock；每一个线程一个独有的监视窗口，将问题抛给内核去处理，让内核去负载均衡 ： 结果如下
仅仅唤醒一个线程来进行处理连接，解决了惊群问题
本文通过介绍两种锁入手，以及为什么需要锁，锁本质就是为了保护，持有锁你就有权力有能力操作写入一定的临界保护资源，没有锁你就不行需要等待，本质其实是将多条汇编指令绑定成原子操作
然后介绍了惊群现象，通过一个巧妙地例子，扔一颗石子，只是瞄准一条鱼扔过去了，但是整池鱼都被惊醒了，
对应我们地实际问题就是， 多个线程或者进程共同监视同一个listensock。。。。然后IO连接事件到来地时候本来仅仅只是需要一个线程醒过来处理即可，但是却会使得所有地线程（进程）全部醒过来，造成不必要地进程线程间切换，多核CPU被浪费喔，系统资源被浪费
处理方式 一。 Nginx 源码加互斥锁处理。。 二。设置SO_REUSEPORT, 使得多个进程线程可以同时连接同一个port , 为每一个进程线程搞一个listensock... 将问题抛给内核去处理，让他去负载均衡地仅仅将IO连接事件分配给一个进程或线程
‘肆’ Redis源码分析之事件循环
本篇我们来讲Redis的事件循环，Redis的事件循环会根据系统选择evport、epoll、kqueue或select来进行IO多路复用，我们这里只分析epoll。
首先我们来看一下Redis的IO多路复用对事件循环(aeEventLoop)提供的接口。
以epoll(ae_epoll.c)为例，先来看一下Redis的IO多路复用的使用过程：
首先需要创建，即调用aeApiCreate：
aeApiState结构体有两个成员，events和epfd。events用于存储就绪的epoll事件，epfd存储epoll的文件描述符。aeApiCreate的主要逻辑是为aeApiState分配存储空间，调用epoll_create系统调用创建epoll并获取描述符，最后将aeApiState赋值给aeEventLoop的apidata。
然后在有新的文件描述符(比如接受了一个新连接)需要加入到epoll中时，调用aeApiAddEvent：
参数fd是需要监视的文件描述符，mask标明是需要监视可读还是可写事件。aeApiAddEvent的主要逻辑是调用系统调用epoll_ctl注册或修改添加事件的监听类型到epoll。
然后在有文件描述符失效或者需要修改监听类型时，调用aeApiDelEvent：
参数fd是需要删除的文件描述符，mask标明是需要删除可读还是可写事件。aeApiDelEvent主要逻辑是调用系统调用epoll_ctl删除或修改删除事件的监听类型到epoll。
然后需要检查是否有就绪的事件，调用aeApiPoll：
tvp是等待时间，一般而言，这个值是0(不是NULL)代表没有就绪事件立即返回。主要逻辑是调用系统调用epoll_wait拿到就绪事件保存到events中，然后将events中的就绪事件复制到事件循环aeEventLoop的fired中，最后返回就绪事件的数量。
我们来分析一下Redis的事件循环(ae.c)。
先看主要接口：
创建过程：
初始化aeEventLoop和aeApiState并返回aeEventLoop。
注册文件事件：
存储到events中并调用aeApiAddEvent注册到epoll中。
注册定时事件：
创建aeTimeEvent并将其插入到定时事件链表的头部。
主循环：
不停的调用aeProcessEvents拉取并处理事件。
接下来看aeProcessEvents的逻辑：
再看一下定时事件的触发，也就是processTimeEvents的逻辑：
遍历注册的定时事件，找出到期的事件并调用处理函数，如果处理函数返回了下次执行的时间，则更新下次触发的时间，否则删除该事件。
‘伍’ mac os下有办法是用epoll吗我要编译一个linux下写的源码，发现系统里没有epoll，有办法安装吗
你这个程序是 linux-only 的还是 POSIX 兼容的？
如果是兼容的你看看他缺那个函数库装上就行了。我记得 mac 有 posix 兼容支持功能库装上就行了，当然这个兼容不全，有些东西还要自己另外装。
不过 epoll 我没印象是什么……好像是 Linux 内核的？
如果是 Linux 内核的东西，那这个程序就是 Linux-Only 的程序，你只能做源代码移植了。
BSD 的内核有 Linux 兼容接口层可以用，MAC 的我没印象有。
‘陆’ epoll模型
最近一段时间看epoll的源码，看的抓耳挠腮。本着分享的原则，分享一下我对epoll的理解，注意：本文并不能让你从零开始学epoll，而是希望在你看epoll源码也学的抓耳挠腮的时候，看到本文能对你有一丢小小的帮助。
本篇文章并不会设计到具体源码，只是涉及到epoll的整个数据交互的流程。
一个应用程序，想要使用epoll模型，首先会创建一个epoll模型。这里是在内核创建一个epoll模型，你可以把这个模型看做一个java对象。这个对象里有一个阻塞列表，一个就绪列表，一个红黑树。
每一次通讯，客户端都会建立一个socket，socket有一个文件描述符fd，系统通过这个fd去操作socket，系统会封装一个epitem（红黑树的节点），这个epitem包含socket和一个回调事件，当然还有其他属性，我们暂且不提。
然后内核会把这个epitem添加到红黑树，当然，也可以修改和删除事件。
用户进程去就绪列表拿就绪事件。拿到就返回，拿不到就进入epoll阻塞列表，当然也可以设置超时参数为0表示拿不到也立即返回。
回调事件会根据监听的事件类型，把fd放到就绪列表。然后去通知阻塞进程。阻塞进程从就绪列表拿走就绪事件，也就是把就绪事件从内核空间拷贝到用户空间。
这是我对epoll模型的大概描述，接下来，从交互的层面再说一说：
当一个数据包从网络传输过来，包含了协议，发送端ip 和端口，目标端ip和接口。内核根据这五个要素去找到对应的socket，就可以拿到对应的fd，有了fd，就可以去红黑树里找epitem，找到了epitem就可以去触发回调事件。回调事件就可以把就绪事件放到就绪列表。
输入netstat命名就可以查看系统的所有活跃的socket链接：
例子里，本地机器有两个socket链接和172.217.27.42.443端口建立了链接，当网络数据包传输过来，发送端ip和端口号就是172.217.27.42.443，接收端可能是54040和54035端口，用发送端ip和端口号为参数去对应foreign address，用接收端参数去对应local address，就可以找到具体的哪一个socket连接。
如果在拷贝就绪事件的时候，出现了新的就绪事件怎么办，其实还有一个备用链表，拷贝事件的时候，如果有就绪事件产生，先放到备用链表，拷贝完成再把备用链表的就绪事件放到就绪列表里。
如果想看细节，还是得自己撸源码，别人讲只能听个大概。
‘柒’ nginx 源码 epoll模块在哪个文件
Linux平台上，Nginx使用epoll完成事件驱动，实现高并发；本文将不对epoll本身进行介绍（网上一堆一堆的文章介绍epoll的原理及使用方法，甚至源码分析等），仅看一下Nginx是如何使用epoll的。
Nginx在epoll模块中定义了好几个函数，这些函数基本都是作为回调注册到事件抽象层的对应接口上，从而实现了事件驱动的具体化，我们看如下的一段代码：
[cpp] view plain print?
ngx_event_mole_t ngx_epoll_mole_ctx = {
&epoll_name,
ngx_epoll_create_conf, /* create configuration */
ngx_epoll_init_conf, /* init configuration */
{
ngx_epoll_add_event, /* add an event */
ngx_epoll_del_event, /* delete an event */
ngx_epoll_add_event, /* enable an event */
ngx_epoll_del_event, /* disable an event */
ngx_epoll_add_connection, /* add an connection */
ngx_epoll_del_connection, /* delete an connection */
NULL, /* process the changes */
ngx_epoll_process_events, /* process the events */
ngx_epoll_init, /* init the events */
ngx_epoll_done, /* done the events */
}
};
这段代码就是epoll的相关函数注册到事件抽象层，这里所谓的事件抽象层在前面的博文中有提过，就是Nginx为了方便支持和开发具体的I/O模型，从而实现的一层抽象。代码后面的注释将功能说明得很详细了，本文就只重点关注ngx_epoll_init和ngx_epoll_process_events两个函数，其他几个函数就暂且忽略了。
ngx_epoll_init主要是完成epoll的相关初始化工作，代码分析如下：
[cpp] view plain print?
static ngx_int_t
ngx_epoll_init(ngx_cycle_t *cycle, ngx_msec_t timer)
{
ngx_epoll_conf_t *epcf;
/*取得epoll模块的配置结构*/
epcf = ngx_event_get_conf(cycle->conf_ctx, ngx_epoll_mole);
/*ep是epoll模块定义的一个全局变量，初始化为-1*/
if (ep == -1) {
/*创一个epoll对象，容量为总连接数的一半*/
ep = epoll_create(cycle->connection_n / 2);
if (ep == -1) {
ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
"epoll_create() failed");
return NGX_ERROR;
}
}
/*nevents也是epoll模块定义的一个全局变量，初始化为0*/
if (nevents < epcf->events) {
if (event_list) {
ngx_free(event_list);
}
/*event_list存储产生事件的数组*/
event_list = ngx_alloc(sizeof(struct epoll_event) * epcf->events,
cycle->log);
if (event_list == NULL) {
return NGX_ERROR;
}
}
nevents = epcf->events;
/*初始化全局变量ngx_io, ngx_os_is定义为：
ngx_os_io_t ngx_os_io = {
ngx_unix_recv,
ngx_readv_chain,
ngx_udp_unix_recv,
ngx_unix_send,
ngx_writev_chain,
0
};（位于src/os/unix/ngx_posix_init.c）
*/
ngx_io = ngx_os_io;
/*这里就是将epoll的具体接口函数注册到事件抽象层接口ngx_event_actions上。
具体是上文提到的ngx_epoll_mole_ctx中封装的如下几个函数
ngx_epoll_add_event,
ngx_epoll_del_event,
ngx_epoll_add_event,
ngx_epoll_del_event,
ngx_epoll_add_connection,
ngx_epoll_del_connection,
ngx_epoll_process_events,
ngx_epoll_init,
ngx_epoll_done,
*/
ngx_event_actions = ngx_epoll_mole_ctx.actions;
#if (NGX_HAVE_CLEAR_EVENT)
/*epoll将添加这个标志,主要为了实现边缘触发*/
ngx_event_flags = NGX_USE_CLEAR_EVENT
#else
/*水平触发*/
ngx_event_flags = NGX_USE_LEVEL_EVENT
#endif
|NGX_USE_GREEDY_EVENT /*io的时候，直到EAGAIN为止*/
|NGX_USE_EPOLL_EVENT; /*epoll标志*/
return NGX_OK;
}
epoll初始化工作没有想象中的复杂，和我们平时使用epoll都一样，下面看ngx_epoll_process_events，这个函数主要用来完成事件的等待并处理。
[cpp] view plain print?
static ngx_int_t
ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)
{
int events;
uint32_t revents;
ngx_int_t instance, i;
ngx_uint_t level;
ngx_err_t err;
ngx_log_t *log;
ngx_event_t *rev, *wev, **queue;
ngx_connection_t *c;
/*一开始就是等待事件，最长等待时间为timer；nginx为事件
专门用红黑树维护了一个计时器。后续对这个timer单独分析。
*/
events = epoll_wait(ep, event_list, (int) nevents, timer);
if (events == -1) {
err = ngx_errno;
} else {
err = 0;
}
if (flags & NGX_UPDATE_TIME || ngx_event_timer_alarm) {
/*执行一次时间更新, nginx将时间缓存到了一组全局变量中，方便程序高效的获取事件。*/
ngx_time_update();
}
/*处理wait错误*/
if (err) {
if (err == NGX_EINTR) {
if (ngx_event_timer_alarm) {
ngx_event_timer_alarm = 0;
return NGX_OK;
}
level = NGX_LOG_INFO;
} else {
level = NGX_LOG_ALERT;
}
ngx_log_error(level, cycle->log, err, "epoll_wait() failed");
return NGX_ERROR;
}
/*wait返回事件数0，可能是timeout返回，也可能是非timeout返回；非timeout返回则是error*/
if (events == 0) {
if (timer != NGX_TIMER_INFINITE) {
return NGX_OK;
}
ngx_log_error(NGX_LOG_ALERT, cycle->log, 0,
"epoll_wait() returned no events without timeout");
return NGX_ERROR;
}
log = cycle->log;
/*for循环开始处理收到的所有事件*/
for (i = 0; i < events; i++) {
/*取得发生此事件的连接*/
c = event_list[i].data.ptr;
instance = (uintptr_t) c & 1;
c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
/*获得该连接上的读事件*/
rev = c->read;
。。。。。。。。。。。。。
/*取得发生一个事件*/
revents = event_list[i].events;
/*记录wait的错误返回状态*/
if (revents & (EPOLLERR|EPOLLHUP)) {
ngx_log_debug2(NGX_LOG_DEBUG_EVENT, log, 0,
"epoll_wait() error on fd:%d ev:%04XD",
c->fd, revents);
}
if ((revents & (EPOLLERR|EPOLLHUP))
&& (revents & (EPOLLIN|EPOLLOUT)) == 0)
{
/*
* if the error events were returned without EPOLLIN or EPOLLOUT,
* then add these flags to handle the events at least in one
* active handler
*/
revents |= EPOLLIN|EPOLLOUT;
}
/*该事件是一个读事件，并该连接上注册的读事件是active的*/
if ((revents & EPOLLIN) && rev->active) {
if ((flags & NGX_POST_THREAD_EVENTS) && !rev->accept) {
rev->posted_ready = 1;
} else {
rev->ready = 1;
}
/*事件放入相应的队列中；关于此处的先入队再处理，在前面的文章中已经介绍过了。*/
if (flags & NGX_POST_EVENTS) {
queue = (ngx_event_t **) (rev->accept ?
&ngx_posted_accept_events : &ngx_posted_events);
ngx_locked_post_event(rev, queue); /*入队*/
} else {
rev->handler(rev);
}
}
wev = c->write;
/*发生的是一个写事件，和读事件完全一样的逻辑过程*/
if ((revents & EPOLLOUT) && wev->active) {
if (flags & NGX_POST_THREAD_EVENTS) {
wev->posted_ready = 1;
} else {
wev->ready = 1;
}
/*先入队再处理*/
if (flags & NGX_POST_EVENTS) {
ngx_locked_post_event(wev, &ngx_posted_events);
} else {
wev->handler(wev);
}
}
}
return NGX_OK;
}
本文将关注的两个epoll函数也就这么一点代码了，但整个epoll还有添加事件和删除事件等的相关函数，代码都很简单，本文就不做具体的分析了。
写到此处的时候，我感觉epoll模块没有分析的足够详细，或者说是没有足够的理解作者的用意，如果你有更好的理解，希望能够告诉我。或许，随着后面的分析，能够逐渐的真正明白吧。
‘捌’ 面试必问的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时除外），如果有监听的事件产生，该进程就被唤醒，同时将事件从内核里面拷贝到用户空间返回给该进程。
‘玖’ mac os下有办法是用epoll吗我要编译一个linux下写的源码，发现系统里没有epoll，有办法安装吗
kqueue也需能行，Macos毕竟是基于bsd的