一、什么是Epollepoll 是 Linux 内核提供的 IO 多路复用技术，用来解决 select 和 poll 存在的性能短板。 select 和 poll 每次调用都要把全部监听 fd 拷贝到内核，并且内核需要遍历所有 fd 检查就绪状态，返回之后用户态同样要遍历全部集合寻找就绪 fd，当监听 fd 数量很大的时候开销很高。epoll 一共提供三个系统调用：epoll_create、epoll_ctl、epoll_wait。epoll 在内核里维护一个事件管理结构体，会长期保存我们要监听的 fd 和对应的事件，只需要在最开始调用 epoll_create 创建对象，epoll_ctl 向内核添加、删除、修改要监听的 fd 事件，不需要每次调用都把全部 fd 数组拷贝进内核。当 fd 事件就绪时，内核会单独把就绪的 fd 收集起来。调用 epoll_wait 的时候，只会拿到就绪的 fd 集合，用户态只需要遍历就绪的 fd，不用遍历全部监听 fd，在大量 fd 场景下性能远高于 select 和 poll。二、Epoll与select、poll的对比select、poll、epoll 都属于 IO 多路复用技术，作用都是单线程同时监听多个文件描述符，当文件描述符就绪时通知程序处理 IO，避免线程阻塞在单个 IO 操作上。select 需要每次调用都把全部待监听的文件描述符集合从用户态拷贝到内核态，内核遍历所有 fd 来寻找就绪描述符，调用结束后还要把集合拷贝回用户态，并且存在最多监听 1024 个 fd 的硬限制，返回结果后用户程序仍然需要遍历全部 fd 才能找到就绪的连接。而poll 对 select 做了部分改进，取消了 1024 个文件描述符的数量上限，改用 pollfd 数组来管理监听的 fd，但是依然存在每次调用都要把全部 fd 数组拷贝进内核、内核需要遍历所有 fd 检测状态，调用返回后用户程序也要遍历整个数组筛选就绪事件的问题，在大量 fd 的场景下性能同样会变差。epoll 是 Linux 独有的 IO 多路复用方案，分为 epoll_create 创建 epoll 对象、epoll_ctl 管理监听 fd、epoll_wait 等待就绪事件这三个接口，文件描述符只需要在内核注册一次，不需要每次调用都完整拷贝，内核通过回调机制，在 fd 就绪时将就绪事件放入就绪链表，epoll_wait 只会拿到就绪的事件集合，用户代码只需要遍历就绪 fd 即可。在监听的文件描述符数量比较少时，select、poll、epoll 三者性能差距不大；当需要同时监听成千上万个 fd，且大部分连接处于空闲状态时，epoll 的性能优势就会凸显出来，Nginx、Redis 这类高并发服务就是基于 epoll 实现的。同时epoll 还提供两种事件触发模式，默认是 LT 水平触发，只要缓冲区还有未读完的数据就会持续上报事件，行为和 select、poll 比较接近；ET 边缘触发只会在状态发生变化的瞬间触发一次通知。三、LT、ET模式LT模式是水平触发，只要缓冲区还有未读完的数据就会持续上报事件。而ET模式是只会在状态变化的一瞬间触发通知，例如缓冲区中的数据从无到有或者从有到无、等。而ET模式就倒逼程序员必须要在通知的本轮内就将数据读完。而为了保证数据确实是被读完了，就必须循环地读。但是如果一直循环地读取，直到缓冲区没有数据了还在读取，那么由于缓冲区中已经没有数据了，recv就会被阻塞。但是不能让epoll阻塞，因为epoll是单进程地，一旦阻塞整个进程也会阻塞住，所以就必须将fd设置为非阻塞的！ET模式下不仅仅是读数据需要保证读取完毕，获取连接时也需要保证连接被全部获取完整，因为ET模式下只有在发生变化时才会进行通知LT模式和ET模式是没有绝对意义上的谁好谁坏，只是看在某个应用场景下谁更适合。ET这种高效的模式，LT也可以实现，但是LT是能做到，而ET是必须这么做！ET最大的优势在于倒逼程序员必须一次性将数据处理完毕，否则数据会丢失。四、理解ET模式和非阻塞文件描述符使用 ET 模式的 epoll，需要将文件描述设置为非阻塞，这个不是接口上的要求，而是工程实践上的要求。假设这样的场景：服务器接收到一个 10k 的请求，会向客户端返回一个应答数据，如果客户端收不到应答，不会发送第二个 10k 请求。如果服务端写的代码是阻塞式的 read，并且一次只 read 1k 数据的话，read 不能保证一次就把所有的数据都读出来，参考 man 手册的说明，还可能被信号打断，剩下的 9k 数据就会待在缓冲区中。此时由于 epoll 是 ET 模式，并不会认为文件描述符读就绪，epoll_wait 就不会再次返回，剩下的 9k 数据会一直留在缓冲区中，直到下一次客户端再给服务器写数据，epoll_wait 才能返回。但是这里就产生了死锁问题：服务器只读到 1k 个数据，必须等 10k 全部读完才会给客户端返回响应数据；客户端要读到服务器的响应，才会发送下一个请求；只有客户端发送了下一个请求，epoll_wait 才会返回，程序才有机会去读缓冲区中剩余的数据。所以，为了解决阻塞 read 不一定能一次性读完完整请求的问题，我们就要使用非阻塞轮询的方式读取缓冲区，保证把缓冲区里完整的数据全部读出来。而 LT 模式就不存在这个问题，只要缓冲区中还有数据没有读完，就能够持续让 epoll_wait 返回，标记文件描述符读就绪。当我们使用epoll_ctl时，带上EPOLLET这个宏，我们就可以将这个文件描述符设置为ET边缘触发模式。epoll_ctl 中的 events 可以是以下几个宏的集合：EPOLLIN ：表示对应的文件描述符可以读（包括对端 SOCKET 正常关闭）；EPOLLOUT ：表示对应的文件描述符可以写；EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；EPOLLERR：表示对应的文件描述符发生错误；EPOLLHUP：表示对应的文件描述符被挂断；EPOLLET ：将 EPOLL 设为边缘触发 (Edge Triggered) 模式，这是相对于水平触发 (Level Triggered) 来说的。EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个 socket 的话，需要再次把这个 socket 加入到 EPOLL 红黑树里。oneshot模式是当事件就绪时，文件描述符会被放入就绪队列中，同时将节点从红黑树中移除。socket 的 EPOLLOUT 写事件在默认情况下是满足的，只有发送缓冲区被写满的时候，写事件才不满足。此时我们把 sockfd 交给 epoll 托管监听，等到发送缓冲区腾出空间，epoll 就会检测到 EPOLLOUT 写事件就绪。EPOLLOUT 写事件需要按需设置，大部分场景下 socket 发送缓冲区都有空闲空间，写条件天然满足，只有少数场景缓冲区才会被填满，所以不能一直常设监听 EPOLLOUT 写事件，否则 epoll 会持续上报写就绪事件，造成 CPU 资源浪费。
一、什么是Epollepoll 是 Linux 内核提供的 IO 多路复用技术，用来解决 select 和 poll 存在的性能短板。 select 和 poll 每次调用都要把全部监听 fd 拷贝到内核，并且内核需要遍历所有 fd 检查就绪状态，返回之后用户态同样要遍历全部集合寻找就绪 fd，当监听 fd 数量很大的时候开销很高。epoll 一共提供三个系统调用：epoll_create、epoll_ctl、epoll_wait。epoll 在内核里维护一个事件管理结构体，会长期保存我们要监听的 fd 和对应的事件，只需要在最开始调用 epoll_create 创建对象，epoll_ctl 向内核添加、删除、修改要监听的 fd 事件，不需要每次调用都把全部 fd 数组拷贝进内核。当 fd 事件就绪时，内核会单独把就绪的 fd 收集起来。调用 epoll_wait 的时候，只会拿到就绪的 fd 集合，用户态只需要遍历就绪的 fd，不用遍历全部监听 fd，在大量 fd 场景下性能远高于 select 和 poll。二、Epoll与select、poll的对比select、poll、epoll 都属于 IO 多路复用技术，作用都是单线程同时监听多个文件描述符，当文件描述符就绪时通知程序处理 IO，避免线程阻塞在单个 IO 操作上。select 需要每次调用都把全部待监听的文件描述符集合从用户态拷贝到内核态，内核遍历所有 fd 来寻找就绪描述符，调用结束后还要把集合拷贝回用户态，并且存在最多监听 1024 个 fd 的硬限制，返回结果后用户程序仍然需要遍历全部 fd 才能找到就绪的连接。而poll 对 select 做了部分改进，取消了 1024 个文件描述符的数量上限，改用 pollfd 数组来管理监听的 fd，但是依然存在每次调用都要把全部 fd 数组拷贝进内核、内核需要遍历所有 fd 检测状态，调用返回后用户程序也要遍历整个数组筛选就绪事件的问题，在大量 fd 的场景下性能同样会变差。epoll 是 Linux 独有的 IO 多路复用方案，分为 epoll_create 创建 epoll 对象、epoll_ctl 管理监听 fd、epoll_wait 等待就绪事件这三个接口，文件描述符只需要在内核注册一次，不需要每次调用都完整拷贝，内核通过回调机制，在 fd 就绪时将就绪事件放入就绪链表，epoll_wait 只会拿到就绪的事件集合，用户代码只需要遍历就绪 fd 即可。在监听的文件描述符数量比较少时，select、poll、epoll 三者性能差距不大；当需要同时监听成千上万个 fd，且大部分连接处于空闲状态时，epoll 的性能优势就会凸显出来，Nginx、Redis 这类高并发服务就是基于 epoll 实现的。同时epoll 还提供两种事件触发模式，默认是 LT 水平触发，只要缓冲区还有未读完的数据就会持续上报事件，行为和 select、poll 比较接近；ET 边缘触发只会在状态发生变化的瞬间触发一次通知。三、LT、ET模式LT模式是水平触发，只要缓冲区还有未读完的数据就会持续上报事件。而ET模式是只会在状态变化的一瞬间触发通知，例如缓冲区中的数据从无到有或者从有到无、等。而ET模式就倒逼程序员必须要在通知的本轮内就将数据读完。而为了保证数据确实是被读完了，就必须循环地读。但是如果一直循环地读取，直到缓冲区没有数据了还在读取，那么由于缓冲区中已经没有数据了，recv就会被阻塞。但是不能让epoll阻塞，因为epoll是单进程地，一旦阻塞整个进程也会阻塞住，所以就必须将fd设置为非阻塞的！ET模式下不仅仅是读数据需要保证读取完毕，获取连接时也需要保证连接被全部获取完整，因为ET模式下只有在发生变化时才会进行通知LT模式和ET模式是没有绝对意义上的谁好谁坏，只是看在某个应用场景下谁更适合。ET这种高效的模式，LT也可以实现，但是LT是能做到，而ET是必须这么做！ET最大的优势在于倒逼程序员必须一次性将数据处理完毕，否则数据会丢失。四、理解ET模式和非阻塞文件描述符使用 ET 模式的 epoll，需要将文件描述设置为非阻塞，这个不是接口上的要求，而是工程实践上的要求。假设这样的场景：服务器接收到一个 10k 的请求，会向客户端返回一个应答数据，如果客户端收不到应答，不会发送第二个 10k 请求。如果服务端写的代码是阻塞式的 read，并且一次只 read 1k 数据的话，read 不能保证一次就把所有的数据都读出来，参考 man 手册的说明，还可能被信号打断，剩下的 9k 数据就会待在缓冲区中。此时由于 epoll 是 ET 模式，并不会认为文件描述符读就绪，epoll_wait 就不会再次返回，剩下的 9k 数据会一直留在缓冲区中，直到下一次客户端再给服务器写数据，epoll_wait 才能返回。但是这里就产生了死锁问题：服务器只读到 1k 个数据，必须等 10k 全部读完才会给客户端返回响应数据；客户端要读到服务器的响应，才会发送下一个请求；只有客户端发送了下一个请求，epoll_wait 才会返回，程序才有机会去读缓冲区中剩余的数据。所以，为了解决阻塞 read 不一定能一次性读完完整请求的问题，我们就要使用非阻塞轮询的方式读取缓冲区，保证把缓冲区里完整的数据全部读出来。而 LT 模式就不存在这个问题，只要缓冲区中还有数据没有读完，就能够持续让 epoll_wait 返回，标记文件描述符读就绪。当我们使用epoll_ctl时，带上EPOLLET这个宏，我们就可以将这个文件描述符设置为ET边缘触发模式。epoll_ctl 中的 events 可以是以下几个宏的集合：EPOLLIN ：表示对应的文件描述符可以读（包括对端 SOCKET 正常关闭）；EPOLLOUT ：表示对应的文件描述符可以写；EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；EPOLLERR：表示对应的文件描述符发生错误；EPOLLHUP：表示对应的文件描述符被挂断；EPOLLET ：将 EPOLL 设为边缘触发 (Edge Triggered) 模式，这是相对于水平触发 (Level Triggered) 来说的。EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个 socket 的话，需要再次把这个 socket 加入到 EPOLL 红黑树里。oneshot模式是当事件就绪时，文件描述符会被放入就绪队列中，同时将节点从红黑树中移除。socket 的 EPOLLOUT 写事件在默认情况下是满足的，只有发送缓冲区被写满的时候，写事件才不满足。此时我们把 sockfd 交给 epoll 托管监听，等到发送缓冲区腾出空间，epoll 就会检测到 EPOLLOUT 写事件就绪。EPOLLOUT 写事件需要按需设置，大部分场景下 socket 发送缓冲区都有空闲空间，写条件天然满足，只有少数场景缓冲区才会被填满，所以不能一直常设监听 EPOLLOUT 写事件，否则 epoll 会持续上报写就绪事件，造成 CPU 资源浪费。