阻塞和非阻塞IO模型
操作系统在处理io的时候，主要有两个阶段：
1.等待数据传到io设备
2.io设备将数据复制到user space
我们一般将上述过程简化理解为：
1.等到数据传到kernel内核space
2.kernel内核区域将数据复制到user space（理解为进程或者线程的缓冲区）
阻塞 io 模型 blocking IO
最常用的也就是阻塞io模型。默认情况下，所有文件操作都是阻塞的。我们以套接字接口为例来讲解此模型，在进程空间调用recvfrom，其系统调用知道数据包到达并且被复制到进程缓冲中或者发生错误时才会返回，在此期间会一直阻塞，所以进程在调用recvfrom开始到它返回的整段时间都是阻塞的，因此称之为阻塞io模型。
应用层有数据过来，会调用recvfrom方法，但是这个时候应用层的数据还没复制到kernel中，将应用层数据复制到kerne这个阶段是需要时间的，所以recvfrom方法会阻塞，当内核中的数据准备好之后，recvfrom方法还不会返回，而是会发起一个系统调用将kernel中的数据复制到进程的缓冲区中，也就是user space，当这个工作完成之后，recvfrom才会返回并解除程序的阻塞。因此，阻塞io模型就是将这个两个过程合并在一起，一起阻塞。
非阻塞 io 模型 nonblocking IO
非阻塞模型则是将第一个过程的阻塞变成非阻塞，第二个阶段是系统调用，是必须阻塞的，所以非阻塞模型也是同步的，因为它们在kernel里的数据准备好之后，进行系统调用，将数据拷贝到进程缓冲区中。对于第一个阶段，也就是应用层数据到kernel的过程中，recvfrom会轮询检查，如果kernel数据没有准备还，就返回一个EWOULDBLOCK错误。不断的轮询检查，直到发现kernel中的数据准备好了，就返回，然后进行系统调用，将数据从kernel拷贝到进程缓冲区中。
IO多路复用模型
**目的：**因为阻塞模型在没有收到数据的时候就会阻塞卡住，如果一次需要接受多个socket fd的时候，就会导致必须处理完前面的fd，才能处理后面的fd，即使可能后面的fd比前面的fd还要先准备好，所以这样就会造成客户端的严重延迟。为了处理多个请求，我们自然先想到用多线程来处理多个socket fd，但是这样又会启动大量的线程，造成资源的浪费，所以这个时候就出现了io多路复用技术。就是用一个进程来处理多个fd的请求。
**应用：**适用于针对大量的io请求的情况，对于服务器必须在同时处理来自客户端的大量的io操作的时候，就非常适合
select和poll
select和poll的工作流程类似：
单个进程就可以同时处理多个网络连接的io请求（同时阻塞多个io操作）。基本原理就是程序呼叫select，然后整个程序就阻塞了，这时候，kernel就会轮询检查所有select负责的fd，当找到一个client中的数据准备好了，select就会返回，这个时候程序就会系统调用，将数据从kernel复制到进程缓冲区。
下图为select同时从多个客户端接受数据的过程
虽然服务器进程会被select阻塞，但是select会利用内核不断轮询监听其他客户端的io操作是否完成。
poll的原理与select非常相似，差别如下：
描述fd集合的方式不同，poll使用 pollfd 结构而不是select结构fd_set结构，所以poll是链式的，没有最大连接数的限制
poll有一个特点是水平触发，也就是通知程序fd就绪后，这次没有被处理，那么下次poll的时候会再次通知同个fd已经就绪。
select的缺点：
1、单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)
2、内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3、select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4、select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。
相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。
拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
epoll
由于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万个连接的句柄数据，内核也不需要去遍历全部的连接。
IO多路复用模型应用场景
Netty
Redis
