前言
在开始这篇文章之前想先说一句:如果一套零碎临时没问题,那只是因为它的并发量不够而已。
上周在查看系统日志时,发现了一条不同凡响的日志。日志中有一半内容是失常的报文数据,而另一半内容是0x00这样的空数据。
尽管零碎没抛出任何异样,但这些日志必定是反常的。多年的教训通知我,这其中肯定有什么不对的中央,加上好奇心的驱使,终于揭开了一个暗藏十分深的Bug。
有时候找到Bug,解决Bug很容易,难的是如何发现Bug,并推理出哪里出问题解决。上面就带大家来分析一下这个Bug。
奇怪的日志输入
一个调用内部接口的根底类,打印出相似如下的日志:
abcdabcdabcdabcdabcdabcdabcd<0x00><0x00><0x00><0x00><0x00>
其中后面的abcd是失常的业务数据,前面莫名其妙的多出了很多<0x00>
。
那么,这个根底工具类有多根底?多处应用该办法,每天大概被调用几十万次吧,而下面的状况一天只会呈现几次。就是那么巧,恰好被看到了。
查看代码,初步推断,可能是byte数组转String时,byte数组后半部分为空或存在一些无奈转换的数据导致的。
旧代码剖析
这里先把业务代码脱敏,写成一个demo展现给大家看看:
public static void oldCode() throws IOException { // 通过HttpURLConnection读取的内部零碎返回的流 InputStream in = new ByteArrayInputStream("abc".getBytes()); // 明确晓得的报文长度(解析Header取得) int bodyLen = 2048; byte[] body = new byte[bodyLen]; int recvLen = 0; while (recvLen < bodyLen) { recvLen = in.read(body, recvLen, bodyLen - recvLen); if(recvLen == -1){ break; } } System.out.println(new String(body, "GBK"));}
上述代码进行了业务脱敏解决,仅为还原根本的应用过程。
业务场景的大略应用流程是:第一,通过HTTP调用近程接口;第二,读取接口返回的字节流,Inputstream;第三,解析字节流,存入字节数组;第四,将字节数组转换为String。
而日志中看到的异样内容,便是打印String时呈现的。后面咱们曾经推断,呈现<0x00>
的可能性是字节数组有一部分为空导致或数据谬误导致的。
上述代码有一个显著的谬误,你是否可能看进去?依据代码原始的写法,揣测之所以呈现这个谬误是因为使用者对InputStream的read办法并不相熟导致的。
这里读者先自行浏览看看上述代码的Bug在哪里,上面咱们来介绍一下InputStream的read办法。
InputStream的read办法
InputStream这个抽象类是示意字节输出流的所有类的超类,它提供了3个常常被应用的read()办法:
- read(),无参办法。该办法从输出流中读取数据的下一个字节。返回0到255范畴内的int字节值。如果因为曾经达到流开端而没有可用的字节,则返回值 -1 。该办法会处于阻塞状态,期待数据的达到,直到返回值为-1或抛出异样。
- read(byte b[], int off, int len):将输出流中最多len个数据字节读入byte数组。尝试读取len个字节,但读取的字节也可能小于该值。以整数模式返回理论读取的字节数。
- read (byte[] b):从输出流中读取肯定数量的字节,并将其存储在缓冲区数组b中。以整数模式返回理论读取的字节数。
剖析一下下面的三个办法。
其中第一个办法,实质上来说后两个办法都是调用第一个办法来实现的,但第一个办法间接应用毛病很显著,就是解决效率低下,一个字节一个字节的读。而后两个办法都退出了byte数组,用来作为缓存区。
而第三个办法又相当于第二个办法被如下形式调用:
read(b, 0, b.length)
而有Bug的代码中应用的是第二个办法。
Bug剖析
看了read办法的API阐明,你是不是曾经找到Bug了?对的,当初写这段代码的人把read办法返回值了解错了。
recvLen = in.read(body, recvLen, bodyLen - recvLen);
最后写代码的人可能把read办法的返回值当中参数off通过读取之后新的地位了。这样在调用read办法之后,取得了填充的地位,而后拿总长度减去曾经填充的地位,再持续读取前面的内容,持续填充。
但实际上read办法的返回后果是:以整数模式返回理论读取的字节数,可能与off的地位值雷同,但并不是off的地位。
上面来剖析一下while循环中的逻辑解决状况:
while (recvLen < bodyLen) { recvLen = in.read(body, recvLen, bodyLen - recvLen); if(recvLen == -1){ break; }}
咱们举个例子来推演一下2种状况(为了不便推算,暂且用比拟小的数来举例)。
状况一:假如bodyLen长度为10,read一次性读完。
在这种状况中,先进入while循环,read一次性读完,返回值为10,此时recvLen赋值为10,不再满足循环条件(recvLen < bodyLen),退出循环,继续执行。此时,代码没问题。这种状况可能占到99.9%-99.99%(取决于申请频次和报文大小)。
状况二:假如bodyLen长度为10,read 2次读完(产生粘包拆包景象)。
第一次循环,read读取6个字节长度,返回值为6,recvLen赋值为6。第二次循环,off参数取recvLen的值为6,读取残余4个字节(10 - 6)。实现第二次读取,循环本应该完结的,但你会发现此时recvLen被赋值为4,仍旧满足while循环的判断条件(recvLen < bodyLen),进行下一轮读取。
下一轮读取时,off变为4,len变为(10 - 4)。原本通过第二轮循环off曾经读取到10了,当初又指定为4,又去流中读取。这就造成了日志中呈现很多<0x00>
。
Bug起因
通过上述剖析,咱们曾经找到Bug,并取得了Bug起因。
首先,Bug之所以没有大面积暴发,那是因为大多数申请都是一次性读完流中的数据,循环间接完结,当不会进入第二次循环时,这个Bug就被暗藏了。
其次,Bug之所以产生除了使用者对API的返回值不理解,更重要的起因是对于read办法可能会将后果分屡次返回(粘包拆包景象)不理解。
Bug革新
找到起因,革新起来就非常容易了。针对demo咱们从新革新一下:
public static void oldCode() throws IOException { // 通过HttpURLConnection读取的内部零碎返回的流 InputStream in = new ByteArrayInputStream("abc".getBytes()); // 明确晓得的报文长度(解析Header取得) int bodyLen = "abc".getBytes().length; System.out.println(bodyLen); byte[] body = new byte[6]; int recvLen = 0; while (recvLen < bodyLen) { // 革新点1 int currentLen = in.read(body, recvLen, bodyLen - recvLen); if(recvLen == -1){ break; } // 革新点2 recvLen += currentLen; } System.out.println(new String(body, "GBK"));}
上述革新只改变了两处,将read办法的返回值用新变量接管,而后让recvLen每次累加read读取的字节数。
革新是不是非常简单?正应了那句话:改bug很容易,难的是如何找到bug。
小结
有时候咱们对本人写的代码很自信,有时候总以为代码之前可能失常运行,当前也可能失常运行。但往往大失所望,谁能想到始终“运行良好”的代码中深藏着这样的Bug?所以,还是那句话,如果你感觉你的代码没问题,那只是因为零碎的并发量还不够而已。代码不仅要实现性能,还要满足性能和健壮性。
博主简介:《SpringBoot技术底细》技术图书作者,热爱钻研技术,写技术干货文章。
公众号:「程序新视界」,博主的公众号,欢送关注~
技术交换:请分割博主微信号:zhuan2quan