聊聊BIO、NIO与AIO的区别

题目：说一下bio/aio/nio 有什么区别？及异步模式的用途和意义？

1f

说一说i/o
首先来说一下什么是i/o?

在计算机系统中i/o就是输入（input）和输出(output)的意思，针对不同的操作对象，可以划分为磁盘i/o模型，网络i/o模型，内存映射i/o, direct i/o、数据库i/o等，只要具有输入输出类型的交互系统都可以认为是i/o系统，也可以说i/o是整个操作系统数据交换与人机交互的通道，这个概念与选用的开发语言没有关系，是一个通用的概念。

在如今的系统中i/o却拥有很重要的位置，现在系统都有可能处理大量文件，大量数据库操作，而这些操作都依赖于系统的i/o性能，也就造成了现在系统的瓶颈往往都是由于i/o性能造成的。因此，为了解决磁盘i/o性能慢的问题，系统架构中添加了缓存来提高响应速度；或者有些高端服务器从硬件级入手，使用了固态硬盘（ssd）来替换传统机械硬盘；在大数据方面，spark越来越多的承担了实时性计算任务，而传统的hadoop体系则大多应用在了离线计算与大量数据存储的场景，这也是由于磁盘i/o性能远不如内存i/o性能而造成的格局（spark更多的使用了内存，而mapreduece更多的使用了磁盘）。因此，一个系统的优化空间，往往都在低效率的i/o环节上，很少看到一个系统cpu、内存的性能是其整个系统的瓶颈。也正因为如此，java在i/o上也一直在做持续的优化，从jdk 1.4开始便引入了nio模型，大大的提高了以往bio模型下的操作效率。

这里先给出bio、nio、aio的基本定义与类比描述：

bio （blocking i/o）：同步阻塞i/o模式，数据的读取写入必须阻塞在一个线程内等待其完成。这里使用那个经典的烧开水例子，这里假设一个烧开水的场景，有一排水壶在烧开水，bio的工作模式就是， 叫一个线程停留在一个水壶那，直到这个水壶烧开，才去处理下一个水壶。但是实际上线程在等待水壶烧开的时间段什么都没有做。

nio （new i/o）：同时支持阻塞与非阻塞模式，但这里我们以其同步非阻塞i/o模式来说明，那么什么叫做同步非阻塞？如果还拿烧开水来说，nio的做法是叫一个线程不断的轮询每个水壶的状态，看看是否有水壶的状态发生了改变，从而进行下一步的操作。

aio （ asynchronous i/o）：异步非阻塞i/o模型。异步非阻塞与同步非阻塞的区别在哪里？异步非阻塞无需一个线程去轮询所有io操作的状态改变，在相应的状态改变后，系统会通知对应的线程来处理。对应到烧开水中就是，为每个水壶上面装了一个开关，水烧开之后，水壶会自动通知我水烧开了。

进程中的io调用步骤大致可以分为以下四步：

进程向操作系统请求数据 ;

操作系统把外部数据加载到内核的缓冲区中;

操作系统把内核的缓冲区拷贝到进程的缓冲区 ;

进程获得数据完成自己的功能 ;

当操作系统在把外部数据放到进程缓冲区的这段时间（即上述的第二，三步），如果应用进程是挂起等待的，那么就是同步io，反之，就是异步io，也就是aio 。

2f

bio（blocking i/o）同步阻塞i/o
这是最基本与简单的i/o操作方式，其根本特性是做完一件事再去做另一件事，一件事一定要等前一件事做完，这很符合程序员传统的顺序来开发思想，因此bio模型程序开发起来较为简单，易于把握。

但是bio如果需要同时做很多事情（例如同时读很多文件，处理很多tcp请求等），就需要系统创建很多线程来完成对应的工作，因为bio模型下一个线程同时只能做一个工作，如果线程在执行过程中依赖于需要等待的资源，那么该线程会长期处于阻塞状态，我们知道在整个操作系统中，线程是系统执行的基本单位，在bio模型下的线程 阻塞就会导致系统线程的切换，从而对整个系统性能造成一定的影响。当然如果我们只需要创建少量可控的线程，那么采用bio模型也是很好的选择，但如果在需要考虑高并发的web或者tcp服务器中采用bio模型就无法应对了，如果系统开辟成千上万的线程，那么cpu的执行时机都会浪费在线程的切换中，使得线程的执行效率大大降低。此外，关于线程这里说一句题外话，在系统开发中线程的生命周期一定要准确控制，在需要一定规模并发的情形下，尽量使用线程池来确保线程创建数目在一个合理的范围之内，切莫编写线程数量创建上限的代码。

3f

nio (new i/o) 同步非阻塞i/o
关于nio，国内有很多技术博客将英文翻译成no-blocking i/o，非阻塞i/o模型 ，当然这样就与bio形成了鲜明的特性对比。nio本身是基于事件驱动的思想来实现的，其目的就是解决bio的大并发问题，在bio模型中，如果需要并发处理多个i/o请求，那就需要多线程来支持，nio使用了多路复用器机制，以socket使用来说，多路复用器通过不断轮询各个连接的状态，只有在socket有流可读或者可写时，应用程序才需要去处理它，在线程的使用上，就不需要一个连接就必须使用一个处理线程了，而是只是有效请求时（确实需要进行i/o处理时），才会使用一个线程去处理，这样就避免了bio模型下大量线程处于阻塞等待状态的情景。

相对于bio的流，nio抽象出了新的通道（channel）作为输入输出的通道，并且提供了缓存（buffer）的支持，在进行读操作时，需要使用buffer分配空间，然后将数据从channel中读入buffer中，对于channel的写操作，也需要现将数据写入buffer，然后将buffer写入channel中。

如下是nio方式进行文件拷贝操作的示例，见下图：

通过比较new io的使用方式我们可以发现，新的io操作不再面向 stream来进行操作了，改为了通道channel，并且使用了更加灵活的缓存区类buffer，buffer只是缓存区定义接口， 根据需要，我们可以选择对应类型的缓存区实现类。在java nio编程中，我们需要理解以下3个对象channel、buffer和selector。

• channel

首先说一下channel，国内大多翻译成“通道”。channel和io中的stream(流)是差不多一个等级的。只不过stream是单向的，譬如：inputstream, outputstream。而channel是双向的，既可以用来进行读操作，又可以用来进行写操作，nio中的channel的主要实现有：filechannel、datagramchannel、socketchannel、serversocketchannel；通过看名字就可以猜出个所以然来：分别可以对应文件io、udp和tcp（server和client）。

• buffer

nio中的关键buffer实现有：bytebuffer、charbuffer、doublebuffer、 floatbuffer、intbuffer、 longbuffer,、shortbuffer，分别对应基本数据类型: byte、char、double、 float、int、 long、 short。当然nio中还有mappedbytebuffer, heapbytebuffer, directbytebuffer等这里先不具体陈述其用法细节。

说一下 directbytebuffer 与 heapbytebuffer 的区别？

它们 bytebuffer 分配内存的两种方式。heapbytebuffer 顾名思义其内存空间在 jvm 的 heap（堆）上分配，可以看做是 jdk 对于 byte[] 数组的封装；而 directbytebuffer 则直接利用了系统接口进行内存申请，其内存分配在c heap 中，这样就减少了内存之间的拷贝操作，如此一来，在使用 directbytebuffer 时，系统就可以直接从内存将数据写入到 channel 中，而无需进行 java 堆的内存申请，复制等操作，提高了性能。既然如此，为什么不直接使用 directbytebuffer，还要来个 heapbytebuffer？原因在于， directbytebuffer 是通过full gc来回收内存的，directbytebuffer会自己检测情况而调用 system.gc()，但是如果参数中使用了 disableexplicitgc 那么就无法回收该快内存了，-xx:+disableexplicitgc标志自动将 system.gc() 调用转换成一个空操作，就是应用中调用 system.gc() 会变成一个空操作，那么如果设置了就需要我们手动来回收内存了，所以directbytebuffer使用起来相对于完全托管于 java 内存管理的heap bytebuffer 来说更复杂一些，如果用不好可能会引起oom。direct bytebuffer 的内存大小受 -xx:maxdirectmemorysize jvm 参数控制（默认大小64m），在 directbytebuffer 申请内存空间达到该设置大小后，会触发 full gc。

• selector

selector 是nio相对于bio实现多路复用的基础，selector 运行单线程处理多个 channel，如果你的应用打开了多个通道，但每个连接的流量都很低，使用 selector 就会很方便。例如在一个聊天服务器中。要使用 selector , 得向 selector 注册 channel，然后调用它的 select() 方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新的连接进来、数据接收等。

这里我们再来看一个nio模型下的tcp服务器的实现，我们可以看到selector 正是nio模型下 tcp server 实现io复用的关键，请仔细理解下段代码while循环中的逻辑，见下图：

4f

aio (asynchronous i/o) 异步非阻塞i/o
java aio就是java作为对异步io提供支持的nio.2 ，java nio2 (jsr 203)定义了更多的 new i/o apis， 提案2003提出，直到2011年才发布， 最终在jdk 7中才实现。jsr 203除了提供更多的文件系统操作api(包括可插拔的自定义的文件系统)， 还提供了对socket和文件的异步 i/o操作。 同时实现了jsr-51提案中的socket channel全部功能,包括对绑定， option配置的支持以及多播multicast的实现。

从编程模式上来看aio相对于nio的区别在于，nio需要使用者线程不停的轮询io对象，来确定是否有数据准备好可以读了，而aio则是在数据准备好之后，才会通知数据使用者，这样使用者就不需要不停地轮询了。当然aio的异步特性并不是java实现的伪异步，而是使用了系统底层api的支持，在unix系统下，采用了epoll io模型，而windows便是使用了iocp模型。关于java aio，本篇只做一个抛砖引玉的介绍，如果你在实际工作中用到了，那么可以参考netty在高并发下使用aio的相关技术。

总 结

io实质上与线程没有太多的关系，但是不同的io模型改变了应用程序使用线程的方式，nio与aio的出>现解决了很多bio无法解决的并发问题，当然任何技术抛开适用场景都是耍流氓，复杂的技术往往是为了解决简单技术无法解决的问题而设计的，在系统开发中能用常规技术解决的问题，绝不用复杂技术，>否则大大增加系统代码的维护难度，学习it技术不是为了炫技，而是要实实在在解决问题。

原文地址：

https://juejin.im/entry/598da7d16fb9a03c42431ed3