黑马程序员技术交流社区

标题: 【成都校区】io模型 [打印本页]

作者: 小刀葛小伦    时间: 2019-8-22 17:24
标题: 【成都校区】io模型
前言
说到IO模型,都会牵扯到同步、异步、阻塞、非阻塞这几个词。从词的表面上看,很多人都觉得很容易理解。但是细细一想,却总会发现有点摸不着头脑。自己也曾被这几个词弄的迷迷糊糊的,每次看相关资料弄明白了,然后很快又给搞混了。经历过这么几次之后,发现这东西必须得有所总结提炼才不至于再次混为一谈。尤其是最近看到好几篇讲这个的文章,很多都有谬误,很容易把本来就搞不清楚的人弄的更加迷糊。
最适合IO模型的例子应该是咱们平常生活中的去餐馆吃饭这个场景,下文就结合这个来讲解一下经典的几个IO模型。在此之前,先需要说明以下几点:

IO模型同步阻塞
去餐馆吃饭,点一个自己最爱吃的盖浇饭,然后在原地等着一直到盖浇饭做好,自己端到餐桌就餐。这就是典型的同步阻塞。当厨师给你做饭的时候,你需要一直在那里等着。
网络编程中,读取客户端的数据需要调用recvfrom。在默认情况下,这个调用会一直阻塞直到数据接收完毕,就是一个同步阻塞的IO方式。这也是最简单的IO模型,在通常fd较少、就绪很快的情况下使用是没有问题的。
同步非阻塞
接着上面的例子,你每次点完饭就在那里等着,突然有一天你发现自己真傻。于是,你点完之后,就回桌子那里坐着,然后估计差不多了,就问老板饭好了没,如果好了就去端,没好的话就等一会再去问,依次循环直到饭做好。这就是同步非阻塞。
这种方式在编程中对socket设置O_NONBLOCK即可。但此方式仅仅针对网络IO有效,对磁盘IO并没有作用。因为本地文件IO就没有被认为是阻塞,我们所说的网络IO的阻塞是因为网路IO有无限阻塞的可能,而本地文件除非是被锁住,否则是不可能无限阻塞的,因此只有锁这种情况下,O_NONBLOCK才会有作用。而且,磁盘IO时要么数据在内核缓冲区中直接可以返回,要么需要调用物理设备去读取,这时候进程的其他工作都需要等待。因此,后续的IO复用和信号驱动IO对文件IO也是没有意义的。
此外,需要说明的一点是nginx和node中对于本地文件的IO是用线程的方式模拟非阻塞的效果的,而对于静态文件的io,使用zero copy(例如sendfile)的效率是非常高的。
IO复用
接着上面的列子,你点一份饭然后循环的去问好没好显然有点得不偿失,还不如就等在那里直到准备好,但是当你点了好几样饭菜的时候,你每次都去问一下所有饭菜的状态(未做好/已做好)肯定比你每次阻塞在那里等着好多了。当然,你问的时候是需要阻塞的,一直到有准备好的饭菜或者你等的不耐烦(超时)。这就引出了IO复用,也叫多路IO就绪通知。这是一种进程预先告知内核的能力,让内核发现进程指定的一个或多个IO条件就绪了,就通知进程。使得一个进程能在一连串的事件上等待。
IO复用的实现方式目前主要有select、poll和epoll。
select和poll的原理基本相同:
相比select,poll解决了单个进程能够打开的文件描述符数量有限制这个问题:select受限于FD_SIZE的限制,如果修改则需要修改这个宏重新编译内核;而poll通过一个pollfd数组向内核传递需要关注的事件,避开了文件描述符数量限制。
此外,select和poll共同具有的一个很大的缺点就是包含大量fd的数组被整体复制于用户态和内核态地址空间之间,开销会随着fd数量增多而线性增大。
select和poll就类似于上面说的就餐方式。但当你每次都去询问时,老板会把所有你点的饭菜都轮询一遍再告诉你情况,当大量饭菜很长时间都不能准备好的情况下是很低效的。于是,老板有些不耐烦了,就让厨师每做好一个菜就通知他。这样每次你再去问的时候,他会直接把已经准备好的菜告诉你,你再去端。这就是事件驱动IO就绪通知的方式-epoll。
epoll的出现,解决了select、poll的缺点:
目前,epoll是Linux2.6下最高效的IO复用方式,也是Nginx、Node的IO实现方式。而在freeBSD下,kqueue是另一种类似于epoll的IO复用方式。
此外,对于IO复用还有一个水平触发和边缘触发的概念:
信号驱动
上文的就餐方式还是需要你每次都去问一下饭菜状况。于是,你再次不耐烦了,就跟老板说,哪个饭菜好了就通知我一声吧。然后就自己坐在桌子那里干自己的事情。更甚者,你可以把手机号留给老板,自己出门,等饭菜好了直接发条短信给你。这就类似信号驱动的IO模型。
流程如下:
此种io方式存在的一个很大的问题:Linux中信号队列是有限制的,如果超过这个数字问题就无法读取数据。
异步非阻塞
之前的就餐方式,到最后总是需要你自己去把饭菜端到餐桌。这下你也不耐烦了,于是就告诉老板,能不能饭好了直接端到你的面前或者送到你的家里(外卖)。这就是异步非阻塞IO了。
对比信号驱动IO,异步IO的主要区别在于:信号驱动由内核告诉我们何时可以开始一个IO操作(数据在内核缓冲区中),而异步IO则由内核通知IO操作何时已经完成(数据已经在用户空间中)。
异步IO又叫做事件驱动IO,在Unix中,POSIX1003.1标准为异步方式访问文件定义了一套库函数,定义了AIO的一系列接口。使用aio_read或者aio_write发起异步IO操作,使用aio_error检查正在运行的IO操作的状态。但是其实现没有通过内核而是使用了多线程阻塞。此外,还有Linux自己实现的Native AIO,依赖两个函数:io_submit和io_getevents,虽然io是非阻塞的,但仍需要主动去获取读写的状态。
需要特别注意的是:AIO是I/O处理模式,是一种接口标准,各家操作系统可以实现也可以不实现。目前Linux中AIO的内核实现只对文件IO有效,如果要实现真正的AIO,需要用户自己来实现。
网络编程模型
上文讲述了UNIX环境的五种IO模型。基于这五种模型,在Java中,随着NIO和NIO2.0(AIO)的引入,一般具有以下几种网络编程模型:
BIO
BIO是一个典型的网络编程模型,是通常我们实现一个服务端程序的过程,步骤如下:
这种模型有一个很大的问题是:当客户端连接增多时,服务端创建的线程也会暴涨,系统性能会急剧下降。因此,在此模型的基础上,类似于 tomcat的bio connector,采用的是线程池来避免对于每一个客户端都创建一个线程。有些地方把这种方式叫做伪异步IO(把请求抛到线程池中异步等待处理)。
NIO
JDK1.4开始引入了NIO类库,这里的NIO指的是Non-blcok IO,主要是使用Selector多路复用器来实现。Selector在Linux等主流操作系统上是通过epoll实现的。
NIO的实现流程,类似于select:
相比BIO,NIO的编程非常复杂。
AIO
JDK1.7引入NIO2.0,提供了异步文件通道和异步套接字通道的实现。其底层在windows上是通过IOCP,在Linux上是通过epoll来实现的(LinuxAsynchronousChannelProvider.java,UnixAsynchronousServerSocketChannelImpl.java)。
其编程模型相比NIO有了不少的简化。
对比
.同步阻塞IO伪异步IONIOAIO
客户端数目 :IO线程1 : 1m : nm : 1m : 0
IO模型同步阻塞IO同步阻塞IO同步非阻塞IO异步非阻塞IO
吞吐量低中高高
编程复杂度简单简单非常复杂复杂

本文转至https://www.cnblogs.com/javalyy/p/8882066.html




欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) 黑马程序员IT技术论坛 X3.2