阻塞式IO通信

一、BIO通信介绍

网络编程的基本模型是Client/Server模型,也就是两个进程之间进行相互通信,其中服务端提供位置信息(绑定的IP地址和监听端口),客户端通过连接操作向服务端监听的地址发起连接请求,通过三次握手建立连接,如果连接建立成功,双方就可以通过网络套接字(Socket)进行通信。在基于传统同步阻塞模型开发中,ServerSocket负责绑定IP地址,启动监听端口;Socket负责发起连接操作。连接成功之后,双方通过输入和输出流进行同步阻塞式通信。

先看一下BIO通信模型,采用BIO通信模型的服务端,通常由一个独立的Acceptor线程负责监听客户端的连接,它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理,处理完成之后,通过输出流返回应答给客户端,线程销毁。这就是典型的一请求一应答通信模型。

该模型最大的问题就是缺乏弹性伸缩能力,当客户端并发访问量增加后,服务端的线程个数和客户端并发访问数呈1:1的正比关系,由于线程是Java虚拟机非常宝贵的系统资源,当线程数膨胀之后,系统的性能将急剧下降,随着并发访问量的继续增大,系统会发生线程堆栈溢出、创建新线程失败等问题,并最终导致进程宕机或者僵死,不能对外提供服务。

二、代码实例

2.1 服务端

TimeServer.java 主线程,监听端口的线程

TimeServerHandler.java 子线程,处理客户端请求的线程

启动TimeServer,可以看到打印:

此时因为没有客户端接入,主线程阻塞在socket = server.accept();通过Java VisualVM打印线程堆栈,可以看到主程序确实阻塞在accept操作上:

2.2 客户端

TimeClient.java 客户端请求socket通信

启动客户端,打印:

服务端打印:

这样就完成了一次socket通信。

三、遇到的问题

3.1 server阻塞

问题现象:

客户端没有拿到返回值,通过Java VisualVM打印线程堆栈发现服务端阻塞在了body = in.readLine();

这里有个疑问,既然阻塞在readLine处为什么线程的状态还是RUNNABLE呢?这是因为这里的阻塞是IO阻塞,不是线程阻塞,这是两个概念,IO阻塞一般不会造成线程阻塞,至于IO阻塞中线程会不会占用CPU应该是有系统底层的线程调度决定,比如在Linux中等待IO的过程中线程不会占用CPU,知道IO完成会唤醒线程重新抢夺CPU时间片。

参考:I/O会一直占用CPU吗?https://www.zhihu.com/question/27734728

原因分析:

后来发现是因为客户端没有进行flush操作(最开始的时候忘记写out.flush();),导致服务端阻塞在readline处。flush方法刷新输出流并强制将所有缓冲的输出字节被写出。

四、伪异步IO

为了解决一个线程维护一个连接的问题,我们可以通过线程池来维护连接,这样就可以控制线程的数量,灵活地调配线程资源,防止由于海量并发接入导致系统线程耗尽。通信模型如下:

4.1 代码实现

只需要将上面的TimerServer新建线程的地方改为线程池即可:

运行结果以上面一样。伪异步I/O实际上仅仅是对之前I/O线程模型的一个简单优化,它无法从根本上解决同步I/O导致的通信线程阻塞问题。

Last updated

Was this helpful?