反思了下，解决问题无外乎3w1h when where who how

就是查询出来的事情多了，现在不知道哪个地方出问题，应该根据日志一步一步梳理，查看每一步的输出结果是否与预期一致

顺藤摸瓜

觉得不清楚的地方，可以新增打印，或通过其它方法获取这些不可知的信息。

已经确认没有问题的代码，不能出异常情况时，就开始漫无目的的怀疑，张驰有度。。。

严格的讲这个Bug还没有彻底解决，因为没有找到真正的原因

重启下服务就好了！！！！！！！！！！！！！！！！

主要想梳理下操作流程：

当时的反应：

bug出现了，第一个反应就是，不可能啊。这代码是才重构和优化的。相关细节可以说是了如指掌。怎么可能呢

然后开始漫无目的的怀疑Collections.shuff这个api，因为在这些代码中，就这个方法是黑盒，其它的都可以 认为是自己写的，不可能有问题。
对了，还有一个api，也可能有问题redisTemplate.boundsListOps(key).range(from,stop)这个api可能有问题，导致返回的值比较多

最近，老和一个测试磕起来了。

有这个必要嘛，一个自认为专业的人找到另一个自认为专业的人的bug。

如果不这样做会给团队带来不可挽回的损失？
如果不这样做，就会给自己带来不可挽回的损失？

怎么解决这个问题呢？
熟悉下测试部署的环境，能在测试使用的环境上找到出错的原因，按照测试的思路解决测试提出的问题，这样就了了测试的想法

Bug解决过程复盘