JAVA中的I/O模型
I/O 模型：就是用什么样的通道或者说是通信模式和架构进行数据的传输和接收，很大程度上决定了程序通信的性能。
Java 共支持 3 种网络编程的/IO 模型：同步阻塞的BIO、同步非阻塞的NIO、异步非阻塞的AIO。
实际通信需求下，要根据不同的业务场景和性能需求决定选择不同的I/O模型。
同步阻塞IO：在此种方式下，用户进程在发起一个IO操作以后，必须等待IO操作的完成，只有当真正完成了IO操作以后，用户进程才能运行。JAVA传统的IO模型属于此种方式！
同步非阻塞IO：在此种方式下，用户进程发起一个IO操作以后边可返回做其它事情，但是用户进程需要时不时的询问IO操作是否就绪，这就要求用户进程不停的去询问，从而引入不必要的CPU资源浪费。JAVA的NIO就属于同步非阻塞IO。
异步阻塞IO：此种方式下是指应用发起一个IO操作以后，不等待内核IO操作的完成，等内核完成IO操作以后会通知应用程序，这其实就是同步和异步最关键的区别，同步必须等待或者主动的去询问IO是否完成，那么为什么说是阻塞的呢？因为此时是通过select系统调用来完成的，而select函数本身的实现方式是阻塞的，而采用select函数有个好处就是它可以同时监听多个文件句柄，从而提高系统的并发性！
异步非阻塞IO：在此种模式下，用户进程只需要发起一个IO操作然后立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要进行实际的IO读写操作，因为真正的IO读取或者写入操作已经由内核完成了。Java AIO属于这种异步非阻塞模型。
参考链接：blog.csdn.net/ty497122758…
同步阻塞BIO:一个连接一个线程
按上面的理解:同步阻塞IO是用户主动调用内核,当前线程会被阻塞,用户空间程序需等到IO操作彻底完成。
同步阻塞的服务器实现模式为一个连接一个线程。
服务端启动一个[ServerSocket],然后在客户端启动[Socket]来对服务端进行通信。
即客户端有连接请求时服务器端就需要启动一个线程进行处理。如果这个连接不做任何事情会造成不必要的线程开销。
缺点:
1.需要创建大量线程。
2.没有请求数据会造成线程资源浪费。
最传统的一种IO模型，即在读写数据过程中会发生阻塞现象。
当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。
当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
典型的阻塞IO模型的例子为：
data = socket.read();
如果数据没有就绪,就会一直阻塞在read方法。
即使开多进程也不能解决IO阻塞问题。
服务端为了处理客户端的连接和请求的数据，写了如下代码。
listenfd = socket(); // 打开一个网络通信端口
bind(listenfd); // 绑定
listen(listenfd); // 监听
while(1) {
connfd = accept(listenfd); // 阻塞建立连接
int n = read(connfd, buf); // 阻塞读数据
doSomeThing(buf); // 利用读到的数据做些什么
close(connfd); // 关闭连接，循环等待下一个连接
}
这段代码会执行得磕磕绊绊，就像这样。
可以看到，服务端的线程阻塞在了两个地方，一个是 accept 函数，一个是 read 函数。
1.accept需要接受用户的socket连接。
2.连接建立以后,还需要等待用户的socket连接发起发送数据的操作,即write操作。
如果再把read 函数的细节展开，我们会发现其阻塞在了两个阶段。
阻塞IO的两个阻塞阶段动画
这就是传统的阻塞 IO。服务器端整体流程如下图。
所以，如果这个连接的客户端一直不发数据，那么服务端线程将会一直阻塞在 read 函数上不返回，也无法接受其他客户端连接。这肯定是不行的。
优点：用户程序开发简单，在阻塞等待数据期间，用户线程挂起，这段时间内，用户线程基本不会占用 CPU 资源。
缺点：通常会为每个连接配备一个独立的线程，由这个线程来维护一个连接的 IO 操作。
那么在高并发的情况下，就需要大量的线程来维护大量的网络连接，内存和线程切换的开销将会非常巨大。
同步非阻塞NIO:占用CPU
按上面的理解:同步非阻塞IO是用户调用内核当前线程不会被阻塞,可以立刻返回。
当服务器线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。 如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。 一旦内核中的数据准备好了，并且又再次收到了服务器线程的read请求，那它马上就将数据拷贝到用户线程，然后返回。 所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。
//典型的非阻塞IO模型一般如下：
data = socket.read();
while(true){
if(data!= -1){
处理数据
break;
}
}
但是对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。
为了解决上面的问题，其关键在于改造这个 read 函数。
有一种看似聪明的办法是，每次都创建一个新的进程或线程，去调用 read 函数，并做业务处理。
while(true) {
connfd = accept(listenfd); // 阻塞建立连接
pthread_create(doWork); // 创建一个新的线程
}
void doWork() {
int n = read(connfd, buf); // 阻塞读数据
doSomeThing(buf); // 利用读到的数据做些什么
close(connfd); // 关闭连接，循环等待下一个连接
}
这样，当给一个客户端建立好连接后，就可以立刻等待新的客户端连接，而不用阻塞在原客户端的 read 请求上。
不过，这不叫非阻塞 IO，只不过用了多线程的手段使得主线程没有卡在 read 函数上不往下走罢了。
操作系统为我们提供的 read 函数仍然是阻塞的。
同时多个连接,仍然需要多个线程。
所以真正的非阻塞 IO，不能是通过我们用户层的小把戏，而是要恳请操作系统为我们提供一个非阻塞的 read 函数。
这个 read 函数的效果是，如果没有数据到达时（即没有数据到达网卡并拷贝到了内核缓冲区），立刻返回一个错误值（-1），而不是阻塞地等待。
操作系统提供了这样的功能，只需要在调用 read 前，将文件描述符设置为非阻塞即可。
fcntl(connfd, F_SETFL, O_NONBLOCK);
int n = read(connfd, buffer) != SUCCESS);
这样，就需要用户线程死循环调用 read，直到返回值不为 -1，再开始处理业务。
非阻塞IO内核态用户态动画
这里我们注意到一个细节。
非阻塞的 read，指的是在数据到达前，即数据还未到达网卡，或者到达网卡但还没有拷贝到内核缓冲区之前，这个阶段是非阻塞的。
当数据已到达内核缓冲区，此时调用 read 函数仍然是阻塞的，需要等待数据从内核缓冲区拷贝到用户缓冲区，才能返回。
非阻塞IO虽然在用户发起请求时会立即返回，但是当内核准备好数据之后,非阻塞IO依然需要用户线程发起请求才会将数据从内核空间拷贝到用户空间，因此非阻塞IO属于同步IO。
整体流程如下图。
- 优点：每次发起 IO 系统调用，在内核等待数据过程中可以立即返回，用户线程不会阻塞 ，实时性较好。
- 缺点：不断轮询内核，将会占用大量的 CPU 时间，浪费性能，效率低下，因此，在高并发的情况下，同步非阻塞模型也是不可用的。
多路复用IO模型
Java NIO ： 同步非阻塞，服务器实现模式为一个线程处理多个请求(连接)，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求就进行处理 。
IO多路复用:程序注册一组socket文件描述符给操作系统，表示“我要监视这些fd是否有IO事件发生，有了就告诉程序处理”。
IO多路复用也属于NIO, IO多路复用和NIO是要配合一起使用才有实际意义。
使用 I/O 多路复用时，最好搭配非阻塞 I/O 一起使用,即调用完立刻有结果,无论结果是什么样的即使文件。
服务器实现模式为一个线程处理多个请求(连接)，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求就进行处理。
多路复用IO+NIO模型是目前使用得比较多的模型。
在多路复用IO模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的IO读写操作。
因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。
也许有朋友会说，我可以采用 多线程+ 阻塞IO 达到类似的效果，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用，并且尤其是对于长连接来说，线程的资源一直不会释放，如果后面陆续有很多连接的话，就会造成性能上的瓶颈。
而多路复用IO模式，通过一个线程就可以管理多个socket，只有当socket真正有读写事件发生才会占用资源来进行实际的读写操作。因此，多路复用IO比较适合连接数比较多的情况。
多路复用IO为何比非阻塞IO模型的效率高是因为在非阻塞IO中，不断地询问socket状态是通过用户线程去进行的，而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。
不过要注意的是，多路复用IO模型是通过轮询的方式来检测是否有事件到达，并且对到达的事件逐一进行响应。因此对于多路复用IO模型来说，一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询。可以分为2个线程组,1组用来轮询接收新连接,1组用来处理业务。
BIO将每一个客户端请求分配给一个线程来单独处理。这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身对线程的总数也有一定的限制。
如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。
NIO本身是基于事件驱动思想来完成的，其主要想解决的是BIO的大并发问题： 在使用同步I/O的网络应用中，如果要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通讯，就必须使用多线程来处理。也就是说，将每一个客户端请求分配给一个线程来单独处理。
原因是:如果不使用多线程,只使用单线程。如果有100个连接并发请求,使用1个线程遍历这100个请求。假如每秒有10个请求就绪,每次处理需要100ms,那么每次处理需要1秒。最后10个请求要9秒才能处理完成。
这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身对线程的总数也有一定的限制。
如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。
NIO基于Reactor，当socket有流可读或可写入socket时，操作系统会相应的通知应用程序进行处理，应用再将流读取到缓冲区或写入操作系统。
也就是说，这个时候，已经不是一个连接就要对应一个处理线程了。仅限于有效的请求，才能对应一个线程。
当连接没有数据时，是没有工作线程来处理的。
BIO与NIO一个比较重要的不同，是我们使用BIO的时候往往会引入多线程，每个连接一个单独的线程；
而NIO则是使用单线程或者只使用少量的多线程，多个连接共用一个线程。
NIO的最重要的地方是当一个连接创建后，不需要对应一个线程，这个连接会被注册到多路复用器上面，所以所有的连接只需要一个线程就可以搞定，当这个线程中的多路复用器进行轮询的时候，发现连接上有请求的话，才开启一个线程进行处理，也就是一个请求分配一个线程的模式。
在NIO的处理方式中，当一个请求来的话，开启线程进行处理，可能会等待后端应用的资源(JDBC连接等)，其实这个线程就被阻塞了，当并发上来的话，还是会有BIO一样的问题。
io操作本质上发生在内核空间. nio 的一个工作线程并不会傻傻等着io操作执行完毕, 而是把这个io 任务交给内核后就返回线程池了, 内核完成任务后会通知 eventloop 从线程池里找一个线程执行后续的操作.所以线程池有限数量的线程可以轻松应付海量的io向任务.
为每个客户端创建一个线程，服务器端的线程资源很容易被耗光。
当然还有个聪明的办法，我们可以每 accept 一个客户端连接后，将这个文件描述符（connfd）放到一个数组里。
fdlist.add(connfd);
然后弄一个新的线程去不断遍历这个数组，调用每一个元素的非阻塞 read 方法。
while(1) {
for(fd
