为什么需求I/O多路复用

TCP Socket只能实现一对一的通信，它采纳了同步堵塞的办法。它有着一个很大的缺陷：当服务端在还没处理完一个客户端的网络 I/O 时，或许读写操作产生堵塞时，其他客户端是无法与服务端衔接的。（下图是TCP协议的Socket 程序的调用过程）

I/O多路复用的三种实现
这样就意味着，不采纳什么特别的办法的话，一个服务器就仅仅只能服务一个客户。这样的话就太浪费资源了，所以咱们就需求改善这种网络I/O模型，让服务器能够一起支持更多的客户端。

IO多路复用是为了高效实现服务更多的用户。在正式解说IO多路复用前，先来讲一下，假设没有IO多路复用，咱们能够怎么做到服务更多的用户。

咱们很简单想到，在一个恳求过来的时分，就创立一个线程来处理恳求。那这样又有什么问题呢？

假设运用了线程池，能处理的衔接数便是线程池的线程数量，这样仍是太过于浪费资源且低效。假设不用线程池呢？衔接数量上来之后，可能会导致程序直接崩溃或许上下文切换的开销太大导致程序运行效率很低。这样也是太过于浪费资源并且低效。

I/O多路复用

已然为每个恳求分配一个线程的办法并不合理，那有没有可能只运用一个线程来保护多个Socket呢？答案是有的，便是I/O多路复用技能。

I/O多路复用的三种实现

这种形式下，一个进程尽管任一时刻只能处理一个恳求。可是，假设处理每个恳求的时刻耗时控制在 1 毫秒以内，这样 1 秒内就能够处理上千个恳求。把时刻拉长来看，多个恳求复用了一个进程，这便是多路复用，所以也叫做时分多路复用。

Linux操作体系给咱们提供了 select/poll/epoll 内核提供给用户态的多路复用体系调用，进程能够经过一个体系调用函数从内核中获取多个事情。

select/poll/epoll 是怎么获取网络事情的呢？在获取事情时，先把一切衔接（文件描述符）传给内核，再由内核回来产生了事情的衔接，然后在用户态中再处理这些衔接对应的恳求即可。

select/poll

select 实现多路复用的办法是，将已衔接的 Socket 都放到一个文件描述符调集，然后调用 select 函数将文件描述符调集复制到内核里，让内核来查看是否有网络事情产生。查看的办法很粗暴，便是经过遍历的办法，当查看到有事情产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符调集复制回用户态里，然后用户态再经过遍历的办法找到可读或可写的 Socket，然后再对其处理。

咱们来总结一下select这种办法需求多少次遍历和多少次复制。select需求进行2次遍历文件描述符调集，一次是在内核态里（将有事情产生的 Socket 标记为可读或可写），一次是在用户态里（取出可读或可写的 Socket ）。需求进行2次复制文件描述符调集，先从用户空间传入内核空间，由内核修改后，再传回用户空间。

select的缺陷是存文件操作符调集的是一个固定长度的BitsMap，默认大小为1024，也就意味着最多只能监听1024个文件描述符。

poll运用了动态数组，用链表进行安排，突破了能放入的文件操作符个数约束。可是 poll和select并没有太大的本质区别，都是运用「线性结构」存储进程重视的 Socket 调集，因而都需求遍历文件描述符调集来找到可读或可写的 Socket，并且也需求在用户态与内核态之间复制整个文件描述符调集。这种办法的I/O多路复用，不适合太大规划的并发量，由于随着并发量上来。性能会越来越差。

epoll

先来一段伪代码讲述一下应用程序代码中epoll怎么运用

int s = socket(...); // 创立一个socket
bind(s, ...);
listen(s, ...);
int epfd = epoll_create(...); // 创立一个epoll实例
epoll_ctl(epfd, ...); // 将一切需求监听的socket添加到epfd中
while(1) {
    int n = epoll_wait(...);
    for(接收到数据的socket){
        handle(...) // 处理操作的函数
    }
}

先用epoll_create 创立一个 epoll实例，再经过 epoll_ctl 将需求监督的 socket 添加到epoll实例中，最终调用 epoll_wait 等待数据，最终进行处理，处理完后再重新进入等待。

那epoll是怎么处理select/poll中遍历的数量多，复制的数量多这两个问题呢？

  1. epoll在内核中运用了红黑树跟踪一切待检测的文件描述符。红黑树是一种优秀的数据结构。一般来说，它的增删改的时刻复杂度为O(logn)。当需求添加一个新的需求检测的socket时，仅需求调用epoll_ctl这个函数，即可仅将需求检测的文件描述符传入内核，不用传递整个线性表。这无疑大大减少了数据复制的数量。
  2. epoll 运用事情驱动的机制，内核里保护了一个链表来记录安排妥当事情，当某个 socket 有事情产生时，内核会调用回调函数将其加入到这个安排妥当事情列表中，当用户调用 epoll_wait() 函数时，只回来有事情产生的文件描述符的个数。这种机制，使得epoll不需求轮询扫描整个 socket 调集，大大提高了效率。

I/O多路复用的三种实现

epoll这种I/O多路复用的办法随着监听的socket变多，效率也不会大幅度降低。所以epoll常被咱们在需求I/O多路复用的场景中运用。

边际触发和水平触发

epoll支持两种事情触发，分别是边际触发和水平触发。

  • 运用边际触发形式，当被监控的socket有可读事情产生时，服务器端只会从epoll_wait中复苏一次，即使是进程没有读取数据，它也仅仅复苏这一次。因而用这个形式时，有必要确保一次性将内核缓冲区数据全部读取完。
  • 运用水平触发形式，当被监控的socket有可读事情产生时，服务器端不断地从epoll_wait复苏，直到内核缓冲区被读完才完毕。这样能确保让咱们知道有哪些数据需求读取。

说一句题外话，Java中的NIO运用的是水平触发形式的epoll。

运用epoll时，最好运用非堵塞I/O（这似乎是在Linux手册中提到的）。在Java中，假设selector中的socketChannel不对错堵塞I/O时，会直接抛反常。

希望我的文章对你有所协助。