建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。
我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、濮陽縣ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學管理、有技術(shù)的濮陽縣網(wǎng)站制作公司
部門新來了個架構(gòu)師，BAT背景，住在三環(huán)，開寶馬上班，有車位。
小伙話不多，但一旦說話斬釘截鐵，帶著無法撼動的自信。原因就是，有他著數(shù)億高并發(fā)經(jīng)驗，每一秒鐘的請求，都是其他企業(yè)運行一年也無法企及的。這就讓人非常羨慕，畢竟他靠這個比我賺的錢要多。
俗話說，要想在公司不出事故，那就不要寫代碼。干活多了容易出事，一身輕松無人問津，這就是現(xiàn)實。
但有時候還是要看成果的。新來的研發(fā)領(lǐng)導不懂技術(shù)，但他懂技術(shù)指標，所以就統(tǒng)計大家提交git的數(shù)量，如果git活動是一片綠色如A股，那就算過關(guān)了。
架構(gòu)師思來想去，決定領(lǐng)一個并發(fā)量最高的需求：統(tǒng)計接口的平均響應時間和啟動以來的請求數(shù)。
為什么說它的并發(fā)量高呢?這是因為，它是統(tǒng)計所有接口的，自然比每一個接口的請求量都要大。AOP代碼一包，每個接口都得從他這里走一圈。
該我們的架構(gòu)師上場了。代碼如圖。
架構(gòu)師說，我的代碼不需要做注釋。所謂的注釋，都是給垃圾代碼用的。我深以為是，他明顯是受到了Netflix公司的影響。
程序考慮到了高并發(fā)場景，使用了線程安全的ConcurrentHashMap，然后每次通過監(jiān)控key取出相應的數(shù)據(jù)，然后在value上遞增。這么簡單的代碼，確實不需要增加什么注釋。
作為項目里并發(fā)量最高的代碼，出于對高級架構(gòu)師的信任，我們并不需要做什么代碼review，也不需要做什么測試。大家都很忙，代碼您吶，到線上遛一遛吧。
我建議你先找一找代碼的問題，如果你發(fā)現(xiàn)了問題，那就比架構(gòu)師還厲害;如果你沒發(fā)現(xiàn)，也不證明你比架構(gòu)師弱，沒有什么好傷心的。
下面插一副圖，阻斷一下思維。
裝B遭雷劈，線上運行一段時間后，內(nèi)存溢出了。
大家吵吵個沒完，畢竟xjjdog說過，內(nèi)存溢出問題的排查周期很長，大約平均需要40天左右才能解決問題。在大家開始論證的時候，架構(gòu)師偷偷的啟動了Eclipse MAT。MAT用來分析內(nèi)存問題是非常合適的，但前提是你需要把堆棧給搗鼓下來。
架構(gòu)師會用jmap，最主要的是權(quán)限大，于是自己搞了一份拷貝到線下分析。
我能理解到他的心情，畢竟問題定位到自己的代碼不是一件什么值得高興的事情。他發(fā)現(xiàn)內(nèi)存的堆里面，滿滿的全是MonitorKey和MonitorValue。
Monitor$MonitorKey@15aeb7ab
我和架構(gòu)師關(guān)系比較好，于是他問我：咱們的接口是不是特別的多?
我說：不是啊，你別看訪問量大，就這么個狗屁業(yè)務(wù)能有多少接口?幾百個撐了天了。
他說：我在堆里發(fā)現(xiàn)了幾千萬個...
說完他就不言語了，因為他發(fā)現(xiàn)里面有不少是一樣的接口。一定是參數(shù)的原因，所以他在代碼里加了這個，把?后面的給截斷了。
- key = key.split("\\?")[0];
結(jié)果發(fā)布到線上，過不了多久內(nèi)存又溢出了。這次終于引起了大牛們的注意，經(jīng)過大家的分析，發(fā)現(xiàn)代碼是忘了給MonitorKey重寫equals和hashCode方法了。
我不禁臉紅起來。作為好朋友，我不應該讓他出這個丑。但我又是隱隱快樂的，因為他工資比我高。
所以這就是一個很大的問題。很多同學對HashMap的知識點對答如流，甚至還專門記憶了紅黑樹。但換一個方式去問，卻又一臉懵逼。
其中一種問法是這樣的：一個普通的對象，能夠作為HashMap的key么?
答案顯然是可以的，但需要注意重寫hashCode和equals方法。如果忘記重寫的話，大概率會造成內(nèi)存泄漏。
很不幸，現(xiàn)實中忘記的案例很多。大牛架構(gòu)師也會中招。
代碼重寫hashCode和equals方法后，線上就再也沒發(fā)生過內(nèi)存溢出。
等等，還沒完。畢竟是架構(gòu)師，僅僅這樣一個bug還是證明不了水平的。架構(gòu)師寫的bug，肯定非比尋常。
這種事出現(xiàn)的多了，研發(fā)領(lǐng)導對技術(shù)的權(quán)威性就不再是那么感冒。我們決定從并發(fā)量最高的代碼開始，進行一下代碼review。
很不幸，架構(gòu)師的visit代碼出現(xiàn)問題了。雖然問題不是很大，但它畢竟是個問題。
在統(tǒng)計數(shù)據(jù)的時候，代碼使用了ConcurrentHashMap，但它并沒有什么卵用。
visit方法，首先拿出了key，然后判空，再塞值。這明顯不是一個原子操作。
- 線程1：獲取key為a的值
- 線程2：獲取key為a的值
- 線程1：a為null，生成一個b
- 線程2：a為null，生成一個c
- 線程1：保存a=b
- 線程2：保存a=c
此時，B丟了。
業(yè)務(wù)可以忍受，但嚴謹?shù)募夹g(shù)大牛們?nèi)淌懿涣耍岢隽诵薷牡囊庖姟?/p>
架構(gòu)師說，給visit方法加個synchronized不就成了。
- public synchronized void visit(String url, String desc, long timeCost)
我說不行。有更優(yōu)雅的寫法，效率更高。那就是使用putIfAbsent方法，代碼改動如下：
MonitorKey key = new MonitorKey(url, desc);MonitorValue value = monitors.putIfAbsent(key, new MonitorValue());value.count.getAndIncrement();value.totalTime.getAndAdd(timeCost);value.avgTime = value.totalTime.get() / value.count.get();
大家就這兩種方式爭論了起來。
技術(shù)總監(jiān)托著腮想了半天，看了看爭的面紅耳赤的同學們，說：這就是我不放心你們的緣故。線上環(huán)境要盡量保持穩(wěn)定性，做最小的變更。既然加個synchronized就能夠很容易簡單解決的問題，為啥不直接用呢?下面這種代碼改動太大，有風險。
總監(jiān)接著把頭轉(zhuǎn)向我：這個BUG非比尋常，為了讓大家引以為戒，你來做整個事故的復盤。把問題的排查和得到的教訓分享給大家，讓大家向這種至簡的架構(gòu)看齊。我們平常的工作中，也要盡量以結(jié)果導向為主，用什么手段無所謂，能漂亮把事情辦好就行。
這就是此篇文章的由來，我虛心受教，同時也明白自己的工資是漲不上去了。
你要是點個贊或者友情三連，或許還能安慰我一下下。
作者簡介：小姐姐味道 (xjjdog)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
標題名稱：架構(gòu)師寫的BUG，非比尋常
鏈接URL：http://www.5511xx.com/article/cocojpj.html
