Linux下主要的IO主要分为：阻塞IO(Blocking IO)，非阻塞IO(Non-blocking IO)，同步IO(Sync IO)和异步IO(Async IO)。 同步：调用端会一直等待服务端响应，直到返回结果。 异步：调用端发起调用之后不会立刻返回，不会等待服务端响应。服务端通过通知机制或者回调函数来通知客户端。 阻塞：服务端返回结果之前，客户端线程会被挂起，此时线程不可被cpu调度，线程暂停运行。 非阻塞：在服务端返回前，函数不会阻塞调用端线程，而会立刻返回。
同步异步的区别在于：服务端在拷贝数据时是否阻塞调用端线程；阻塞和非阻塞的区别在于：调用端线程在调用function后是否立刻返回。要理解这些I/O，需要先理解一些基本的概念。
用户态和核心态
Linux系统中分为核心态(Kernel model)和用户态(User model)，cpu会在两个model之间切换。
用户态和核心态的切换
用户态切换到核心态有三种方式：
a.系统调用 这是用户态进程主动要求切换到内核态的一种方式，用户态进程通过系统调用申请使用操作系统提供的服务程序完成工作，比如前例中fork()实际上就是执行了一个创建新进程的系统调用。而系统调用的机制其核心还是使用了操作系统为用户特别开放的一个中断来实现，例如Linux的int 80h中断。
b.异常 当cpu在执行运行在用户态下的程序时，发生了某些事先不可知的异常，这时会触发由当前运行进程切换到处理此异常的内核相关程序中，也就转到了内核态，比如缺页异常。
c.外围设备的中断 当外围设备完成用户请求的操作后，会向cpu发出相应的中断信号，这时cpu会暂停执行下一条即将要执行的指令转而去执行与中断信号对应的处理程序，如果先前执行的指令是用户态下的程序，那么这个转换的过程自然也就发生了由用户态到内核态的切换。比如硬盘读写操作完成，系统会切换到硬盘读写的中断处理程序中执行后续操作等。
进程切换
为了控制进程的执行，内核必须有能力挂起正在cpu上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：
进程阻塞
正在执行的进程由于一些事情发生，如请求资源失败、等待某种操作完成、新数据尚未达到或者没有新工作做等，由系统自动执行阻塞原语，使进程状态变为阻塞状态。因此，进程阻塞是进程自身的一种主动行为，只有处于运行中的进程才可以将自身转化为阻塞状态。当进程被阻塞，它是不占用cpu资源的。
文件描述符(fd,File Descriptor)
FD用于描述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。
缓存I/O
缓存IO又被称作标准IO，大多数文件系统的默认IO 操作都是缓存IO。在Linux的缓存IO 机制中，操作系统会将 IO 的数据缓存在文件系统的页缓存（ page cache ）中，也就是说，数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。
缓存I/O的缺点
数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 cpu 以及内存开销是非常大的。
事件驱动模型
事件驱动模型是一种编程范式，也就是编程思想。这种思想会在我们以后经常性的用到，它与传统编程思想最大不同的地方在于他是一种非线性的模式。
这个有点不好解释，我们来看一个例子。
我们用最常见的网页浏览做一个引子，任何的UI编程都是基于事件驱动模型来完成的，当我们的鼠标放在任何一段文字之上，它会根据文字不同而做出对应的不同反应。
并且，我们进入一个网页不仅仅可以用鼠标与网页产生交互，也可以使用键盘与网页产生交互，那么这里就会有很多很多种不同的选择，如果想尝试用传统的编程思想来解决识别用户的操作无疑效率是非常低下的。
传统编程思想解决方案：
1.死循环来不断的检测是否有鼠标点击，键盘按下，鼠标悬浮等等操作。
这种解决方案看似十分完美，但实际上是非常不明智的，它的缺点如下：
1.死循环占用大量cpu资源，并且如果需要检测的事件太多势必会引发延迟问题。
2.通过阻塞方式只能检测一种操作，并不能同时检测多种操作。
那么到底有什么方案能够完美的解决这些问题呢？我们看看UI编程的事件驱动模型的是怎么解决这些问题的：
1. 有一个事件(消息)队列，包括但不仅是鼠标事件，键盘事件，悬浮事件等等。
2. 假设当鼠标按下，便往这个队列中增加一个点击事件(消息)。
事件驱动模型图解：
所以说事件驱动的一大特点就是：
包含一个事件循环并且只有当外部事件发生时才使用回调机制来触发相应的处理。也就是说程序运行的整个流程都是取决于用户触发的各种事件来决定的，开发者并不用关心大体流程，而只是需要做好每一个事件对应的处理方式即可。
Linux下的五种I/O模型
Linux下主要有以下五种I/O模型：
-
阻塞I/O（blocking IO）
阻塞IO模型
进程会一直阻塞，直到数据拷贝完成 应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。数据准备好后，从内核拷贝到用户空间，IO函数返回成功指示。阻塞IO模型图
非阻塞IO模型
通过进程反复调用IO函数，在数据拷贝过程中，进程是阻塞的。模型图如下所示:
IO复用模型
主要是select和epoll。一个线程可以对多个IO端口进行监听，当socket有读写事件时分发到具体的线程进行处理。模型如下所示：
信号驱动IO模型
信号驱动式I/O：首先我们允许Socket进行信号驱动IO,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。过程如下图所示：
异步IO模型
相对于同步IO，异步IO不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。异步过程如下图所示：
五种IO模型比较
阻塞IO和非阻塞IO的区别 调用阻塞IO后进程会一直等待对应的进程完成，而非阻塞IO不会等待对应的进程完成，在kernel还在准备数据的情况下直接返回。 同步IO和异步IO的区别 首先看一下POSIX中对这两个IO的定义：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。注意到non-blocking IO会一直轮询(polling)，这个过程是没有阻塞的，但是recvfrom阶段blocking IO,non-blocking IO和IO multiplexing都是阻塞的。 而asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。
IO复用之select、poll、epoll简介
epoll是linux所特有，而select是POSIX所规定，一般操作系统均有实现。
select
select本质是通过设置或检查存放fd标志位的数据结构来进行下一步处理。缺点是：
poll
poll本质和select相同，将用户传入的数据拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或主动超时，被唤醒后又要再次遍历fd。它没有最大连接数的限制，原因是它是基于链表来存储的，但缺点是：
epoll
epoll支持水平触发和边缘触发，最大特点在于边缘触发，只告诉哪些fd刚刚变为就绪态，并且只通知一次。还有一特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一量该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。epoll的优点：
select、poll、epoll区别总结
| 支持一个进程打开连接数 | IO效率 | 消息传递方式 | |
|---|---|---|---|
| select | 32位机器1024个，64位2048个 | IO效率低 | 内核需要将消息传递到用户空间，都需要内核拷贝动作 |
| poll | 无限制，原因基于链表存储 | IO效率低 | 内核需要将消息传递到用户空间，都需要内核拷贝动作 |
| epoll | 有上限，但很大，2G内存20W左右 | 只有活跃的socket才调用callback，IO效率高 | 通过内核与用户空间共享一块内存来实现 |
扩展：水平触发与边缘触发
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
