记一次关于改变形参值的bug排查经历

上周五按计划需要上线一个运营的紧急需求，在测试环境也 “测试” 通过了，结果发到预发及正式环境却出现问题。然后我就进行了排查。

bug 表现：

• 最初的观察发现，相同的账号密码，在 A 功能处能成功通过，在 B 功能处却大面积报密码错误，偶尔几个能成功。一开始觉得简直不可思议，连忙校验数据库中的配置是否正确。自己看了好几遍也让同事对了好几遍没发现错误。排除配置错误原因。

• 观察第三方服务网关日志，发现 B 功能请求的服务日志中，MD5 加密过的密码没有一个是相同的。于是从此处着手，排查代码中的 MD5 加密是否存在问题，一开始怀疑是环境的问题导致的，但是想到有部分能成功通过，那说明加密本身还是正常的。随排除 MD5 加密本身问题。

• 本来排查到这里已经陷入一个死胡同，但是我继续观察日志发现，每一批请求的第一个 MD5 加密后的密码都是正确的，随后每一个都不一样。于是想到网关这边批量处理的代码是不是有问题，猜想是循环来处理的，但是循环的时候代码出现错误了。然后去查看第三方网关相关代码，发现果然如此。该功能的批量处理是用for循环实现的，然而写这部分代码的同事在循环体内调用的方法中把md5加密后的密码重新set回形参内，导致除了第一次循环，后面的循环中的密码都不是本来的密码， 而是上一次md5加密后的密码。因此才会第一次成功，之后的全部失败。

找到了原因那么这个 bug 就很好解决了，将 md5 加密的过程放在最后的处理中而不用重新 set 回去即可。

其实这里面涉及到的就是 Java 中形参的改变对实参的影响。Java中，当形参是基本类型，或者基本类型被包装后的的包装类（Integer等）或者字符串的引用类时，改变形参不会影响实参的值，而形参是对象时，改变形参是会改变实参的值的。

这次 bug 反映出在测试时测试不充分的问题，在测试环境中我和测试同学只测试了单个处理的过程，没有测试批量处理的过程，以后应当更充分一些，算是一次教训。

同时也显示出日志和仔细观察日志的重要性，如果这次没有良好的日志或者仔细的观察，都无法做到较快的排查这次的问题（虽然这次也花了挺久的其实）。