talent-aio的使用和原理讲解系列（一）--java bio、nio、aio的io模型区别讲解

   2017年春季开源中国要说最火的开源项目，即时通信框架敢说第一，没人敢说第二，当然现在是3月10日，它还能否火热一年让我们拭目以待。

   虽然我不是talent-aio的作者，但也是挂名的开发者，所以好歹也得给它做点事情，写个博客给大家介绍它的使用，也不枉talent-aio作者对我的教诲。之所以talent-aio会开源，其实也有我的功劳，哈哈，因为当初我和作者是同事并住同一个小区，某一个散步的路上，作者一面感慨时光荏苒，一面觉得事业到了瓶颈，需要一个突破口，准备把精心打造的

talent-aio开源出去以寻找新突破口；当时听他的想法后，我非常赞同他的想法，并表示，一个人的身价往往和名气成正比，干同一件事情，名气不一样，价钱也不一样，因此让他感觉开源，并推广。好吧，我意淫了。

   回归正题，talent-aio从名字上开就知道，它的核心就是aio，异步通信，大家都知道，io模型现在分三类，bio、nio、aio；

bio 顾名思意，就是堵塞io，它的io模型如下图：





服务器接受客户端的请求后要指派或者新建一个线程资源去处理客户端的io事件，直到接收到断开连接的指令。这样

的弊端在并发情况下，愈发明显，它是同步堵塞的模型，操作系统在没处理完一个Io事件时会一直堵塞在一个连接上，其他socket连接就会被堵塞挂起，当并发量特别大时，一方面会造成大量连接挂起，另一方面会造成线程资源的不足，因为针对一个socket连接，服务器要新建一个线程进行处理，哪怕使用线程池也会造成大量上下文切换开销。

nio 是非堵塞io 使用的是Reactor模型 如下图所示：





此图来着:http://www.cnblogs.com/jasongj/p/5797863.html

如上图所示，nio只有acceptor的服务线程是堵塞进行的，其它读写线程是通过注册事件的方式，有读写事件激活时

才调用线程资源去执行，不会一直堵塞等着读写操作。Preactor的瓶颈主要是在accepotr的执行，所有的读写事件是在他这一块了分发。

AIO 是异步非堵塞IO模型，如下图所示：





与NIO不同，aio需要一个连接注册读写事件和回调方法，当进行读写操作时，只须直接调用API的read或write方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。 

即可以理解为，read/write方法都是异步的，完成后会主动调用回调函数。

以上是BIO、NIO、AIO的区别，AIO不管是在性能上还是稳定性上都优于BIO和NIO，但API使用复杂度都高于NIO和BIO，包括调试难度，所以Talent-aio的出现就是为了解决这两个问题，封装AIO的API并提供更友好的接口，同时talent-aio内部把线程池和多线程发挥到极致，帮我们把aio的性能发挥到最佳，我们只需要简单的使用即可，也不用考虑tcp的沾包粘包等问题。

talent-AIo的使用案例将在下一篇给出！