IO模型主要包括以下几种：
- 同步阻塞IO
- 同步非阻塞IO
- IO多路复用
- 异步IO
Blocking IO
是指用户空间主动发起的，需要等到内核IO完成之后，才能返回用户空间的IO，用户进程一直处于阻塞状态，即调用没有立即的返回值。
同步非阻塞IO
（NO-Blocking IO）用户主动发起，不需要等待内核IO完成，就能立刻返回用户空间的IO操作。IO在用户进程中是非阻塞状态的。需要不断的调用轮询函数，访问内核的数据报是否准备好。
IO多路复用
（IO Multiplexing）对于整个应用程序中所有IO事件是否发生的一种监视, 多路IO地理解, 就是可以同时监视多个文件地IO事件地发生, 复用就是复用主线程或者说是一个进程, 也就是在一个进程中处理多个IO事件。
轮询式的解决方案：
select和poll的本质都是一次并发处理多个IO事件，但是IO事件的解决上还是采取的轮询遍历对应的 fds集合的方式进行的处理, 因为轮询, 所以效率上不算很好, O(n)…看似是一次解决了多个IO事件, 其实本质上不过是在一段时间内轮询处理了多个IO事件, 之所以我们看起来像是同时并行处理似的, 是因为处理时间及短, 所以看起来就像同时处理一样。
中断式的解决方案：
epoll采取提前注册监视事件的方式, 不需要再进行轮询，来了IO事件就会提示，执行相应的处理。
-
poll对比select不再使用BitMap来存储关注的文件描述符事件了,
-
pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式. 接口使用比 select更方便.
-
poll并没有最大数量限制(相较select打破了文件描述符个数上的限制) (但是数量过大后性能也是会下降, 所以在fd数目很大的情况下也不适合).
-
poll 没有最大数量, 不像select的 fd_set在一开始是设定好了,上限1024个最多. poll上线取决于pollfd结构体数组的大小, 我们可以使用动态数组或者从堆区new一个足够大的数组
-
epoll在内核里面使用了红黑树来监视所有待检测的文件描述符, 把需要监视的socket全部通过epoll_ctl函数加到红黑树中,而且这个红黑树是处在内核中的, 所有避免了每一次调用返回IO触发事件的时候的拷贝, 向select 和 poll就需要将需要监视的事件拷贝进入内核, 而且是每一次都需要拷贝, 这个代价还是比较大
-
内核中监视IO事件使用红黑树存储,增删改查 的效率都远远的超过了线性结构…select和poll都是使用的线性结构, 遍历轮询IO事件效率低
-
epoll使用的是事件驱动机制, 内核中维护一个就绪链表存储就绪事件,当用户调用epoll_wait的时候直接返回有IO事件发生的描述符个数就是了, 链表中的就绪事件通过我们传入的 struct epoll_event数组直接拿出, 有了这个就绪链表还避免了内核的轮询查找发生了IO的事件.
异步IO
用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。用异步IO实现的服务器这里就不举例了，以后有时间另开文章来讲述。异步IO是真正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器实现至关重要。