架构师写的BUG,非比寻常

部门新来了个架构师,BAT背景,住在三环,开宝马上班,有车位。 小伙话不多,但一旦说话斩钉截铁,带着无法撼动的自信。原因就是,有他着数亿高并发经验,每一秒钟的请求,都是其他企业运...
部门新来了个架构师,BAT背景,住在三环,开宝马上班,有车位。 小伙话不多,但一旦说话斩钉截铁,带着无法撼动的自信。原因就是,有他着数亿高并发经验,每一秒钟的请求,都是其他企业运行一年也无法企及的。这就让人非常羡慕,毕竟他靠这个比我赚的钱要多。 俗话说,要想在公司不出事故,那就不要写代码。干活多了容易出事,一身轻松无人问津,这就是现实。 但有时候还是要看成果的。新来的研发领导不懂技术,但他懂技术指标,所以就统计大家交git的数量,如果git活动是一片绿色如A股,那就算过关了。 架构师思来想去,决定领一个并发量最高的需求:统计接口的平均响应时间和启动以来的求数。 为什么说它的并发量高呢?这是因为,它是统计所有接口的,自然比每一个接口的请求量都要大。AOP代码一包,每个接口都得从他这里走一圈。 该我们的架构师上场了。代码如图。
架构师说,我的代码不需要做注释。所谓的注释,都是给垃圾代码用的。我深以为是,他明显是受到了Netflix公司的影响。 程序考虑到了高并发场景,使用了线程安全的ConcurrentHashMap,然后每次通过监控key取出相应的数据,然后在value上递增。这么简单的代码,确实不需要增加什么注释。 作为项目里并发量最高的代码,出于对高级架构师的信任,我们并不需要做什么代码review,也不需要做什么测试。大家都很忙,代码您呐,到线上遛一遛吧。 我建议你先找一找代码的问题,如果你发现了问题,那就比架构师还厉害;如果你没发现,也不证明你比架构师弱,没有什么好伤心的。 下面插一副图,阻断一下思维。
装B遭雷劈,线上运行一段时间后,内存溢出了。 大家吵吵个没完,毕竟xjjdog说过,内存溢出问题的排查周期很长,大约平均需要40天左右才能解决问题。在大家开始论证的时候,架构师偷偷的启动了Eclipse MAT。MAT用来分析内存问题是非常合适的,但前提是你需要把堆栈给捣鼓下来。 架构师会用jmap,最主要的是权限大,于是自己搞了一份拷贝到线下分析。 我能理解到他的心情,毕竟问题定位到自己的代码不是一件什么值得高兴的事情。他发现内存的堆里面,满满的全是MonitorKeyMonitorValue
Monitor$MonitorKey@15aeb7ab
我和架构师关系比较好,于是他问我:咱们的接口是不是特别的多? 我说:不是啊,你别看访问量大,就这么个狗屁业务能有多少接口?几百个撑了天了。 他说:我在堆里发现了几千万个... 说完他就不言语了,因为他发现里面有不少是一样的接口。一定是参数的原因,所以他在代码里加了这个,把后面的给截断了。 key = key.split("\?")[0]; 复制代码 结果发布到线上,过不了多久内存又溢出了。这次终于引起了大牛们的注意,经过大家的分析,发现代码是忘了给MonitorKey重写equalshashCode方法了。 我不禁脸红起来。作为好朋友,我不应该让他出这个丑。但我又是隐隐快乐的,因为他工资比我高。 所以这就是一个很大的问题。很多同学对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非比寻常,为了让大家引以为戒,你来做整个事故的复盘。把问题的排查和得到的教训分享给大家,让大家向这种至简的架构看齐。我们平常的工作中,也要尽量以结果导向为主,用什么手段无所谓,能漂亮把事情办好就行。 这就是此篇文章的由来,我虚心受教,同时也明白自己的工资是涨不上去了。
 
 
 
  • 发表于 2020-07-30 22:40
  • 阅读 ( 76 )
  • 分类:网络文章

条评论

请先 登录 后评论
不写代码的码农
小编

篇文章

作家榜 »

  1. 小编 文章
返回顶部
部分文章转自于网络,若有侵权请联系我们删除