架构师写的BUG，非比寻常

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

部门新来了个架构师，BAT背景，住在三环，开宝立刻班，有车位。

小伙话很少，但一旦说话斩钉截铁，带着没法撼动的自信。缘由就是，有他着数亿高并发经验，每一秒钟的请求，都是其余企业运行一年也没法企及的。这就让人很是羡慕，毕竟他靠这个比我赚的钱要多。

俗话说，要想在公司不出事故，那就不要写代码。干活多了容易出事，一身轻松无人问津，这就是现实。

但有时候仍是要当作果的。新来的研发领导不懂技术，但他懂技术指标，因此就统计你们提交git的数量，若是git活动是一片绿色如A股，那就算过关了。

架构师思来想去，决定领一个并发量最高的需求：统计接口的平均响应时间和启动以来的请求数。

为何说它的并发量高呢？这是由于，它是统计全部接口的，天然比每个接口的请求量都要大。AOP代码一包，每一个接口都得从他这里走一圈。

该咱们的架构师上场了。代码如图。

架构师说，个人代码不须要作注释。所谓的注释，都是给垃圾代码用的。我深觉得是，他明显是受到了Netflix公司的影响。

程序考虑到了高并发场景，使用了线程安全的ConcurrentHashMap，而后每次经过监控key取出相应的数据，而后在value上递增。这么简单的代码，确实不须要增长什么注释。

做为项目里并发量最高的代码，出于对高级架构师的信任，咱们并不须要作什么代码review，也不须要作什么测试。你们都很忙，代码您呐，到线上遛一遛吧。

我建议你先找一找代码的问题，若是你发现了问题，那就比架构师还厉害；若是你没发现，也不证实你比架构师弱，没有什么好伤心的。

下面插一副图，阻断一下思惟。

装B遭雷劈，线上运行一段时间后，内存溢出了。

你们吵吵个没完，毕竟xjjdog说过，内存溢出问题的排查周期很长，大约平均须要40天左右才能解决问题。在你们开始论证的时候，架构师偷偷的启动了Eclipse MAT。MAT用来分析内存问题是很是合适的，但前提是你须要把堆栈给捣鼓下来。

架构师会用jmap，最主要的是权限大，因而本身搞了一份拷贝到线下分析。

我能理解到他的心情，毕竟问题定位到本身的代码不是一件什么值得高兴的事情。他发现内存的堆里面，满满的全是MonitorKey和MonitorValue。

Monitor$MonitorKey@15aeb7ab
复制代码

我和架构师关系比较好，因而他问我：我们的接口是否是特别的多？

我说：不是啊，你别看访问量大，就这么个狗屁业务能有多少接口？几百个撑了天了。

他说：我在堆里发现了几千万个...

说完他就不言语了，由于他发现里面有很多是同样的接口。必定是参数的缘由，因此他在代码里加了这个，把？后面的给截断了。

key = key.split("\\?")[0];
复制代码

结果发布到线上，过不了多久内存又溢出了。此次终于引发了大牛们的注意，通过你们的分析，发现代码是忘了给MonitorKey重写equals和hashCode方法了。

我不由脸红起来。做为好朋友，我不该该让他出这个丑。但我又是隐隐快乐的，由于他工资比我高。

因此这就是一个很大的问题。不少同窗对HashMap的知识点对答如流，甚至还专门记忆了红黑树。但换一个方式去问，却又一脸懵逼。

其中一种问法是这样的：一个普通的对象，可以做为HashMap的key么？

答案显然是能够的，但须要注意重写hashCode和equals方法。若是忘记重写的话，大几率会形成内存泄漏。

很不幸，现实中忘记的案例不少。大牛架构师也会中招。

代码重写hashCode和equals方法后，线上就再也没发生过内存溢出。

---

等等，还没完。毕竟是架构师，仅仅这样一个bug仍是证实不了水平的。架构师写的bug，确定非比寻常。

这种事出现的多了，研发领导对技术的权威性就再也不是那么感冒。咱们决定从并发量最高的代码开始，进行一下代码review。

很不幸，架构师的visit代码出现问题了。虽然问题不是很大，但它毕竟是个问题。

在统计数据的时候，代码使用了ConcurrentHashMap，但它并无什么卵用。

visit方法，首先拿出了key，而后判空，再塞值。这明显不是一个原子操做。

线程1：获取key为a的值
线程2：获取key为a的值
线程1：a为null，生成一个b
线程2：a为null，生成一个c
线程1：保存a=b
线程2：保存a=c
复制代码

此时，B丢了。

业务能够忍受，但严谨的技术大牛们忍受不了，提出了修改的意见。

架构师说，给visit方法加个synchronized不就成了。

public synchronized void visit(String url, String desc, long timeCost) 复制代码

我说不行。有更优雅的写法，效率更高。那就是使用putIfAbsent方法，代码改动以下：

MonitorKey key = new MonitorKey(url, desc);
MonitorValue value = monitors.putIfAbsent(key, new MonitorValue());
value = monitors.get(key);
value.count.getAndIncrement();
value.totalTime.getAndAdd(timeCost);
value.avgTime = value.totalTime.get() / value.count.get();
复制代码

你们就这两种方式争论了起来。

技术总监托着腮想了半天，看了看争的面红耳赤的同窗们，说：这就是我不放心大家的缘故。线上环境要尽可能保持稳定性，作最小的变动。既然加个synchronized就可以很容易简单解决的问题，为啥不直接用呢？下面这种代码改动太大，有风险。

总监接着把头转向我：这个BUG非比寻常，为了让你们引觉得戒，你来作整个事故的复盘。把问题的排查和获得的教训分享给你们，让你们向这种至简的架构看齐。咱们日常的工做中，也要尽可能以结果导向为主，用什么手段无所谓，能漂亮把事情办好就行。

这就是此篇文章的由来，我虚心受教，同时也明白本身的工资是涨不上去了。

你要是点个赞或者友情三连，或许还能安慰我一下下。​

做者简介：小姐姐味道 (xjjdog)，一个不容许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不同的味道。个人我的微信xjjdog0，欢迎添加好友，​进一步交流。​