关于InputStream.read()方法的阻塞原理的测试
最近在一家公司做java实习,写了个网络字节采集器。写了个单例TCPServer来采集数据,其中用到了InputStream.read()来读取数据。产生了一系列问题,下面做下总结:
关于while((length = is.read(data)) != -1)问题。
在写此方法时,产生了一些疑惑,read何时阻塞?何时返回值-1?
首先做个假设:
1、读不满data的length就一直阻塞。为此,做了以下实验:
Server端:
byte[] data = new byte[8];
while((length = is.read(data)) != -1){
String result = new String(data);
System.out.println(result);
System.out.println("length:" + length);
}
客户端:
String msg = "ab";
byte[] byteMsg = msg.getBytes();
Socket socket = new Socket("127.0.0.1", 9999);
OutputStream out = socket.getOutputStream();
BufferedOutputStream bw = new BufferedOutputStream(out);
for (int i = 0;i<10;i++) {
bw.write(byteMsg);
bw.flush();
}
发现服务端在length=2时,就输出了,结果为ab。说明并不是在data读不满时就一直阻塞。
2、那么是不是跟flush()有关呢?
下面将bw.flush()注视,发现,并追加代码Thread.sleep(5*1000),让它每次输出2个字节后暂停5秒,以达到网络很差的目的。发现服务端每次输出abababab 8个长度的字节。则可以判定跟flush有关。
3、那什么时候缓冲区的数据会flush呢?
和另一网络组的程序对接读数据,他每次都发送148个字节长度的数据,并循环一直发,而我这边依次解析148长度的数据。但发现时间久了数据就会对不拢。分析错误数据发现是没有读完148,而下次再读时将剩余没读完的部分加在了本次的头部,固然出错。于是有个疑问:我这边每次都是读148个字节,然后处理,为什么会有读不满148的情况?根据前两个的测试,初步判断跟flush有关。可能是网络层数据缓冲区在数据量超过一定范围时自动flush了。测试如下:
客户端:
String msg = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+ "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
byte[] byteMsg = msg.getBytes();
try {
Socket socket = new Socket("127.0.0.1", 9999);
OutputStream out = socket.getOutputStream();
BufferedOutputStream bw = new BufferedOutputStream(out);
for (;;) {
bw.write(byteMsg);
//这里不进行程序flush,一直发。
}
服务端:
int count = 1000000;
is = socket.getInputStream();
byte[] data = new byte[count];
int length = 0;
while((length = is.read(data)) != -1){
String result = new String(data);
System.out.println(result);
System.out.println("length:" + length);
}
发现输出如下:
aaaaaaa..............行太长
length:39960
aaaaaaa..............行太长
length:23976
aaaaaaa..............行太长
length:23976
aaaaaaa..............行太长
length:24745
aaaaaaa..............行太长
length:25435
aaaaaaa..............行太长
length:21748
说明网络层缓冲区在长度一定时,就自动flush,但是这个长度好像不是很固定。长度取决于什么现在还不清楚。
关于InputStream.read()方法的阻塞原理的测试的更多相关文章
- [Android Pro] 关于inputStream.available()方法获取文件的总大小
reference to :http://hold-on.iteye.com/blog/1017449 如果用inputStream对象的available()方法获取流中可读取的数据大小,通常我们调 ...
- (判断url文件大小)关于inputStream.available()方法获取下载文件的总大小
转自:http://hold-on.iteye.com/blog/1017449 如果用inputStream对象的available()方法获取流中可读取的数据大小,通常我们调用这个函数是在下载文件 ...
- Sleeping会话导致阻塞原理(下)
背景 最近给客户做优化时,有几个客户都存在.SLEEPING 会话中开启了事务,导致的大量阻塞,从而产生严重的性能问题.虽然在之前的文章我分享了Sleeping会话导致阻塞原理(上) .说明了什么是S ...
- 机器学习中模型泛化能力和过拟合现象(overfitting)的矛盾、以及其主要缓解方法正则化技术原理初探
1. 偏差与方差 - 机器学习算法泛化性能分析 在一个项目中,我们通过设计和训练得到了一个model,该model的泛化可能很好,也可能不尽如人意,其背后的决定因素是什么呢?或者说我们可以从哪些方面去 ...
- 深入理解java中的底层阻塞原理及实现
谈到阻塞,相信大家都不会陌生了.阻塞的应用场景真的多得不要不要的,比如 生产-消费模式,限流统计等等.什么 ArrayBlockingQueue, LinkedBlockingQueue, Delay ...
- KafkaConsumer 长时间地在poll(long )方法中阻塞
一,问题描述 搭建的用来测试的单节点Kafka集群(Zookeeper和Kafka Broker都在同一台Ubuntu上),在命令行下使用: ./bin/kafka-topics. --replica ...
- DisplayNameFor()方法的工作原理
DisplayNameFor()方法的工作原理原创Peter Yelnav 最后发布于2018-11-23 11:09:51 阅读数 1308 收藏展开最近研究了一下ASP.NET MVC,困惑于视图 ...
- JVM系列-方法调用的原理
JVM系列-方法调用的原理 最近重新看了一些JVM方面的笔记和资料,收获颇丰,尤其解决了长久以来心中关于JVM方法管理的一些疑问.下面介绍一下JVM中有关方法调用的知识. 目的 方法调用,目的是选择方 ...
- go-micro开发RPC服务的方法及其运行原理
go-micro是一个知名的golang微服务框架,最新版本是v4,这篇文章将介绍go-micro v4开发RPC服务的方法及其运作原理. 基本概念 go-micro有几个重要的概念,后边开发RPC服 ...
随机推荐
- windows下的文件到linux下乱码 iconv 修改文件编码
conv [选项...] [文件...] 有如下选项可用: 输入/输出格式规范:-f, --from-code=名称 原始文本编码-t, --to-code=名称 输出编码 信息:-l, --list ...
- [Educational Codeforces Round 16]D. Two Arithmetic Progressions
[Educational Codeforces Round 16]D. Two Arithmetic Progressions 试题描述 You are given two arithmetic pr ...
- [BZOJ1998][Hnoi2010]Fsk物品调度
[BZOJ1998][Hnoi2010]Fsk物品调度 试题描述 现在找工作不容易,Lostmonkey费了好大劲才得到fsk公司基层流水线操作员的职位.流水线上有n个位置,从0到n-1依次编号,一开 ...
- 使用caffe自动测试模型top5的结果
方法很简单,直接在定义网络的prototxt里面最后加一层就可以了. 这一层定义如下 layer { name: "accuracy_5" type: "Accuracy ...
- Javascript之十大常用原理性样例大总结
案例一:全选等 运用知识点:ondblclick=()| onclick | 寻找标签属性及判断和函数的应用
- ubuntu 修改保存报错E37:No write since last change(add ! to override)的解决方法
报错信息如下: E37: No write since last change (add ! to override) 解决办法是: 在修改完后,将命令 :q 改成 :wq 即可.
- systemd在各个linux发行版的普及
后面我要说下自己的意见: 原则如果阻碍了进步,那还算个屁,不客气地说,UNIX 原则已经过时了. 移植性问题:我除了 Mac 外不用任何 BSD 系统,当然 Mac 上一般只做开发不做运维(但就算如此 ...
- qcow2文件压缩
qemu-img convert -O qcow2 /path/old.img.qcow2 /path/new.img.qcow2 转自:https://havee.me/linux/2011-09/ ...
- Ubuntu删除history记录
history -c就是清除本次登录到目前所执行的命令 转自: http://www.linuxdiyf.com/viewarticle.php?id=189355
- 全面解释StringBuilder、StringBuffer和String的关系
1. String 类 String的值是不可变的,这就导致每次对String的操作都会生成新的String对象,不仅效率低下,而且大量浪费有限的内存空间. String a = " ...