还原下五天前的bug

有点啰嗦，如果你只想看trouble是怎么解决的可以直接跳到总结部分

前言

10.20号项目验收，早上代码发布好后自我感觉一帆风顺，中午吃完饭后根据测试反馈的bug进行 ，jenkins发布，于是领导们拿起手机开始验收，这时有人反馈接口响应有点慢，本着重启能解决99%的原则我重启了服务(没有时间给我犹豫，只能先重启)。

然后自己再偷偷登上服务器看 是否正常，发现这个锅 不背，这时领导又反馈了已经出现500了，于是几个领导们都过来看情况，自己心里顿时慌了，只能硬着头皮上了，根据测试的操作流程大概判断出是那个服务器，于是登上服务器，忐忑的敲下 后发现上面的四个服务都是正常的run，于是由敲了第二个命令: ，然后发现有个java的进程cpu居然到了310%，赶紧敲下第三个命令: （cpu最高的pid），这时才找到了问题服务。

是时候找背锅侠了，先把找到的pid转16进制，然后再通过 找到有问题的位置，然后赶紧修改代码、 ,确定一切ok后领导们才从我身后走开（被人盯着看的感觉确实不是很舒服），然后通过 最终找到了背锅侠，至此耗时15分钟的trouble彻底解决了，可以松一口气了。

bug代码

相信看了这么久了肯定是想看下代码的，满足好奇心，贴出代码

其实逻辑很简单，就是两个集合做减法，先别着急说直接用 ，当然我当时是这么改的，但是事后我再想这段代码的时候发现里面还是有点小坑值得花点时间踩踩的

首先为什么没有不用两个for去循环减而用迭代器，你可能会说会出现 但事实真这样的吗?只用在用 和 时才会出现。因为在调用 方法的时候会先调用 方法，发现集合大小改变了就会抛异常。ok如果这个你如果感觉简单我还有

在第7行假如 不成立，则代码会一直循环下去，可怕吧，这也是这次的罪魁祸首。假如 成立，又会掉进 异常的坑，是不是很坑，也就是说这个代码不管怎么都是一个坑啊

其实这段代码只需要在第5行后面添加一个 方法,完整代码如下

事后我做了什么

被领导教育肯定的，但是每行代码要去 也是不现实的，喊喊口号还可以，真正去落实的人没有几个，但是怎么避免这种问题再出现？特别是在验收的节骨眼上，于是24号下午我通过 搭建了 分析出来的代码然后再交叉安排人去 ，这样组员都对业务熟悉了，潜在的bug也可以被修复（这是最理想的状态）

总结

遇到bug不能听别人乱指挥，因为代码自己比他熟（前提是自己知道怎么排查问题，要是不知道那还是听他指挥）

即便自己很慌也不能表现出来，不然大家都会慌，到时你只有挨批的份了

关于cpu爆满的处理流程

：找出作怪的pid

：把pid转16进制

为什么想起弄这个公众号了

用同事的话说工作不饱和

以前申请的公众号有一个被微信收回了，这个再不用也会被收回

自己消极了两个月了想搞点事情

24号说过想写个bug庆祝下

技术交流