BIO,即阻塞IO,在基于Socket的消息通信过程中,Socket服务端向外部提供服务,而Socket客户端可以建立到Socket服务端的连接,进而发送请求数据,然后等待Socket服务端处理,并返回处理结果(响应)。
基于BIO的通信,Socket服务端会发生阻塞,即在监听过程中每次accept到一个客户端的Socket连接,就要处理这个请求,而此时其他连接过来的客户端只能阻塞等待。可见,这种模式下Socket服务端的处理能力是非常有限的,客户端也只能等待,直到服务端空闲时进行请求的处理。
BIO通信实现
下面基于BIO模式,来实现一个简单的Socket服务端与Socket客户端进行通信的逻辑,对这种通信方式有一个感性的认识。具体逻辑描述如下:
1、Socket客户端连接到Socket服务端,并发送数据“I am the client N.”;
2、Socket服务端,监听服务端口,并接收客户端请求数据,如果请求数据以“I am the client”开头,则响应客户端“I am the server, and you are the Nth client.”;
Socket服务端实现,代码如下所示:
上述实现,没有进行复杂的异常处理。
Socket客户端实现,代码如下所示:
首先启动Socket服务端进程SimpleBioTcpServer,然后再运行Socket客户端SimpleBioTcpClient。可以看到,服务端接收到请求数据,然后响应客户端,客户端接收到了服务端的响应数据。
上述实现中,对于Socket客户端和服务端都是一次写入,并一次读出,而在实际中如果每次通信过程中数据量特别大的话,服务器端是不可能接受的,可以在确定客户端请求数据字节数的情况,循环来读取并进行处理。
另外,对于上述实现中流没有进行装饰(Wrapped)处理,在实际中会有性能的损失,如不能缓冲等。
对于Socket服务端接收数据,如果可以使多次循环读取到的字节数据通过一个可变长的字节缓冲区来存储,就能方便多了,可是使用ByteArrayOutputStream,例如:
BIO通信测试
下面测试一下大量请求的场景下,Socket服务端处理的效率。
第一种方式:通过for循环来启动5000个Socket客户端,发送请求,代码如下所示:
经过测试,大约需要9864ms,大概接近10s。
第二种方式:通过启动5000个独立的客户端线程,同时请求,服务端进行计数:
经过测试,大约需要7110ms,大概接近7s,没有太大提高。
BIO通信改进
通过上面的测试我们可以发现,在Socket服务端对来自客户端的请求进行处理时,会发生阻塞,严重地影响了能够并发处理请求的效率。实际上,在Socket服务端接收来自客户端连接能力的范围内,可以将接收请求独立出来,从而在将处理请求独立粗话来,通过一个请求一个线程处理的方式来解决上述问题。这样,服务端是多处理线程对应客户端多请求,处理效率有一定程度的提高。
下面,通过单线程接收请求,然后委派线程池进行多线程并发处理请求:
可见,这种改进方式增强服务端处理请求的并发度,但是每一个请求都要由一个线程去处理,大量请求造成服务端启动大量进程进行处理,也是比较占用服务端资源的。