搭建Demo验证在一次Socket请求中有借助缓冲区处理数据

文章目录

1、编写socket通信消费端
2、编写socket通信生产端
3、测试结果
4、其他

在我的上一篇博客——浅谈Tomcat接收到一个请求后在其内部的执行流程的第二章中提到了一个操作系统的缓冲区概念，位置如下图所示。

即浏览器发送请求后，数据是先存放到一个缓冲区，如果tomcat想要使用对应的数据，就是用相应的API去缓冲区中获取数据，即使用我们熟悉的inputStream.read进行获取。下面我将使用一个小案例来验证对应的缓冲区的存在。

1、编写socket通信消费端

public class TestServerSocket {public static void main(String[] args) throws IOException {// 1、增加一个8089的服务端口ServerSocket socket = new ServerSocket(8089);Socket accept = socket.accept();// 2、在键盘未输入前阻塞（用于验证后续方法的作用）System.in.read();// 3、获取接收到的数据流InputStream inputStream = accept.getInputStream();while (true) {// 4、使用一个死循环，不断的在接收到的数据流中读取数据，每次读取10000个字节byte[] bytes = new byte[10000];// 5、readLength 表示单次读取到的数据长度int readLength = inputStream.read(bytes);// 6、将获取到的数据以字符串的形式打印在控制台System.out.println(new String(bytes, 0, readLength));}}
}

2、编写socket通信生产端

public class TestSocket {public static void main(String[] args) throws IOException {// 1、向本地的8089端口发送数据（即和服务端匹配）Socket socket = new Socket("localhost", 8089);// 2、拿到我们即将要发送的输入流OutputStream stream = socket.getOutputStream();// 3、使用一个死循环，不断的向对应的服务端发送数据，即向输入流中写数据for (int i = 0; ; i++) {stream.write(String.valueOf(i).getBytes("UTF-8"));// 4、在控制台打印当前时间和数据，方便查看效果System.out.println(LocalTime.now());System.out.println(i);}}
}

3、测试结果

场景一：首先启动服务端，再启动客户端

根据测试结果，我们不难发现，测试结果后面的输出越来越慢。

我们使用Java的API进行数据的写入写出，两个Java类，好比两个请求，当请求的数据到达一定的量后，请求就会卡住，好像请求不动了。

这种请求不动，是否就可以理解为到达了某种阈值，好比把东西放在一个房间，房间的东西没有被拿走，那么房间能发的东西就越来越少。Java之上是JVM，JVM直接和操作系统进行交互，按照前面的分析，这个“房间”，要么是在JVM里面，要么是在操作系统里面，反正至少有一个地方有（至于是哪一个，我目前还不确定，这也从侧面表示，我之前说缓冲区是在操作系统是不准确的）。

场景二：在场景一的基础上，我在服务端，随便输入一个字符串（跳过阻塞，进入while循环，读取数据）

此时服务端不断的获取客户端发送过来的数据，客户端又能够源源不断的发送数据了，如下图所示。

还是上面的房子，房间两个门，一个人放，一个人取，并且取的速度大于等于放的速度，自然就不会出现房子装满的情况，即能够源源不断的写入数据。

4、其他

我们还能够通过这个案例，测试一下，我们服务端接受到的数据是什么样子。即开启服务端，使用浏览器发起一次请求

浏览器请求地址：http://localhost:8089/master/activity/list?pageNum=1&pageSize=10

此时控制台打印出的信息就是浏览器请求的详细信息（去掉了read的阻塞）。

这里又不得不再次提到我的上一篇文章——浅谈Tomcat接收到一个请求后在其内部的执行流程。在第三章第4节的地3条，即tomcat内部会对接受到的请求进行相应的解析处理（如下图）。对照上面测试的tomcat接收到的数据，你是不是就能更加理解tomcat解析的是什么了？