网络-BIO-伪异步I/O

为了解决同步阻塞I/O面临的一个链路须要一个线程处理的问题，后来有人对它的线程模型进行了优化，后端经过一个线程池来处理多个客户端的请求接入，造成客户端个数M：线程池最大线程数N的比例关系，其中M能够远远大于N，经过线程池能够灵活的调配线程资源，设置线程的最大值，防止因为海量并发接入致使线程耗尽。

伪异步I/O模型图

采用线程池和任务队列能够实现一种叫作伪异步的I/O通讯框架，它的模型图以下：

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

伪异步I/O的主函数代码发生了变化，咱们首先建立一个时间服务器处理类的线程池，当接收到新的客户端链接的时候，将请求Socket封装成一个Task，而后调用线程池的execute方法执行，从而避免了每一个请求接入都建立一个新的线程。

当对Socket的输入流进行读取操做的时候，它会一直阻塞下支，直到发生以下三种事件：

• 有数据可读；

• 可用数据已经读取完毕；

• 发生空指针或者I/O异常；

这意味着当对方发送请求或者应答消息比较缓慢，或者网络传输比较慢时，读取输入流一方的通讯线程将被长时间阻塞，若是对方要60s才可以将数据发送完成，读取一方的I/O线程也将会被同步阻塞60s，在此期间，其余接入消息只能在消息队列中排队。

当调用OutputStream的write方法写输出流的时候，它将会被阻塞，直到全部要发送的字节所有写入完毕，或者发生异常。学习过TCP/IP相关知识的人都知道，当消息的接收方处理缓慢的时候，将不能及时地从TCP缓冲区读取数据，这将会致使发送方的TCP window size不断减少，直到为0，双方处于Keep-Alive状态，消息发送方将不能再向TCP缓冲区写入消息，这时若是采用的是同步阻塞I/O，write操做将会被无限期阻塞，直到TCP window size大于0或者发生I/O异常。

经过对输入和输出流的API文档进行分析，咱们了解到读和写操做都是同步阻塞的，阻塞的时间取决于对方I/O线程的处理速度和网络I/O的传输速度。

伪异步I/O实际上仅仅只是对以前I/O线程模型的一个简单优化，它没法从根本上解决同步I/O致使的通讯线程阻塞问题。下面咱们就简单分析下若是通讯对方返回应答时间过长，会引发的级联故障：

1. 服务端处理缓慢，返回应答消息耗费60s，平时只须要10s。

2. 采用伪异步I/O的线程正在读取故障服务节点的响应，因为读取输入流是阻塞的，所以，它将会被同步阻塞60s。

3. 假如全部的可用线程都被故障服务器阻塞，那后续全部的I/O消息都将在队列中排队。 
   

4. 因为线程池采用阻塞队列实现，当队列积满以后，后续入队列的操做将被阻塞。

5. 因为前端只有一个Accptor线程接收客户端接入，它被阻塞在线程池的同步阻塞队列以后，新的客户端请求消息将被拒绝，客户端会发生大量的链接超时。

6. 因为几乎全部的链接都超时，调用者会认为系统已经崩溃，没法接收新的请求消息。