编程问答
os / 5 种 io 模型 -凯发ag旗舰厅登录网址下载
零、从 tcp 发送数据的流程说起
要深入的理解各种 io 模型，那么必须先了解下产生各种 io 的原因是什么，要知道这其中的本质问题那么我们就必须要知一条消息是如何从过一个人发送到另外一个人的；
以两个应用程序通讯为例，我们来了解一下当“a”向"b" 发送一条消息，简单来说会经过如下流程：
第一步：应用 a 把消息发送到 tcp 发送缓冲区。
第二步： tcp 发送缓冲区再把消息发送出去，经过网络传递后，消息会发送到 b 服务器的 tcp 接收缓冲区。
第三步：b 再从 tcp 接收缓冲区去读取属于自己的数据。
根据上图我们基本上了解消息发送要经过应用 a、应用 a 对应服务器的 tcp 发送缓冲区、经过网络传输后消息发送到了应用 b 对应服务器 tcp 接收缓冲区、然后最终 b 应用读取到消息。
如果理解了上面的消息发送流程，那么我们下面开始进入文章的主题；
一、阻塞 io | 非阻塞 io
我们把视角切换到上面图中的第三步， 也就是应用 b 从 tcp 缓冲区中读取数据。
思考一个问题：
因为应用之间发送消息是间断性的，也就是说在上图中 tcp 缓冲区还没有接收到属于应用 b 该读取的消息时，那么此时应用 b 向 tcp 缓冲区发起读取申请，tcp 接收缓冲区是应该马上告诉应用 b 现在没有你的数据，还是说让应用 b 在这里等着，直到有数据再把数据交给应用 b 。
把这个问题应用到第一个步骤也是一样，应用 a 在向 tcp 发送缓冲区发送数据时，如果 tcp 发送缓冲区已经满了，那么是告诉应用 a 现在没空间了，还是让应用 a 等待着，等 tcp 发送缓冲区有空间了再把应用 a 的数据访拷贝到发送缓冲区。
什么是阻塞 io
如果上面的问题你已经思考过了，那么其实你已经明白了什么是阻塞 io 了，所谓阻塞 io 就是当应用 b 发起读取数据申请时，在内核数据没有准备好之前，应用 b 会一直处于等待数据状态，直到内核把数据准备好了交给应用b才结束。
术语描述：在应用调用 recvfrom 读取数据时，其系统调用知道数据包到达切被复制到应用缓冲区中或者发送错误时才返回，在此期间一直会等待，进程从调用到返回这段时间内都是被阻塞的成为阻塞 io。
流程：
什么是非阻塞 io
我敢保证如果你已经理解了阻塞 io，那么必定已经知道了什么是非阻塞 io。按照上面的思路，所谓非阻塞 io 就是当应用 b 发起读取数据申请时，如果内核数据没有准备好会即刻告诉应用 b，不会让 b 在这里等待。
术语：非阻塞 io 是在应用调用 recvfrom 读取数据时，如果该缓冲区没有数据的话，就会直接返回一个 ewouldblock 错误，不会让应用一直等待中。在没有数据的时候会即刻返回错误标识，那也意味着如果应用要读取数据就需要不断的调用 recvfrom 请求，直到读取到它数据要的数据为止。
流程：
二、io 复用模型
如果你已经明白了非阻塞 io 的工作模式，那么接下来我们继续了解 io 复用模型的产生原因和思路。
思考一个问题：
我们还是把视角放到应用 b 从 tcp 缓冲区中读取数据这个环节来。如果在并发的环境下，可能会 n 个人向应用 b 发送消息，这种情况下我们的应用就必须创建多个线程去读取数据，每个线程都会自己调用recvfrom 去读取数据。那么此时情况可能如下图：
如上图一样，并发情况下服务器很可能一瞬间会收到几十上百万的请求，这种情况下应用 b 就需要创建几十上百万的线程去读取数据，同时又因为应用线程是不知道什么时候会有数据读取，为了保证消息能及时读取到，那么这些线程自己必须不断的向内核发送 recvfrom 请求来读取数据；
那么问题来了，这么多的线程不断调用 recvfrom 请求数据，先不说服务器能不能扛得住这么多线程，就算扛得住那么很明显这种方式是不是太浪费资源了，线程是我们操作系统的宝贵资源，大量的线程用来去读取数据了，那么就意味着能做其它事情的线程就会少。
所以，有人就提出了一个思路，能不能提供一种方式，可以由一个线程监控多个网络请求（我们后面将称为 fd 文件描述符，linux 系统把所有网络请求以一个 fd 来标识），这样就可以只需要一个或几个线程就可以完成数据状态询问的操作，当有数据准备就绪之后再分配对应的线程去读取数据，这么做就可以节省出大量的线程资源出来，这个就是 io 复用模型的思路。
正如上图，io 复用模型的思路就是系统提供了一种函数可以同时监控多个 fd 的操作，这个函数就是我们常说到的 select、poll、epoll 函数，有了这个函数后，应用线程通过调用 select 函数就可以同时监控多个 fd，select 函数监控的 fd 中只要有任何一个数据状态准备就绪了，select 函数就会返回可读状态，这时询问线程再去通知处理数据的线程，对应线程此时再发起 recvfrom 请求去读取数据。
术语描述：进程通过将一个或多个 fd 传递给select，阻塞在 select 操作上，select 帮我们侦测多个 fd 是否准备就绪，当有 fd 准备就绪时，select 返回数据可读状态，应用程序再调用 recvfrom 读取数据。
总结：复用io的基本思路就是通过 select 或 poll、epoll 来监控多 fd ，来达到不必为每个fd创建一个对应的监控线程，从而减少线程资源创建的目的。
三、信号驱动 io 模型
复用 io 模型解决了一个线程可以监控多个 fd 的问题，但是 select 是采用轮询的方式来监控多个 fd 的，通过不断的轮询 fd 的可读状态来知道是否就可读的数据，而无脑的轮询就显得有点暴力，因为大部分情况下的轮询都是无效的，所以有人就想，能不能不要我总是去问你是否数据准备就绪，能不能我发出请求后等你数据准备好了就通知我，所以就衍生了信号驱动 io 模型。
于是信号驱动 io 不是用循环请求询问的方式去监控数据就绪状态，而是在调用 sigaction 时候建立一个 sigio 的信号联系，当内核数据准备好之后再通过 sigio 信号通知线程数据准备好后的可读状态，当线程收到可读状态的信号后，此时再向内核发起 recvfrom 读取数据的请求，因为信号驱动 io 的模型下应用线程在发出信号监控后即可返回，不会阻塞，所以这样的方式下，一个应用线程也可以同时监控多个fd。
类似于下图描述：
术语描述：首先开启套接口信号驱动 io 功能，并通过系统调用 sigaction 执行一个信号处理函数，此时请求即刻返回，当数据准备就绪时，就生成对应进程的 sigio 信号，通过信号回调通知应用线程调用recvfrom 来读取数据。
总结： io 复用模型里面的 select 虽然可以监控多个 fd 了，但 select 其实现的本质上还是通过不断的轮询 fd 来监控数据状态， 因为大部分轮询请求其实都是无效的，所以信号驱动 io 意在通过这种建立信号关联的方式，实现了发出请求后只需要等待数据就绪的通知即可，这样就可以避免大量无效的数据状态轮询操作。
四、异步 io
其实经过了上面两个模型的优化，我们的效率有了很大的提升，但是我们当然不会就这样满足了，有没有更好的办法，通过观察我们发现，不管是 io 复用还是信号驱动，我们要读取一个数据总是要发起两阶段的请求，第一次发送 select 请求，询问数据状态是否准备好，第二次发送 recevform 请求读取数据。
思考一个问题：
也许你一开始就有一个疑问，为什么我们明明是想读取数据，什么非得要先发起一个 select 询问数据状态的请求，然后再发起真正的读取数据请求，能不能有一种一劳永逸的方式，我只要发送一个请求我告诉内核我要读取数据，然后我就什么都不管了，然后内核去帮我去完成剩下的所有事情？
当然既然你想得出来，那么就会有人做得到，有人设计了一种方案，应用只需要向内核发送一个 read 请求，告诉内核它要读取数据后即刻返回；内核收到请求后会建立一个信号联系，当数据准备就绪，内核会主动把数据从内核复制到用户空间，等所有操作都完成之后，内核会发起一个通知告诉应用，我们称这种一劳永逸的模式为异步io模型。
术语描述： 应用告知内核启动某个操作，并让内核在整个操作完成之后，通知应用，这种模型与信号驱动模型的主要区别在于，信号驱动 io 只是由内核通知我们合适可以开始下一个 io 操作，而异步 io 模型是由内核通知我们操作什么时候完成。
总结：异步 io 的优化思路是解决了应用程序需要先后发送询问请求、发送接收数据请求两个阶段的模式，在异步 io 的模式下，只需要向内核发送一次请求就可以完成状态询问和数拷贝的所有操作。
再谈 io 模型里面的同步异步
我们通常会说到同步阻塞 io、同步非阻塞 io，异步 io 几种术语，通过上面的内容，那么我想你现在肯定已经理解了什么是阻塞什么是非阻塞了，所谓阻塞就是发起读取数据请求的时，当数据还没准备就绪的时候，这时请求是即刻返回，还是在这里等待数据的就绪，如果需要等待的话就是阻塞，反之如果即刻返回就是非阻塞。
我们区分了阻塞和非阻塞后再来分别下同步和异步，在 io 模型里面如果请求方从发起请求到数据最后完成的这一段过程中都需要自己参与，那么这种我们称为同步请求；反之，如果应用发送完指令后就不再参与过程了，只需要等待最终完成结果的通知，那么这就属于异步。
我们再看同步阻塞、同步非阻塞，他们不同的只是发起读取请求的时候一个请求阻塞，一个请求不阻塞，但是相同的是，他们都需要应用自己监控整个数据完成的过程。而为什么之后异步非阻塞而没有异步阻塞呢，因为异步模型下请求指定发送完后就即刻返回了，没有任何后续流程了，所以它注定不会阻塞，所以也就只会有异步非阻塞模型了。
转载于：https://zhuanlan.zhihu.com/p/115912936
（saw：game over！）
总结
以上是凯发ag旗舰厅登录网址下载为你收集整理的os / 5 种 io 模型的全部内容，希望文章能够帮你解决所遇到的问题。
如果觉得凯发ag旗舰厅登录网址下载网站内容还不错，欢迎将凯发ag旗舰厅登录网址下载推荐给好友。
- 上一篇：
- 下一篇： 数据库 / 各种锁