前言
在开始这篇文章之前想先说一句：如果一套零碎临时没问题，那只是因为它的并发量不够而已。
上周在查看系统日志时，发现了一条不同凡响的日志。日志中有一半内容是失常的报文数据，而另一半内容是 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