<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          最近線上發(fā)生的兩個坑爹鍋!

          共 1927字,需瀏覽 4分鐘

           ·

          2021-01-17 14:36

          往期熱門文章:

          1、往期精選優(yōu)秀博文都在這里了!

          2、為什么我不建議你用去 “ ! = null " 做判空?

          3、這四種情況下,才是考慮分庫分表的時候!

          4、線上 4 臺機器同一時間全部 OOM,到底發(fā)生了什么?

          5爽??!Intellij IDEA 神器居然還藏著這些實用小技巧 !

          最近由于在技改,發(fā)生了不少問題,前文中說的緩存穿透只是其中之一,想了想,雖然都是比較簡單的問題,但是應(yīng)該實際中還是有不少人碰到過,這些問題看似很簡單,但是你絕對應(yīng)該踩過。

          ==和equals

          關(guān)于==和equals區(qū)別,我相信稍微做過一兩年開發(fā)的同學(xué)都應(yīng)該很清楚,可是,然而,這個坑在很多開發(fā)的時候仍然頻繁出現(xiàn),為什么?因為有時候有的同學(xué)認為沒什么區(qū)別,就用==吧,然而,一些意外總是如期而至。
          不久前,由于線上RPC框架切換,我們就發(fā)生了一點小問題。
          本來,線上的接口是這樣定義的:
          然后,接口查詢中使用到了一個枚舉類型,根據(jù)id獲取枚舉值,只不過這里使用的是==號來判斷。
          調(diào)用方的寫法:
          本來,這個代碼在線上跑了兩年了,一點問題沒有,怎么就突然不行了呢?
          但是,切換框架之后,這個接口報錯了,當時我也看了這個地方半天,猜測是這里的問題,但是想了想貌似又不應(yīng)該啊。
          結(jié)果最后發(fā)現(xiàn),原來的RPC框架傳輸中使用的是valueOf,從緩存中取值,加上自動裝箱拆箱,判斷可以通過。但是,新的框架使用的是new Byte(),所以這個老代碼就永遠無法通過了,因為這是一個新的對象。
          看看這個測試的結(jié)果。
          后面,通過安裝Alibaba Java Coding Guidelines插件統(tǒng)一掃描所有代碼,還又發(fā)現(xiàn)了一個坑爹的問題。
          這個寫法又不太一樣,這個枚舉只是單純的把code成員變量定義成了byte基礎(chǔ)類型,不是包裝類型。這樣,代碼用==判斷又都OK了。
          坑爹1
          想象一下,因為是基礎(chǔ)數(shù)據(jù)類型,拆箱后==判斷當然是通過的。
          還有更奇葩的寫法,成員變量是Byte包裝類型,getEnumByCode(byte code)這里用的又是基礎(chǔ)類型,當然,這種寫法也能判斷通過。
          坑爹2
          所以,心累... ...
          最后,我想再補充一下關(guān)于基礎(chǔ)數(shù)據(jù)類型緩存的知識。能用==判斷的原因也都是依賴于緩存的原因。

          最后,奉勸大家一句,千萬,千萬,在項目中判斷包裝數(shù)據(jù)類型都用equals,因為就算這段代碼你很確信現(xiàn)在是對的,然而鬼都不知道后面會發(fā)生什么!不要抱有僥幸心理。

          日志打滿

          項目技改上線后不久,發(fā)現(xiàn)接口成功率直接跌0(跌0的告警監(jiān)控必須得有,不然死都不知道怎么死的)。排查了很久,看其他都是正常的,最后發(fā)現(xiàn)GC耗時狂增,登錄服務(wù)器一看,居然是硬盤被打滿了。
          然后果斷去看日志,因為我們的硬盤實際上很小,先懷疑日志,果不其然,日志炸了。通過ls -lht查看文件大小。
          通過rm -rf刪除后發(fā)現(xiàn)硬盤空間并沒有釋放。正常情況下是不會出現(xiàn)這個問題的,但是如果文件被鎖定或者有另外的進程在向文件寫數(shù)據(jù)的話就會有問題了。
          在Linux中,一個文件在文件系統(tǒng)中存放包含兩個部分:
          1. 指針部分:指針位于文件系統(tǒng)的meta-data中,在將數(shù)據(jù)刪除后,這個指針就從meta-data中清除了。
          2. 數(shù)據(jù)部分:而數(shù)據(jù)部分存儲在磁盤中。
          像上面的情況,雖然我們刪除了service.log,但是由于進程鎖定,指針部分沒有從meta-data中刪除,所以也就看到存儲空間沒有釋放的問題。
          解決辦法有兩種:
          1. 使用lsof -n |grep delete查看什么進程在寫service.log,通過命令發(fā)現(xiàn)是我們的java進程在一直寫文件,然后通過后臺工具直接重啟應(yīng)用,重啟之后發(fā)現(xiàn)恢復(fù)正常。

          2. 清空日志文件,執(zhí)行命令echo "">/service.log,這個方法可以立刻釋放磁盤空間,進程繼續(xù)寫入日志也不會受到影響。

          往期熱門文章:

          1、歷史文章分類導(dǎo)讀列表!精選優(yōu)秀博文都在這里了!》

          2、萬億級數(shù)據(jù)應(yīng)該怎么遷移?
          3、從應(yīng)用到底層 36張圖帶你進入Redis世界
          4、寫代碼有這16個好習(xí)慣,可以減少80%非業(yè)務(wù)的bug
          5、順豐快遞:請簽收MySQL靈魂十連

          6、一個基于SpringBoot + MyBatis + Vue的代碼生成器
          7、Redis 分布式鎖使用不當,超賣了100瓶飛天茅臺!??!

          8、如何設(shè)計訂單系統(tǒng)?這篇寫得太好了!
          9、如果MySQL磁盤滿了,會發(fā)生什么?還真被我遇到了!
          10、阿里開源的27個項目,值得收藏!
          瀏覽 43
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  成人女人毛片视频 | 日韩三级片一二三区 | 影音先锋男人的资源网站 | 日本免费一级黄色片 | 国产麻传媒一区二区三区网站入口 |