Netty学习第一章-JAVA的I/O演进之路

Netty学习第一章-JAVA的I/O演进之路

1、I/O基础

java1.4之前的早起版本，对I/O的支持并不完善，开发人员在开发高性能I/O程序的时候，会面临一些巨大的挑战和困难，主要困难如下：

• 没有数据缓冲区，I/O性能存在问题
• 没有Channel的概念，只有输入和输出流
• 同步阻塞式I/O通信，通常会导致通信线程被长时间阻塞
• 支持的字符集有限，硬件可移植性不好。

因此，高性能服务端开发领域一直被C++和C长期占据【因为他们可以直接使用操作系统的异步I/O或者AIO的能力】，当并发访问量增大或者响应时间延迟增大之后，采用JAVA的BIO开发的服务端软件只有通过硬件的不断扩容来满足高并发和低延迟。它极大的增加了企业的成本，并且随着集群规模的不断扩大，系统的维护性也将面临巨大的挑战。使得JAVA支持非阻塞I/O的呼声日渐高涨，最终，在JDK1.4版本提供了新的NIO类库,在JDK1.7版本提供了AIO类库。

2、java的I/O模型

I/O模型简单的理解，就是用什么样的通道进行数据的发送和接收，很大程度上决定了程序通信的性能。
上文提到的，JAVA目前共支持三种I/O模型：BIO、NIO、AIO。

2.1、BIO模型（同步并阻塞）

（上图片来源于网络）
如上图所示，BIO模型通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每一个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁，这就是典型的一请求，一应答通信模型。
根据图形分析，这种模型最大的问题就是缺乏弹性伸缩能力，由于服务端的线程数和客户端的连接请求是1:1的关系，因此，当客户端并发访问量增大之后，服务端的线程数也会随之增大，当并发量大到一定程度，可能会导致线程堆栈溢出，最终导致进程宕机，或者僵死，不能对外提供服务。

2.2、NIO模型（同步非阻塞）

（基于自己的理解所画之图，如不对，欢迎矫正）
NIO弥补了原来同步阻塞I/O的不足，它在标准Java代码中提供了告诉的，面向块的I/O，通过定义包含数据的类，以及通过块的形式处理这些数据，NIO不用使用本机代码就可以利用低级优化，这是原来的BIO无法做到的。NIO的非阻塞模式，其实就是一个线程从某通道发送请求或者读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可 以继续做其他的事情。
通俗的来说：NIO是可以做到用一个线程来处理多个操作的，假设有1000个请求过来，根虎实际情况，分配5个或者10个线程来处理，不像BIO那样，需要分配1000个线程来处理，大大的减轻了服务器的压力。

2.3、AIO模型

JDK1.7升级了NIO类库，引人注目的是，JAVA正式提供了异步文件I/O操作，同时提供了与UNIX网络编程事件驱动I/O对应的AIO。在进行 I/O 编程中，常用到两种模式:Reactor 和 Proactor。Java 的 NIO 就是 Reactor，当有事件触发时，服务器端得到通知，进行相应的处理。AIO 即 NIO2.0，叫做异步不阻塞的 IO。AIO 引入异步通道的概念，采用了Proactor模式，简化了程序编写，有效的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用。
当然，我发现就目前来说 AIO 的应用还不是很广泛，Netty之前也尝试使用过 AIO，不过又放弃了。

3、三种I/O模型的应用场景

BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4
以前的唯一选择，但程序简单易理解。
NIO 方式适用于连接数目多且连接比较短(轻操作)的架构，比如聊天服务器，弹幕系统，服务器间通讯等。编程比较复杂，JDK1.4 开始支持。
AIO 方式使用于连接数目多且连接比较长(重操作)的架构，比如相册服务器，充分调用OS 参与并发操作，编程比较复杂，JDK7 开始支持。