反思了下，解决问题无外乎3w1h when where who how
就是查询出来的事情多了，现在不知道哪个地方出问题，应该根据日志一步一步梳理，查看每一步的输出结果是否与预期一致
顺藤摸瓜
觉得不清楚的地方，可以新增打印，或通过其它方法获取这些不可知的信息。
已经确认没有问题的代码，不能出异常情况时，就开始漫无目的的怀疑，张驰有度。。。
严格的讲这个Bug还没有彻底解决，因为没有找到真正的原因
重启下服务就好了！！！！！！！！！！！！！！！！
主要想梳理下操作流程：
当时的反应：
bug出现了，第一个反应就是，不可能啊。这代码是才重构和优化的。相关细节可以说是了如指掌。怎么可能呢
然后开始漫无目的的怀疑Collections.shuff这个api，因为在这些代码中，就这个方法是黑盒，其它的都可以 认为是自己写的，不可能有问题。
对了，还有一个api，也可能有问题redisTemplate.boundsListOps(key).range(from,stop)这个api可能有问题，导致返回的值比较多
最近，老和一个测试磕起来了。
有这个必要嘛，一个自认为专业的人找到另一个自认为专业的人的bug。
如果不这样做会给团队带来不可挽回的损失？
如果不这样做，就会给自己带来不可挽回的损失？
怎么解决这个问题呢？
熟悉下测试部署的环境，能在测试使用的环境上找到出错的原因，按照测试的思路解决测试提出的问题，这样就了了测试的想法