多路复用器（select、poll、epoll）

基本知识

先了解“多线程/多线程连接处理模型”

在该模型下，一个用户连接请求会由一个内核进程处理，而一个内核进程会创建一个应用程序进程，即app进程来处理连接请求。应用程序在调用IO时，采用的是BIO通讯方式，即应用程序进程在未获取到IO响应之前是处于阻塞状态。
该模型的优点是，内核进程不存在对app进程的竞争，一个内核进程对应一个app进程。但弊端也就显而易见了。需要创建过多的app进程，而该创建过程十分消耗系统资源。且一个系统的进程数量是有上限的，所以该模型不能处理高并发的情况。

多路复用连接处理模型

在该模型下，只有一个app进程来处理内核进程事务，且app进程一次只能处理一个内核进程事务。故这种模型对于内核进程来说，存在对app进程的竞争。
在前面的“多进程/多线程连接处理模型”中讲过，app进程只要被创建了就会执行内核进程事务。那么在该模型下，应用程序进程应该执行哪个内核进程事务呢？谁的准备就绪了，app进程就执行哪个。但app进程怎么知道哪个内核进程就绪了呢？需要通过多路复用器来获取各个内核进程的状态信息。那么多路复用器又是怎么获取到内核进程的状态信息的呢？不同的多路复用器，其算法不同。常见的有三种：select、poll与epoll。
app进程在进行IO时，其采用的是NIO通讯方式，即该app进程不会阻塞，当一个IO结果返回时，app进程会暂停当前事务，将IO结果返回给对应的内核进程。然后再继续执行暂停的线程。

多路复用器工作原理

select

select多路复用器是采用轮询方式，一直在轮询所有的相关内核进程，查看他们的进程状态。若已经就绪，则马上将该内核进程放入到就绪队列。否则，继续查看下一个内核进程状态。在处理内核进程事务之前，app进程首先会从内核空间中将用户连接请求相关数据复制到用户空间。
缺陷：
1.对所有内核进程采用轮询方式效率会很低。因为对于大多数情况下，内核进程都不属于就绪状态，只有少部分才会是就绪态。所以这种轮询结果大多数是毫无意义的。
2.由于就绪队列底层由数组实现，所以其所能处理的内核进程数量是由限制的，即其能够处理的最大并发连接数是有限制的。
3.从内核空间到用户空间的复制，系统开销大。

poll

poll工作原理与select几乎相同，不同的是由于其就绪队列由链表实现，所以其对于要处理的内核进程数量理论上是没有限制的，即其能够处理的最大并发连接数是没有限制的（要受制于当前系统中进程可以打开的最大文件描述符数ulimit）。

epoll

epoll采用回调方式实现对内核进程状态的获取，一旦内核进程就绪，其就会回调epoll多路复用器，进入到多路复用器的就绪队列（由链表实现），所以epoll多路复用模型也称为epoll事件驱动模型。
应用程序所使用的数据不再从内核空间复制到用户空间了，而是使用mmap零拷贝机制，大大降低了系统开销。
当内核进程就绪信息通知了epoll多路复用器后，多路复用器就会马上对其进行处理，将其马上存放到就绪队列了吗？不是的，根据处理方式的不同，可以分为两种处理模式：LT模式与ET模式。

LT模式

LT，Level Triggered，水平触发模式。只要内核进程的就绪通知由于某种原因暂时没有被epoll处理，则该内核进程就会定时将其就绪信息通知epoll，直到epoll将其写入到就绪队列，或由于某种原因该内核进程又不再就绪而不再通知，其支持两种通讯方式：BIO与NIO。

ET模式

ET，Edge Triggered，边缘触发模式，仅支持NIO通讯方式。
内核进程的就绪信息仅会通知一次epoll，无论epoll是否处理该通知。明显该方式的效率要高于LT模式，但其有可能会出现就绪通知被忽视的情况，即连接请求丢失的情况。