前言
时间的车轮一直向前不停，试图在时光洪流中碾碎一些久远的记忆。虽然记忆中的人离我越来越远，但是故事却越来越深刻。
当在博客园看到这次的正文题目是“最难忘的bug”，脑海里瞬间浮现起到2017年的11月8号那天。真的很快，已经过去四年了，这么多年，在Java开发、大数据开发中遇到过形形色色、自认为不可能发生的Bug，也曾伤过神、生过气，但最终只是成为了工作经验的给养。但惟有那次很小的一个bug，让我记忆犹新。
那次，改变了我对工作、责任的认知，让我有了团队归属感。那时候的我还是一个只会一点Java的实习生，现在已然成为三年经验的大数据从业者了。
问题
"测试"，"升级"，"割接"。2017年11月8日，这三个名词第一次出现在我的认知里，第一次实践在工作中。
从七月份进入公司实习以来，一直在整理各种文档，后来承担了大数据部分运维的工作。那时候的感觉就是，开发的理想真的离我越来越远。
升级目标
当时是做信令数据的接入，20多种信令，每种信令有50 ~ 100个字段。对端厂家根据规范将每个字段转换成二进制格式，例如unsigned int、int、double、byte、short各种数据类型。
这样的话，每种信令数据根据包含字段的数据类型，就可以计算出长度，然后放入byte[]或者byteBuffer中。例如byte类型就占1个字节，int类型占用4个字节。
根据定义的传输规范，我们将一个数据包分为包头和包体。根据包头可以区分出包体里面是响应数据还是应答数据，然后将包体内的二进制数据解析成对应类型明文即可。
此次升级除了字段个数增加，之前老版本中一个包体中只有一条数据，也修改成一个包体会有N条不同协议的数据。
问题
11月8日晚六点，组长对旁边的大佬说：“测试怎么样？"
大佬：“测试地没啥问题。”后来才知道和对端联调的时候没有测试充分。
那天的我本来是可以下班走的，然后我的第一任项目经理就叫住了我，让我积极参（chong）与（shu）一下。作为一个实习生，那时候正好在自学Java、大数据，加上也不敢拒绝，就留下陪他们加班。
然后晚上11点割接的时候，二进制数据解码后写入Kafka的数据先开始正常，接着就是齐刷刷的乱码，然后就大家就慌了，就开始找问题。
我们三个人都挤在一个工位上，大佬在中间找问题，我和组长就在一人一旁地看着。
乱码分析
那时候我连这个程序是干啥的都不知道，也准备躺平了。刚实习哪见过几千行的代码，就一愣一愣的看着他们在翻着程序。
凌晨五点的时候，我和组长就发现每个协议的解码方法中off变量都是作为形参进来的。
-
先解析包头内容，来确定包体中有多少条数据，这里对应的是totalContents。
-
解析每条协议数据公共部分，一共占54个byte。
-
根据上面的lte_type来区分是哪个协议的数据，然后传入到对应的方法中对字段进行解码。下面是模拟之前老程序中一个协议数据的解析代码逻辑。
off变量的作用是记录每个字段在byte[]中的起始位置，这样才能正确的解析出每个字段。之前一个包体中只包含一条数据的时候，off传入到dataHander(）后，将byte[]从off解析到数组尾部即完成了数据的解析，这时候的off是不要记录的。
但是当一个包体包含多条不同协议数据的时候，当第一条数据顺利解析完成后，因为传入解析方法的形参off虽然已经在方法内部进行了自增，但是未能作用于外部的实参off变量中，所以当解析第二条数据的时候off已经不再正确。
画个图加深理解：
在第三步传入协议方法的时候，虽然在方法内解析每个字段的时候off都自增了，但是却没有对外部的off进行修改，所以才会导致乱码。
为什么会乱码呢？
乱码说白了就是二进制无法转换成对应的字符。因为里面会有一些ascii码，而我们知道ascii是用一个byte表示，能够表示128（2的七次方）个字符，取值范围为0-127，即二进制范围为00000000 ~ 01111111，当off错位之后，这个byte表示的数字大于127的时候，就会因为找不到对应的字符，所以就会乱码。
结语
或许在很多人眼中，这就是个小错误。但对我来说，却是工作生涯的一个起点。经过这一次升级之后，后面也参与了这个程序的JVM调优、Kafka瓶颈测试的工作。对我后面的工作思维方式帮助了很多。
四年过去了，他们也在新的地方，成立了新的团队。而我，也慢慢成长为一名大数据工程师，也成为这个团队的负责人。或许有一天，我也会离开，或许会因为钱、或许会因为平台、亦或许会因为一个人。
这一次、很深刻，就像一份没带给你伤痛的感情一样。我也觉得初入社会，遇到这样的一群人、遇到这样的一件事很幸运。
最后，愿我们永远十八岁。
