Java003 高并发场景下Bio与Nio的比较及原理示意图

高并发场景下BioVsNio

本文将从以下四点梳理一下Bio和Nio的相关知识：

l Bio的技术代码逻辑实现

l 高并发场景下Bio存在的弊端

l Nio的技术实现原理

l 高并发场景下Nio相较于Bio的优势

假设是用部署在Linux操作系统上的Tomcat配置的java应用程序。

1.Bio属于传统网络编程处理连接以及数据传输的方式，技术代码逻辑实现大致如下：

1)一个BioServerTest(服务端启动服务的main主方法入口所在类，监听是否有客户端接入请求，有的话创建线程开始业务处理)

ServerSocket.bind(ip+port);//绑定ip+port，以便监听客户端向此ip+port发起的连接请求

while(server is Run){

Socket socket= ServerSocker.accept();

new Thread(new BioServerTask(socket)).start(); 

}

2)一个BioServerTask extends Thread(收到客户端请求后进行具体业务处理的一个线程类)

InputStream.read (data)//读取客户端发送的数据

3)一个BioClient(客户端，向服务器监听的IP+Port发送请求)

Socket(ip+port)//向指定ip+port发起连接请求

OutputStream.writer(data//往指定ip+port发送数据

2.高并发场景下Bio存在的弊端就会被暴露出来：

1)首先在ServerSocket.accpet()时就会发生阻塞，如果没有客户端连接请求，服务器会一直被阻塞在这里什么也做不了(不优雅高效)；

2)其次，当接收到一个客户端请求后，服务端会创建一个业务处理线程进行具体业务处理，而new Thread这个操作比较耗时(需要jvm分配一段内存空间)。假设并发量为50000qps(query per seconds 每秒请求数)，创建一个线程耗时为0.0001s，将数量级同步缩小一千倍，并发量50qps，耗时0.1s,相当于在这被消耗的0.1s的时间窗口内，请求只能等待，暂时得不到处理。单位再换算以下，1s有50个请求=0.1s有5个请求,在这被线程创建所消耗的0.1s内有5个左右的请求同时到达，服务器只能处理其中一个，其余4个请求丢失了。

Tomcat默认配置下能支持100-150qps并发量，当并发量在150-300qps时会出现200ms延迟，当并发量超过300qps时会出现500ms延迟并伴随部分连接丢失。

3)在进行具体业务处理时，先要把客户端发送的数据接收过来，接收数据的过程中会出现阻塞和二级复制，高并发场景下效率也不高，可能会影响用户体验:

  (1)阻塞出现在InputStream.read()这个方法，此方法要求数据完整性，要一次性将数据传输过来，在传输过程中程序会卡住;

  (2)二级复制的产生过程：与服务器建立连接后，客户端向服务器传输数据，数据首先经过基于HTTP协议的网络层复制到Linux操作系统(将数据复制到Linux Kernel的缓冲区，一次只接收一部分数据，像个小杯子，而不是一次性接收全部数据)，JVM再把数据从内核复制到JVM中(JVM不断从内核缓冲区(小杯子)里取出数据最后组成完整数据)，应用程序从JVM中读取数据。过程比较复杂，数据传输效率也不高。示意图如下：

3.Nio中的连接和数据传输都基于事件处理。

1）服务端不必一直去监听是否有客户端发起连接请求接着再去进行具体业务逻辑处理，而是通过事件注册、事件轮询器和事件通知的这一整套事件处理机制，将服务器从原先一直处于的监听状态中给解放出来。

2）每次收到一个客户端连接请求后也不必再去创建新的线程去进行业务处理，对每个连接请求处理在一个连接池中统一管理，当进行业务处理所需的条件/状态事件准备好时(比如数据可读),事件处理机制会通知处于连接池中的某个连接请求进行后续处理。

3）数据传输时服务器也不会因为一次读取不到完整数据而产生阻塞(当数据传输完毕可读取的时候，会被当作一个事件通知服务器，这时服务器再去读取数据)。

4）客户端与应用程序进行数据传输时，可通过Nio提供的一个叫buffer的东西经由Channel(管道，双向可读可写，可以异步读写，通道中的数据总是要先读到一个buffer或总要先从一个buffer写入)与Linux Kernel缓冲区进行直接的读写实时数据操作(这个buffer应该具有将读取到的一块块数据依据某些信息组合成完整数据且能保证数据正确性的一些功能)，这样就避免了两级复制。

Nio基于事件机制对客户连接请求及数据传输的逻辑处理示意图如下：