1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        架構(gòu)師寫的BUG,非比尋常!

        共 2883字,需瀏覽 6分鐘

         ·

        2020-08-11 22:45

        Java技術(shù)棧

        www.javastack.cn

        關(guān)注閱讀更多優(yōu)質(zhì)文章


        部門新來(lái)了個(gè)架構(gòu)師,BAT背景,住在三環(huán),開寶馬上班,有車位。
        小伙話不多,但一旦說(shuō)話斬釘截鐵,帶著無(wú)法撼動(dòng)的自信。原因就是,有他著數(shù)億高并發(fā)經(jīng)驗(yàn),每一秒鐘的請(qǐng)求,都是其他企業(yè)運(yùn)行一年也無(wú)法企及的。這就讓人非常羨慕,畢竟他靠這個(gè)比我賺的錢要多。
        俗話說(shuō),要想在公司不出事故,那就不要寫代碼。干活多了容易出事,一身輕松無(wú)人問(wèn)津,這就是現(xiàn)實(shí)。
        但有時(shí)候還是要看成果的。新來(lái)的研發(fā)領(lǐng)導(dǎo)不懂技術(shù),但他懂技術(shù)指標(biāo),所以就統(tǒng)計(jì)大家提交git的數(shù)量,如果git活動(dòng)是一片綠色如A股,那就算過(guò)關(guān)了。
        架構(gòu)師思來(lái)想去,決定領(lǐng)一個(gè)并發(fā)量最高的需求:統(tǒng)計(jì)接口的平均響應(yīng)時(shí)間和啟動(dòng)以來(lái)的請(qǐng)求數(shù)。
        為什么說(shuō)它的并發(fā)量高呢?這是因?yàn)?,它是統(tǒng)計(jì)所有接口的,自然比每一個(gè)接口的請(qǐng)求量都要大。AOP代碼一包,每個(gè)接口都得從他這里走一圈。
        該我們的架構(gòu)師上場(chǎng)了。代碼如圖。
        架構(gòu)師說(shuō),我的代碼不需要做注釋。所謂的注釋,都是給垃圾代碼用的。我深以為是,他明顯是受到了Netflix公司的影響。
        程序考慮到了高并發(fā)場(chǎng)景,使用了線程安全的ConcurrentHashMap,然后每次通過(guò)監(jiān)控key取出相應(yīng)的數(shù)據(jù),然后在value上遞增。這么簡(jiǎn)單的代碼,確實(shí)不需要增加什么注釋。
        作為項(xiàng)目里并發(fā)量最高的代碼,出于對(duì)高級(jí)架構(gòu)師的信任,我們并不需要做什么代碼review,也不需要做什么測(cè)試。大家都很忙,代碼您吶,到線上遛一遛吧。
        我建議你先找一找代碼的問(wèn)題,如果你發(fā)現(xiàn)了問(wèn)題,那就比架構(gòu)師還厲害;如果你沒發(fā)現(xiàn),也不證明你比架構(gòu)師弱,沒有什么好傷心的。
        下面插一副圖,阻斷一下思維。
        裝B遭雷劈,線上運(yùn)行一段時(shí)間后,內(nèi)存溢出了。
        大家吵吵個(gè)沒完,畢竟我說(shuō)過(guò),內(nèi)存溢出問(wèn)題的排查周期很長(zhǎng),大約平均需要40天左右才能解決問(wèn)題。在大家開始論證的時(shí)候,架構(gòu)師偷偷的啟動(dòng)了Eclipse MAT。MAT用來(lái)分析內(nèi)存問(wèn)題是非常合適的,但前提是你需要把堆棧給搗鼓下來(lái)。
        架構(gòu)師會(huì)用jmap,最主要的是權(quán)限大,于是自己搞了一份拷貝到線下分析。這個(gè)工作不會(huì)用的可以關(guān)注公眾號(hào)Java技術(shù)棧搜索閱讀。
        我能理解到他的心情,畢竟問(wèn)題定位到自己的代碼不是一件什么值得高興的事情。他發(fā)現(xiàn)內(nèi)存的堆里面,滿滿的全是MonitorKeyMonitorValue
        Monitor$MonitorKey@15aeb7ab
        我和架構(gòu)師關(guān)系比較好,于是他問(wèn)我:咱們的接口是不是特別的多?
        我說(shuō):不是啊,你別看訪問(wèn)量大,就這么個(gè)狗屁業(yè)務(wù)能有多少接口?幾百個(gè)撐了天了。
        他說(shuō):我在堆里發(fā)現(xiàn)了幾千萬(wàn)個(gè)...
        說(shuō)完他就不言語(yǔ)了,因?yàn)樗l(fā)現(xiàn)里面有不少是一樣的接口。一定是參數(shù)的原因,所以他在代碼里加了這個(gè),把?后面的給截?cái)嗔恕?/section>
        key = key.split("\\?")[0];
        結(jié)果發(fā)布到線上,過(guò)不了多久內(nèi)存又溢出了。這次終于引起了大牛們的注意,經(jīng)過(guò)大家的分析,發(fā)現(xiàn)代碼是忘了給MonitorKey重寫equalshashCode方法了。
        我不禁臉紅起來(lái)。作為好朋友,我不應(yīng)該讓他出這個(gè)丑。但我又是隱隱快樂(lè)的,因?yàn)樗べY比我高。
        所以這就是一個(gè)很大的問(wèn)題。很多同學(xué)對(duì)HashMap的知識(shí)點(diǎn)對(duì)答如流,甚至還專門記憶了紅黑樹。但換一個(gè)方式去問(wèn),卻又一臉懵逼。
        其中一種問(wèn)法是這樣的:一個(gè)普通的對(duì)象,能夠作為HashMap的key么?
        答案顯然是可以的,但需要注意重寫hashCode和equals方法。如果忘記重寫的話,大概率會(huì)造成內(nèi)存泄漏。
        很不幸,現(xiàn)實(shí)中忘記的案例很多。大牛架構(gòu)師也會(huì)中招。
        代碼重寫hashCode和equals方法后,線上就再也沒發(fā)生過(guò)內(nèi)存溢出。

        等等,還沒完。畢竟是架構(gòu)師,僅僅這樣一個(gè)bug還是證明不了水平的。架構(gòu)師寫的bug,肯定非比尋常。
        這種事出現(xiàn)的多了,研發(fā)領(lǐng)導(dǎo)對(duì)技術(shù)的權(quán)威性就不再是那么感冒。我們決定從并發(fā)量最高的代碼開始,進(jìn)行一下代碼review。
        很不幸,架構(gòu)師的visit代碼出現(xiàn)問(wèn)題了。雖然問(wèn)題不是很大,但它畢竟是個(gè)問(wèn)題。
        在統(tǒng)計(jì)數(shù)據(jù)的時(shí)候,代碼使用了ConcurrentHashMap,但它并沒有什么卵用。
        visit方法,首先拿出了key,然后判空,再塞值。這明顯不是一個(gè)原子操作。
        線程1:獲取key為a的值
        線程2:獲取key為a的值
        線程1:a為null,生成一個(gè)b
        線程2:a為null,生成一個(gè)c
        線程1:保存a=b
        線程2:保存a=c
        此時(shí),B丟了。
        業(yè)務(wù)可以忍受,但嚴(yán)謹(jǐn)?shù)募夹g(shù)大牛們?nèi)淌懿涣耍岢隽诵薷牡囊庖姟?/section>
        架構(gòu)師說(shuō),給visit方法加個(gè)synchronized不就成了。
        public synchronized void visit(String url, String desc, long timeCost)
        我說(shuō)不行。有更優(yōu)雅的寫法,效率更高。那就是使用putIfAbsent方法,代碼改動(dòng)如下:
        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();
        大家就這兩種方式爭(zhēng)論了起來(lái)。
        技術(shù)總監(jiān)托著腮想了半天,看了看爭(zhēng)的面紅耳赤的同學(xué)們,說(shuō):這就是我不放心你們的緣故。線上環(huán)境要盡量保持穩(wěn)定性,做最小的變更。既然加個(gè)synchronized就能夠很容易簡(jiǎn)單解決的問(wèn)題,為啥不直接用呢?下面這種代碼改動(dòng)太大,有風(fēng)險(xiǎn)。
        總監(jiān)接著把頭轉(zhuǎn)向我:這個(gè)BUG非比尋常,為了讓大家引以為戒,你來(lái)做整個(gè)事故的復(fù)盤。把問(wèn)題的排查和得到的教訓(xùn)分享給大家,讓大家向這種至簡(jiǎn)的架構(gòu)看齊。我們平常的工作中,也要盡量以結(jié)果導(dǎo)向?yàn)橹鳎檬裁词侄螣o(wú)所謂,能漂亮把事情辦好就行。

        最近熱文:

        1、重磅!《Java開發(fā)手冊(cè)(嵩山版)》最新發(fā)布

        2、打破你的認(rèn)知!Java空指針居然還能這樣玩

        3、Java 強(qiáng)、弱、軟、虛,你屬于哪一種?

        4、Spring Boot 太狠了,一次發(fā)布 3 個(gè)版本!

        5、Spring Boot 如何快速集成 Redis?

        6、盤點(diǎn) 6 個(gè)被淘汰的 Java 技術(shù),曾經(jīng)風(fēng)光過(guò)!

        7、Spring Boot Redis 實(shí)現(xiàn)分布式鎖,真香!

        8、Spring Boot 干掉了 Maven 擁抱 Gradle!

        9、公司來(lái)了個(gè)新同事不會(huì)用 Lombok!

        10、同事寫了個(gè)隱藏 bug,我排查了 3 天!

        掃碼關(guān)注Java技術(shù)棧公眾號(hào)閱讀更多干貨。

        點(diǎn)擊「閱讀原文」獲取面試題大全~
        瀏覽 34
        點(diǎn)贊
        評(píng)論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
        評(píng)論
        圖片
        表情
        推薦
        點(diǎn)贊
        評(píng)論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            韩国无码成人三区在线观看 | 国产女主播在线 | 四川女富婆又黄又爽 | 欧美熟妇激情一区二区三区 | 在教室伦流澡到高潮h女女视 | 看中国老女人毛片 | 我要操网站 | 欧美日韩三级在线观看 | 在线看片a | 又大又粗又黄又爽的视频 |