JavaIO模型

BIO

最早模式
jdk1.4以前我们都使用这个BIO, 就是阻塞IO,因为一个线程只能处理一个Client请求,多个Client请求就需要多个线程来处理,线程是非常宝贵的资源,如果线程太多占满了整个计算机的资源,整个计算机就会挂掉了,这是最大的问题.

线程池模式

改进措施是使用了线程池,在你处理事情的时候我不让你创建新的连接了,直接从线程池里面拿连接,用完再放回线程池就行了.

使用线程池存在的问题是,如果线程池里面的线程用完了,后面的请求就得等待了,甚至会超时,这样的客户体验是很不好的

BIO的读和写也是同步的
什么是同步?
比如说客户端建立一个连接过来,客户端发了一条数据过去,服务端在处理,没有处理完的时候,这个线程的Client是不能干别的,只能等待.对于写的操作也是一样的,没处理完的时候也只能等待.

IO线程和业务线程是不匹配的,也就是速度差很大,这样导致一个问题就是可靠性非常差.



当多个Client请求过来时候,会相应地开启多个线程,线程什么时候去执行?
是由CPU来决定的,也就是说线程何时抢到CPU的执行权就会执行,CPU资源是非常宝贵的,不仅仅要处理你这个业务逻辑,它还要有其它的事情去做,CPU保证每个线程执行的有意义的,何时有意义?只有执行IO操作的时候CPU才有意义的.
多个线程一定就是IO操作么?
Socket来了之后就创建了线程,这样是不合理的,因为Socket来了之后不一定就会进行IO操作了,也就是CUP不一定是执行到你的时候你是有意义的.

正确的创建线程时机应该是:
1. Socket连接上来了 —这里不要去抢夺 不要去创建线程.
2. IO操作 —这时候获取CPU线程是有意义的

此时需要做的事情就是要优化线程创建的时期:
一定要等到进行IO操作的时候这个线程才有必要去创建,如果仅仅是Client连接上来了,我不希望去创建线程

继续优化
此时当Client连接过来的时候, 我用一个Map集合去进行登记,记录Socket集合登记, 然后你什么时候去进行IO操作的时候再给你创建线程…后来JDK官方要捍卫自己的尊严,开发了NIO通信架构(jdk1.4之后)

NIO

当Client的Socket连接过来之后我不是给你分配一个线程,而是给你进行登记,信息放入一个类似Map的容器里面:
put(“ClientA”,”Connected”);

当Client一旦进行IO操作的时候,我就给你分配一个线程进行IO操作.
什么时候知道Client需要IO操作了?当容器Map状态 (“ClientA”,”Readable”);或者是(“ClientA”,”Writable”);的时候,就说明要进行Io操作了.

这个类似Map的容器其实是一个类,这个类就是Selector选择器,作用就是选择客户端的连接


NIO也引进了通道Channel类,通道是客户端和服务端连接用的,是多路复用的


Buffer缓冲区
就是一个数据交互的桥梁,所有的读写操作都会去经过这个桥梁



jdk1.4 Linux多路复用技术,也就是select模式
实现IO事件轮询的方式,同步非阻塞模式,是NIO1,这种方式是通过多路复用方式来实现

网络通信框架: Mina,Netty
用网络通信框架比我直接写NIO要容易些,并且可读性更好

AIO

jdk1.7过后Java的IO达到了一个好的扩展,NIO叫成了NIO2,实现了真正的异步IO, NIO2学习了Linux的epoll 模式

NIOAIOBIO案例代码

故事

爪哇村的大嘴做得一手好菜，原本是和平饭店的厨子，对吃的东西悟性很高，工作之余喜欢研究各种创新菜，最近自创一道麻辣小龙虾，顾客们吃后反响强烈，于是，大嘴想自立门户，专门开店经营小龙虾。

说干就干，为了方便抓虾，大嘴将饭店开在了河边，并取名“河底捞”。大嘴虽然姓大，但是野心其实并不大，起初，只是想采取日式料理的做法，店里就他自己一个人，晚上抓虾，白天做成麻辣小龙虾，服务客人。

计划赶不上变化，饭店开张没几天，来吃小龙虾的人越来越多，到饭点时间，大嘴一个人根本忙不过来，实在没办法，于是大嘴找到隔壁张三、李四和王五的老婆，对这3个人讲，到饭点时到他店里来帮忙，主要是帮他当服务员，负责给客人点餐，上菜，结账，清理桌子。大嘴说，来了客人，我就叫你们仨，服务完客人，你们各回各家。于是，我们的BIO通信模型登场了：



来一个客人（Web Brower1），大嘴（Acceptor）就去隔壁叫张三（New Thread1），服务完客人，张三就回家。

来两个客人（Web Brower2），大嘴就去隔壁叫李四（New Thread2），服务完客人，李四就回家。

来三个客人（Web Brower3），大嘴就去隔壁叫王五的老婆（New Thread3），服务完客人，王五的老婆就回家。

大嘴的偶像是米其林3星厨师小野二郎，经营理念就是一个服务员全程服务好一个客人（connection per thread），客人上桌后，服务员就要站在旁边服务，直到客人用餐完毕。美味的小龙虾和良好的用餐体验，吸引越来越多的村民来大嘴店里用餐。随着客户端数量不断增加，BIO通信模型的问题显露无疑：每一个新客户端接入时，服务端必须创建一个新的线程处理新接入的客户端链路，一个线程只能处理一个客户端连接，在高性能服务领域，需要面对成千上万个客户端并发连接，这种模型无法满足高性能、高并发接入场景。采用这种模型，要想满足客人用餐需求，再多来一个客人，大嘴得临时叫上赵六，孙七，周八，吴九，郑十，大嘴能叫过来帮忙的邻居就这么几位，叫完就没有了。后面来的客人，大嘴只好让他们回家，改天再来。

这样下去显然不行，大嘴又找到隔壁张三、李四和王五的老婆，对这3个人讲：以后我不叫你们了，你们每天直接来我店里上班，换上“河底捞”的统一服装，朝九晚五，我给你们开固定工资，这样就节省了你们来来回回的时间，一开始张三和李四不是特别愿意，说要在家陪老婆，但是很快被王五的老婆说服了。于是有了采用线程池和任务队列的“伪异步IO模型”。

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


没客人时，张三、李四和王五的老婆都在店里待命，新来了客人，他们仨陆续上去服务，服务完，继续在店里待命，店门口放了5个凳子，供客人等候。这样改进之后，用户体验有了一定提升，但3个服务员在客人用餐时，还是全程陪在桌旁为其服务，用过餐的都夸“河底捞”的服务好。尤其是钱大爷，特别满意“河底捞”的服务，钱大爷爱喝酒，每次用餐要4个小时，王五的老婆在旁边一会上菜，一会倒酒，一会递热毛巾，基本上一天就服务钱大爷这一个客人。当钱大爷这类人来用餐时，外面排队的5个凳子早早就坐满了人，并且后面再来的客人，大嘴只能劝他们改日再来。

这就是这种“伪异步IO模型”典型的问题，当可用线程都被故障服务器阻塞时，后续所有的IO消息都将在队列中排队，线程池采用阻塞队列实现，当队列积满后，后续入队的操作将被阻塞，前端只有一个Accept线程接收客户端接入，它被阻塞在线程池的同步阻塞队列之后，新的客户端请求将被拒绝，客户端会发生大量连接超时。

大嘴很快意识到，“伪异步IO模型”依然极大地限制了客流量，导致后面来的客人怨声载道，村里的林捕头每天下班过来，想要吃一顿小龙虾，发现门口已经排满了人，根本吃不上。林捕头放出风声，说大嘴长期在河边抓虾，可能会破坏村里的生态环境。于是大嘴紧急召集张三、李四和王五的老婆开会，讨论如何让林捕头能够排上队，吃上小龙虾。

张三曾经在爪哇村村委会干过一段时间码农，他说他知道有一种NIO模型（非阻塞IO），和现在店里的情况很像。几乎所有的网络连接都会经过“读取请求内容—>解码—>计算处理—>编码—>回复”，类似于店里“接待—>找桌—>点菜—>上菜—>结账—>收拾桌子”，每开一个桌子，我们称为开了一个channel，每个桌上放一个灯，当客人有点菜、上菜、结账等服务需求时，点亮灯，我们会有一个全局的管理者selector，会不断地在各个channel轮询（polling），检测是否有灯点亮，如果有灯亮，则通知专门的服务员来进行服务。这就是IO多路复用，IO多路复用可同时监听多个描述符（socket），一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作，IO多路复用避免阻塞在IO上，原本为多线程来接收多个连接的消息变为单线程保存多个socket的状态后轮询处理。

这种机制也叫做反应器模式（Reactor），Reactor负责响应IO事件（accept，read，send），当检测到一个新的事件，将其发送给相应的Handler去处理。Reactor为单个线程，需要处理accept连接，同时发送请求到Handler中。由于只有单个线程，所以Handler中的业务需要能够快速处理完。



于是，大嘴安排张三专职点菜传菜，李四负责上菜结账，王五的老婆负责其他on call的特殊服务，大嘴则负责盯着各个桌上的灯是否亮着，有灯点亮就叫相应的服务员过来处理。这样改进后，效果显著，虽然饭店已经人满为患，门口竟然没有排队的，生意越来越红火。

改进流程后，服务效率显著提高，店里的客流量继续增长，三个服务员每天忙得不可开交，但对于来个十桌八桌客人，三个服务员基本可以轻松应付。不过在某些情况下，会突然出现人手急剧短缺的情况，这种情况在林捕头就餐时经常发生。林捕头有选择困难症，每次点菜时，要考虑半个小时，并且不让服务员离开，因为他有很多问题向服务员咨询。结账时，因为要拿去衙门报销，需要开发票，又需要服务员帮忙写发票抬头，打印，最后还不忘找服务员要停车票。

这个问题正好就是NIO模型的缺点，这种模型由于IO在阻塞时会一直等待，因此在用户负载增加时，性能下降的非常快。server导致阻塞的原因有：

1、serversocket的accept方法，阻塞等待client连接，直到client连接成功。

2、线程从socket inputstream读入数据，会进入阻塞状态，直到全部数据读完。

3、线程向socket outputstream写入数据，会阻塞直到全部数据写完

既然能发现缺点，就有相应的解决办法，聊过非阻塞IO后， 再来看看异步IO（AIO）。 IO方面的概念很多，阻塞性与异步性是其关键概念。简单而言，凡是需要由应用程序将数据读写到应用程序内存中的IO，都是同步IO，比如上面的BIO与NIO。相对的，凡是由OS来完成读写的，就是异步IO。这个说法有些迷惑，举例而言，在NIO中，当应用程序检测到某个Channel有可读数据时，必须显式发起一个read请求。而在异步IO中，应用程序仅仅需要告诉OS，我需要什么数据，并提供给OS一个Buffer和一个回调。OS会自己检测Channel的可读性，当发现其可读，会自动将数据复制到Buffer中，并通知应用程序任务完成。异步IO的典型实现是NodeJS。显然，由于将任务进一步下发到了OS，应用程序的可伸缩性及性能会大大增强。并且，比起非阻塞的NIO，异步IO编程更加容易一些, 性能也基本上总是优于它。

有了这一理论基础，可以继续讲大嘴的故事。

不到一年，小龙虾生意一发不可收拾，店里的营收越来越可观，王五的老婆也用上了iPhoneX和ipad pro，但王五的老婆一直想买一辆BMW，在得知ipad里面有很多点餐的APP后，她对大嘴说：其实咱们店只需要一个服务员就可以了，张三和李四完全是多余的，把他们俩的钱给我，我一个人可以服务所有客人。大嘴表示怀疑：咱们店一天接待几十桌客人，你一个人怎么忙得过来？

王五的老婆说，咱们店里所有的工作分为两类：

1.马上就能干完的，例如接待，找座，下单，清理桌子等

2.需要等别人干完才能干的活，比如点菜（需要顾客想好吃什么），上菜（需要后厨做好），结账（需要顾客确认账单、买单）等。

对于第1类工作，我马上干活，对于第2类工作，我也不会等待，我只要告诉别人，你弄完了告诉我一声，我会接着干，然后马上去做第1类工作。比如点菜，我只要给客人一个ipad，给完ipad我就立刻离开，客人点完餐后叫我，我只要点确认下单即可。结账时，我只要给客人一张带二维码的消费清单小票，我就立刻离开，客人确认完消费清单，自己扫描二维码进行支付，结账完毕后，叫我过来确认即可，我顺便把桌子打扫了，如果顾客需要发票，可以去前台凭小票自助打印，不需要服务员参与。

王五的老婆说的这一套，正是jdk7引入的NIO2模型，又叫异步IO（AIO）。为了说明异步IO，用计算机视角再回顾一下店里的服务流程：

服务员：线程

顾客：http请求

后厨做菜，客人吃饭：耗时的IO操作

后厨大喊一声上菜：这是一个长时间IO操作完成后所发出的事件

客人说结账：另外一个长时间IO操作完成后所发出的事件

第一类工作(迎客，找座，下单) : 在服务器端的业务逻辑代码，能够快速执行。

第二类工作(上菜，结账) : 同样是能快速执行的代码，但是他们需要等待那些耗时的IO 操作完成才能开始，确切的来说，收到了系统发出的事件以后才开始执行。在AIO中实际上是在回调函数中来执行的：

下面是AIO服务模式的伪代码：



后厨处理（）这个函数接受两个参数，一个是事件名，另外一个是匿名的回调函数，事件发生，回调函数才会执行。客人吃饭（）函数也是类似。

王五的老婆接着说，我的秘诀就是不等待，耗时的操作全部使用异步方式，别人做完了再通知我。大嘴听了目瞪口呆，原来饭店可以这样开，一旦拥有这种服务效率，明年利润再翻一番不是问题，后年可以赴港交所上市了。

总结上述几种IO模型，将其功能和特性进行对比：



虽然AIO有很多优势，但并不意味着所有Java网络编程都必须选择AIO，具体选择什么IO模型或者框架，还是要基于业务的实际应用场景和性能诉求，如果客户端并发连接数不多，服务器的负载也不重，则完全没必要选择AIO做服务器，毕竟AIO编程难度相对BIO来说更大。