I/O通信模型（BIO,NIO,AIO）

一、传统的BIO

网络编程的基本模型是Client/Server模型，也就是两个进程之间进行相互通信，其中服务端提供位置信息（绑定的IP地址和监听端口），客户端通过连接操作向服务端监听的地址发起连接请求，通过三次握手建立连接，如果连接建立成功，双方就可以通过网络套接字（Socket）进行通信。

在基于传统同步阻塞模型开发中，ServerSocket负责绑定IP地址，启动监听端口，Socket负责发起连接操作，连接成功之后，双方通过输入和输出流进行同步阻塞式通信。

1.1、BIO通信模型图

首先，我们通过下面的通信模型图来熟悉下BIO的服务端通信模型：采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的一请求一应答通信模型。

　　该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1：1的正比关系，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能将急剧下降，随着并发访问量的继续增大，系统会发生线程堆栈溢出、创建新线程失败等问题，并最终导致进程宕机或者僵死，不能对外提供服务。

它的弊端有很多：

1.性能问题：一连接一线程模型导致服务端的并发接入数和系统吞吐量受到极大限制；

2.可靠性问题：由于I/O操作采用同步阻塞模式，当网络拥塞或者通信对端处理缓慢会导致I/O线程被挂住，阻塞时间无法预测；

3.可维护性问题：I/O线程数无法有效控制、资源无法有效共享（多线程并发问题），系统可维护性差；

二、伪异步IO编程

为了解决同步阻塞IO面临的一个链路需要一个线程处理的问题，后来有人对它的线程模型进行了优化，后端通过一个线程池来处理多个客户端的请求接入，形成客户端个数M：线程池最大线程数N的比例关系，其中M可以远远大于N，通过线程池可以灵活的调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。下面，我们结合连接模型图和源码，对伪异步IO进行分析，看它是否能够解决同步阻塞IO面临的问题。

2.1、伪异步IO模型图

采用线程池和任务队列可以实现一种叫做伪异步的IO通信框架，它的模型图如下：

当有新的客户端接入的时候，将客户端的Socket封装成一个Task（该任务实现java.lang.Runnable接口）投递到后端的线程池中进行处理,JDK的线程池维护一个消息队列和N个活跃线程对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源的耗尽和宕机。

三、NIO（多路复用器Selector）

几乎所有的中文技术书籍都将Selector翻译为选择器，但是实际上我认为这样的翻译并不恰当，选择器仅仅是字面上的意思，这样翻译体现不出Selector的功能和特点。

在前面的章节我们介绍过Java NIO的实现关键是通过多路复用IO技术实现的，多路复用的核心就是通过Selector来轮询注册在其上的Channel，当发现某个或者多个Channel处于就绪状态后，从阻塞状态返回就绪的Channel的选择键集合，进行IO操作。由于多路复用器是NIO实现非阻塞IO的关键，它又是主要通过Selector实现，所以本书将Selector翻译为多路复用器，它与其它技术书籍所说的选择器是同一个东西，请大家了解。

四、AIO异步IO