【杂谈】对IO与NIO的认识

IO流与NIO块的数据缓存

   Java的IO是面向流设计的,通常我们通过IO流读取数据,只能指定读取数据的大小,而不能选择数据读取的起始位置。数据就像流水一样,流过我们的应用,一旦流过就无法回头。除非我们的代码对所读取的数据进行缓存,否则就再也见不到它了(针对此次流操作)。

  比如,我们创建一个byte[]数组来进行数据缓存,稍后可根据需要再次读取数组内的数据。但是有一点不方便的就是,如果我们要复用一个byte[]数组,即我们只处理了其中一部分数据,但是想用这个数组的剩余空间读入新数据。那我们就要在代码中维护一个偏移量offset,来告诉read操作,读取到的数据该从哪里开始存放。

  但是,如果使用NIO的ByteBuffer,就相对来说方便的多,它内部有维护几个字段,只要用户在对其进行读写后,正确地调用flip()方法,就可以复用缓冲对象。省去了维护偏移量的工作。

  而Netty,进一步完善了缓冲对象,它的ByteBuf对象,内部维护两个索引(读写)。也就不用再调用flip()方法了,降低错误概率。

注意:BufferedXXStream里面的缓冲数组没有发布,也就是说,它只在其内部使用,我们外部引用不到。它只是用来减少系统调用的。

 IO与NIO的读写效率

   据说,在单线程场景下,IO的读写速度要高于NIO。(未考证)

   NIO的主要优点是,当读写条件不满足的时候,即缓冲区内没有数据,或没有空间的时候(这里的缓冲区指的应该是内核空间)。执行IO操作的线程不会被阻塞,所谓阻塞,指的是线程是否会被挂起。那么在多线程场景下,我们就可以利用这个优点,即在当读写条件满足的时候再执行IO操作。这样就省去了一定的等待时间,这段时间内,此线程可以做其他事情,如给另一个满足读写条件的Channel进行读写。

那我们如何知晓哪些Channel满足读写条件呢?

答案就是Selector,Seletor可以筛选注册在其上的Channel。可读,或可写的Channel将被筛选出来。

那如果有多个Channel同时满足读写条件呢?

那就把满足条件的Channel,每个都执行一遍。可读的就读,可写的就写。

那这样时效性会不会比较差?

是的,会比较差。拿网络IO来讲,如果一个线程处理多个连接的操作,那么最好情况就是,这几个连接,同时读写的概率不大,或者读写的数据量很小,线程处理速度很快,这样其他读写任务就不会等太久。但是,如果,这多个线程同时读写概率大,或者读写数据量大,处理速度较慢,而又比较追求时效性的话,那么一个线程最好不要处理太多连接。

有了NIO,BIO就被放弃了吗?

BIO就是阻塞IO,那网络IO来讲,如果此线程调用read()操作,且缓冲区无数据可读的时候,此线程将一直阻塞(被挂起),直到有数据可读,才被唤醒。前面说了,NIO的使用场景是,一个线程会维护多个连接,如果多个Channel同时满足条件,那么其中最后一个Channel就要等待它前面的Channel完成读写操作后,才能开始任务。如果此连接比较追求时效性的话,即要求,自己发送数据,对方能立即响应并进行处理的话。那么就可以用BIO进行处理,即用一个专门的线程来监听一个连接,甚至一个连接的读或写操作。

个人认为,BIO就像是高速公路上的专用车道,平时用的不多,但是需要的时候,可以立即使用,且不用跟其他车辆竞争。