Java IO对大多数Java程序员来说是熟悉又陌生,熟悉的是感觉到处都有它的身影,小到简单的读取文件,大到各种服务器的应用,陌生的是Java IO背后到底是一个怎样的机制,今天就让我们去了解一下这位老朋友吧。本文不讲解Java IO如何具体使用,有这方面需求的同学可以自己查下。
IO模型
要说IO,就不得不说IO模型,IO模型大家都有所了解,同步异步,阻塞非阻塞什么的,总的来说IO模型可分为以下五种:
- 阻塞IO
- 非阻塞IO
- 多路复用IO
- 信号驱动IO
- 异步IO
那么这几种IO都有什么区别呢?下面我们一一来看,每种模型我都会举一个适当的例子助于理解:
1.阻塞IO
阻塞IO相信大家都最熟悉了,线程发起一个IO请求,直到有结果返回,否则则一直阻塞等待,比如我们平常常见的阻塞数据库操作,网络IO等。
小明阻塞IO吃饭:
五年前一天周末,小明和朋友一起去商场的外婆家吃饭,到店后发现排队的人超多,所以他就领了一个号码,然后他和朋友就坐在旁边等候,一直等着服务员叫他们的号,也不能做其他事,过了一个多小时终于轮到他们了,然后他们进店点菜,又得等待上菜,最后他们吃饭总共花了两个小时;
关键部分:
- 等待座位吃饭:一直阻塞,直到有座位
- 等待上菜:一直阻塞,直到有菜(假设菜上齐了再吃)
没什么说的,反正就是一直等,反应到程序中就是一直阻塞,而一个IO请求需要一个线程,可想而知当有大量的IO请求,线程的创建和销毁,线程间的切换,线程所占用的资源等等要耗费多少时间和资源,系统的性能会有多差。
2.非阻塞IO
非阻塞IO和阻塞IO的最大区别就在于线程发起一个IO请求,不会一直堵塞直到有数据,而是不断的检查是否已有数据,若有数据则读取数据。
小明非阻塞IO吃饭:
有了第一次的教训,小明学乖了,他在拿到后不再傻傻的等着,而是去外婆家旁边逛了逛,每过3分钟他就会回来,然后跑到前台去询问服务员轮到他了吗?不幸的是,排队的人超多,直到过了半个多小时后才轮到他进店吃饭,期间他大概问了十几次,他们进店点菜,又得等待上菜,最后他们吃饭总共花了两个小时,基本也没做啥其他事;
关键部分:
- 领号后询问是否轮到他:非阻塞,非询问期间可以做点别的事,但也不做了啥大事
- 等待上菜:一直阻塞,直到有菜(假设菜上齐了再吃)
总的来说非阻塞IO的非阻塞主要体现在不需要一直等待到有数据,当然读数据那部分操作还是阻塞的,另外这种非阻塞模式需要用户线程自己不断询问检查,其实效率也不是太高,实际编程中运用的也不多。
3.多路复用IO
既然上面我们说到非阻塞IO的缺点,那么有没有什么方式改进呢?答案是当然有,那就是多路复用IO,我理解的它的特点就是复用,首先它也是一种非阻塞IO的模型,只不过上面说到轮询的方式用了不同的方式处理了,当一个线程发起IO请求,系统会将它注册到一个单独管理IO请求的一个线程,之后该IO的相关操作的通知状态都有这个管理IO请求的线程处理,Java 1.4发布的NIO就是这种模式,我们可以大致来看一下它的流程:
// 打开服务器套接字通道
ServerSocketChannel ssc = ServerSocketChannel.open();
// 服务器配置为非阻塞
ssc.configureBlocking(false);
// 进行服务的绑定
ssc.bind(new InetSocketAddress("localhost", 8008));
// 这里的selector就相当于单独管理IO请求的线程
Selector selector = Selector.open();
// 注册到selector,等待连接
ssc.register(selector, SelectionKey.OP_ACCEPT);
while (true) {
selector.select(); //为IO请求去轮询状态
Set<SelectionKey> keys = selector.selectedKeys(); //多个IO请求的状态
Iterator<SelectionKey> keyIterator = keys.iterator();
while (keyIterator.hasNext()) { //依次处理IO请求
SelectionKey key = keyIterator.next();
doThing(key)
...
}
}
可以看出Java NIO的模式就是多路复用IO模型的应用。
小明多路复用IO吃饭:
随着生意越来越好,外婆家发现好多顾客都堵在门口等待吃饭,等待区都站不下来人了,,思来想去,外婆家准备请一个人专门来维护顾客的排队请求,这样顾客取号后,就不用堵在门口了,我们叫他小A,小明这次取号后,将自己的相关信息告诉小A,并从小A那里获得了一个GPS(用于小A能快速找到小明,假设有了GPS后,小A能秒速找到小明),然后小明就跟朋友们开心的去逛商场,看看MM,买买衣服,而小A则不断的观察店里的情况,当有空座位出现的时候,他便会按照相关信息找到具体的顾客,将其带回进行用餐,但他们进店点菜,还得等待上菜,最后他们吃饭总共花了两个小时,但是他们不再需要排队等位,而是去做一些其他的事。
关键部分:
- 领号后委托给小A,小A观察到有空位后带回小明:非阻塞,领号后可以安心去做自己的事,不用担心错过
- 等待上菜:一直阻塞,直到有菜(假设菜上齐了再吃)
多路复用IO可以看成普通非阻塞IO的升级版,也是目前Java编程中用到比较多的IO模型,它的优势在于可以处理大量的IO请求,用一个线程管理所有的IO请求,无需像阻塞IO和非阻塞IO一样,每个IO需要一个线程处理,提升了系统的吞吐量。
4.信号驱动IO
信号驱动IO相对于以上几种模型最大的特点就是它支持内核信号通知,线程在发起一个IO请求后,会注册一个信号函数,然后内核在确认数据可读了,便会给相应的线程发送通知,让其进行具体IO读写操作。
小明信号驱动IO吃饭:
又了一段时间,外婆家通过使用复用IO模式缓解了排队拥挤的情况,但是觉得还要请一个人专门维护队列,感觉不划算,那么有没有一种更好的方式呢?经过一天的苦思冥想,外婆家的经理又想出一个好办法,让每个顾客在领完号后,关注一下外婆家的公众号,然后顾客就可以去做别的事了,定时或者当排队信息发生改变时给顾客发送通知,告知他现在的排队序号或者轮到他吃饭了,顾客可以根据相应的信息做相应的行为,比如快轮到了就开始往店里走(实际程序中并不一定有这种状态,这里只是大概模拟),或者轮到自己了然后进店吃饭,他们仍然不用排队等位,而是去做一些其他的事。
关键部分:
- 领号后关注公众号,注册关系:非阻塞,领号后可以安心去做自己的事,不用担心错过
- 等待上菜:一直阻塞,直到有菜(假设菜上齐了再吃)
就实际来说,信号驱动IO用的并不多,因为信号驱动IO底层是使用SIGIO信号,所以它主要使用在UDP协议上,因为UDP产生SIGIO信号的时候只有两种可能:
- 1.要么数据到达
- 2.发生错误
但相对TCP来说,产生SIGIO信号的地方太多了,比如请求连接,确认,断开,错误等等,所以我们很难根据SIGIO信号判断到底发生了什么。
5.异步IO
以上四种IO其实都还是同步IO,因为它们在读写数据时都是阻塞的,异步IO相较于它们最大的特点是它读写数据的时候也是非阻塞的,用户线程在发起一个IO请求的时候,除了给内核线程传递具体的IO请求外,还会给其传递数据缓冲区,回调函数通知等内容,然后用户线程就继续执行,等到内核线程发起相应通知的时候,说明数据已经准备就绪,用户线程直接使用即可,无需再阻塞从内核拷贝数据到用户线程。
小明异步IO吃饭:
有过了一段时间,小明又想吃外婆家了,但是这个周末他并不想出门,他突然在网上看到新闻说外婆家竟然可以叫外卖,小明高兴坏了,他马上打电话给外婆家,告诉它自己想要吃哪些菜(相当于IO请求所需要的数据),然后将自己的联系号码(相当于回调通知)和住址(相当于数据缓冲区)也告诉它,然后就挂掉电话,开心的做去打游戏了,过了半个小时后,手机响起,告知外卖已经到了,小明开门取外卖就可以直接开吃了。整个过程小明直到吃饭都没有等待阻塞。
关键部分:
- 叫外卖并提供相应的信息:非阻塞,打完电话后做自己的事
- 通知外卖到了:直接开门取外卖直接开吃,非阻塞
我们可以看出,异步IO才是真正的异步,因为它连数据拷贝这个过程都是非阻塞的,用户线程根本不用关心数据的读写等操作,只需等待内核线程通知后,直接处理数据即可,当然异步IO需要系统内核支持,比如Linux中的AIO和Windows中的IOCP,但是也可以通过多线程跟阻塞I/O模拟异步IO,比如可以在多路复用IO模型上进行相应的改变,另外也有现有的实现,比如异步I/O的库:libeio
最后用一张图总体概括一下Java IO(图片来自美团技术博客):
Java IO概图:
多路复用IO在Linux中的实现
因为后续会讲到Java NIO,所以我们需要了解操作系统是如何支持多路复用IO的,Linux中支持支持三种多路IO复用机制,分别是select、poll和epoll,本来这里我想自己写的,但查阅了相应的一些资料后,发现自己的水平还是不够,这里我不准备班门弄斧了,因为我找到了很多写的比较好的文章,这里就给大家列一下,仅供参考:
总结
这篇文章主要讲了最基础的IO模型,不过我认为最基础的往往是最重要的,只有理解了基础的原理,才能对基于它们实现的类库或者工具有更加深刻的认识,下一篇文章将会主要讲一下基于多路复用IO的Java NIO,敬请期待。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。