看了好多关于IO模型的文章和只是自己总结一下：

一、IO模型的知识

JAVA BIO：同步并阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程并处理，如果这个连接不做任何事情会造成不必要的开销，当然可以通过线程池机制改善

JAVA NIO：同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有IO请求时才启动一个线程进行处理

JAVA AIO(NIO2)：异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理；

2.使用场景

BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。

NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。

AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。

3.BIO 同步并阻塞

tomcat采用的传统的BIO（同步阻塞IO模型）+线程池模式，对于十万甚至百万连接的时候，传统BIO模型是无能为力的：

①线程的创建和销毁成本很高，在linux中，线程本质就是一个进程，创建销毁都是重量级的系统函数

②线程本身占用较大的内存，像java的线程栈一般至少分配512K-1M的空间，如果系统线程过高，内存占用是个问题

③线程的切换成本高，操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用，如果线程数过高可能执行线程切换的时间甚至大于线程执行的时间，这时候带来的表现是系统load偏高，CPUsy使用率很高

④容易造成锯齿状的系统负载。系统负载是用活动线程数或CPU核心数，一旦线程数量高但外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大。

4.NIO同步非阻塞

NIO基于Reactor，当socket有流可读或可写入socket，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。也就是，不是一个链接就要对应一个处理线程，而是一个有效请求对应一个线程，当连接没有数据时，是没有工作线程来处理的

Reactor模型

改进：逻辑处理部分由多线程完成

改进：多CPU，将Reactor拆分为两部分

nio只有acceptor的服务线程是堵塞进行的，其他读写线程是通过注册事件的方式，有读写事件激活时才调用线程资源区执行，不会一直堵塞等着读写操作，Reactor的瓶颈主要在于acceptor的执行，读写事件也是在这一块分发

5.AIO异步非堵塞IO

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

即，read/write方法都是异步的，完成后会主动调用回调函数；

二、IO处理的流程：

首先需要说明的一点是io多线路服用经常提到的select/poll和select/epoll两则的区别：

select/poll从程序的角度解释：将channel 注册到 seletor 上，通过轮询channel是否就绪，将就绪的channel返回。

epoll将channel 注册到 selector 上，基于回调的方式（类似监听者模式），告知selector哪些 channel 已经就绪，然后将就绪的 channel 返回。

两则相比，epoll的性能高于poll，特别是在有大量连接的时候，poll需要轮训的量上来；

BIO的IO处理流程：

一直堵塞在了网络传输数据上，只有等到数据都传到了内核，后复制到jvm应用中才好；

特别是在大量线程同时访问的时候，它的模型就变成了下图：

BIO是一对一的关系，在大批连用户同时操作的时候，thread大量生成，导致资源瞬间消耗。等等

NIO的IO处理流程：

从上图来看，如果你有用nio编程过，我相信你马上就知道了；就和上文说的一样，通过channl注册到select上，然后select轮训获取就绪的channl进一步处理；

AIO的IO处理流程：

程序调用AIO的accept方法并传入Completionhandler，该方法是非阻塞方法。等数据准备完成后回调Completionhandler处理响应操作。

内容图片如有侵权请联系删除；