前言
Java里面的IO模型种类较多，主要包括BIO，NIO和AIO，每个IO模型都有不一样的地方，那么这些IO模型是如何演变呢，底层的原理又是怎样的呢？ 本文我们就来聊聊。
BIO
BIO全称是Blocking IO，是JDK1.4之前的传统IO模型，本身是同步阻塞模式，针对网络通信都是一请求一应答的方式，虽然简化了上层的应用开发，但在性能和可靠性方面存在着巨大瓶颈，试想一下如果每个请求都需要新建一个线程来专门处理，那么在高并发的场景下，机器资源很快就会被耗尽，当然，我们可以通过线程池来优化这种情况，但即使是这样，仍然改变不了阻塞IO的根本问题，就是在IO执行的两个阶段都被block了。拿一个read操作来举例子，在linux中，应用程序向linux发起read操作，会经历两个步骤：
第一个阶段linux内核首先会把需要读取的数据加载到操作系统内核的缓冲区中（Linux文件系统是缓存IO，也称标准IO）
第二个阶段应用程序拷贝内核里面的数据到自己的用户空间中
如果是socket操作，类似也会经历两个步骤：
第一个阶段：通常涉及等待网络上的数据分组包到达，然后被复制到内核的缓冲区
第二个阶段：把数据从内核缓冲区，从内核缓冲区拷贝到用户进程的内存空间里面
同步阻塞IO之所以效率低下，就是因为在这两个阶段，用户的线程或者进程都是阻塞的，期间虽然不占cpu资源，但也意味着该线程也不能再干其他事。有点站着茅坑不拉屎的感觉，自己暂时不用了，也不让别人用。
图示如下：
NIO
由于BIO的缺点，导致Java在JDK1.0至JDK3.0中，网络通信模块的性能一直是短板，所以很多人更倾向于使用C/C++开发高性能服务端。为了强化Java在服务端的市场，终于在JSR-51也就是JDK4.0的时候发布了Java NIO，可以支持非阻塞IO。并新增了java.nio的包，提供很多异步开发的API和类库。
主要的类和接口如下：
（1）进行异步IO操作的缓冲区ByteBuffer
（2）进行异步IO操作的管道Pipe
（3）进行各种IO操作的Channel，主要包括ServerSocketChannel和SocketChannel
（4）实现非阻塞IO的多路复用器Selector
NIO主要有buffer、channel、selector三种技术的整合，通过零拷贝的buffer取得数据，每一个客户端通过channel在selector（多路复用器）上进行注册。服务端不断轮询channel来获取客户端的信息。channel上有connect,accept（阻塞）、read（可读）、write(可写)四种状态标识。根据标识来进行后续操作。所以一个服务端可接收无限多的channel。不需要新开一个线程。大大提升了性能。
新的nio类库，促进了异步非阻塞编程的发展和应用，但仍然有一些不足之处：
（1）没有统一的文件属性，例如读写权限
（2）api能力比较弱，例如目录的及联创建和递归遍历，往往需要自己完成。
（3）底层操作系统的一些高级API无法使用
（4）所有的文件操作都是同步阻塞调用，在操作系统层面上并不是异步文件读写操作。
Java里面的NIO其实采用了多路复用的IO模式，多路复用的模式在Linux底层其实是采用了select，poll，epoll的机制，这种机制可以用单个线程同时监听多个io端口，当其中任何一个socket的数据准备好了，就能返回通知用户线程进行读取操作，与阻塞IO阻塞的是每一个用户的线程不一样的地方是，多路复用只需要阻塞一个用户线程即可，这个用户线程通常我们叫它Selector，其实底层调用的是内核的select，这里面只要任何一个IO操作就绪，就可以唤醒select，然后交由用户线程处理。用户线程读取数据这个过程仍然是阻塞的，多路复用技术只是在第一个阶段可以变为非阻塞调用，但在第二个阶段拷贝数据到用户空间，其实还是阻塞的，多路复用技术的最大特点是使用一个线程就可以处理很多的socket连接，尽管性能上不一定提升，但支持并发能力却大大增强了。
图示如下：
AIO
AIO，其实是NIO的改进优化，也被称为NIO2.0，在2011年7月，也就是JDK7的版本中发布，它主要提供了三个方面的改进：
（1）提供了能够批量获取文件属性的api，通过SPI服务，使得这些API具有平台无关性。
（2）提供了AIO的功能，支持基于文件的异步IO操作和网络套接字的异步操作
（3）完成了JSR-51定义的通道功能等。
AIO 通过调用accept方法，一个会话接入之后再次调用（递归）accept方法，监听下一次会话，读取也不再阻塞，回调complete方法异步进行。不再需要selector 使用channel线程组来接收。
从NIO上面我们能看到，对于IO的两个阶段的阻塞，只是对于第一个阶段有所改善，对于第二个阶段在NIO里面仍然是阻塞的。而真正的理想的异步非阻塞IO（AAIO）要做的就是，将IO操作的两个阶段都全部交给内核系统完成，用户线程只需要告诉内核，我要读取一块数据，请你帮我读取，读取完了放在我给你的地址里面，然后告诉我一声就可以了。
AIO可以做到真正的异步的操作，但实现起来比较复杂，支持纯异步IO的操作系统非常少，目前也就windows是IOCP技术实现了，而在Linux上，目前有很多开源的异步IO库，例如libevent、libev、libuv，但基本都不是纯的异步IO操作，底层还是是使用的epoll实现的。
图示如下：
NIO与Netty
既然Java拥有了各种IO体系，那么为什么还会出现Netty这种框架呢？
Netty出现的主要原因，如下：
（1）Java NIO类库和API繁杂众多，使用麻烦。
（2）Java NIO封装程度并不高，常常需要配合Java多线程编程来使用，这是因为NIO编程涉及到Reactor模式。
（3）Java NIO异常体系不完善，如客户端面临断连，重连，网络闪断，半包读写，网络阻塞，异常码流等问题，虽然开发相对容易，但是可靠性和稳定性并不高。
（4）Java NIO本身的bug，修复较慢。
注意，真正的异步非阻塞io，是需要操作系统层面支持的，在windows上通过IOCP实现了真正的异步io，所以Java的AIO的异步在windows平台才算真正得到了支持，而在Linux系统中，仍然用的是epoll模式，所以在Linux层面上的AIO，并不是真正的或者纯的异步IO，这也是Netty里面为什么采用Java的NIO实现的，而并非是AIO，主要原因如下：
（1）AIO在linux上底层实现仍使用EPOLL，与NIO相同，因此在性能上没有明显的优势
（2）Windows的AIO底层实现良好，但Netty的开发者并没有把Windows作为主要使用平台，所以优化考虑Linux
总结
本文主要介绍了Java里面IO模型的演变和发展，这也是Java在服务端领域大放异彩的一个重要原因，了解这些知识之后，我们再去学习高性能的Netty框架，将会更加容易