總結(jié)最近線上發(fā)生的兩個(gè)坑爹鍋

這篇文章主要介紹“總結(jié)最近線上發(fā)生的兩個(gè)坑爹鍋”，在日常操作中，相信很多人在總結(jié)最近線上發(fā)生的兩個(gè)坑爹鍋問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”總結(jié)最近線上發(fā)生的兩個(gè)坑爹鍋”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

==和equals

關(guān)于==和equals區(qū)別，我相信稍微做過(guò)一兩年開(kāi)發(fā)的同學(xué)都應(yīng)該很清楚，可是，然而，這個(gè)坑在很多開(kāi)發(fā)的時(shí)候仍然頻繁出現(xiàn)，為什么?因?yàn)橛袝r(shí)候有的同學(xué)認(rèn)為沒(méi)什么區(qū)別，就用==吧，然而，一些意外總是如期而至。

不久前，由于線上RPC框架切換，我們就發(fā)生了一點(diǎn)小問(wèn)題。

本來(lái)，線上的接口是這樣定義的：

然后，接口查詢中使用到了一個(gè)枚舉類型，根據(jù)id獲取枚舉值，只不過(guò)這里使用的是==號(hào)來(lái)判斷。

調(diào)用方的寫(xiě)法：

本來(lái)，這個(gè)代碼在線上跑了兩年了，一點(diǎn)問(wèn)題沒(méi)有，怎么就突然不行了呢?

但是，切換框架之后，這個(gè)接口報(bào)錯(cuò)了，當(dāng)時(shí)我也看了這個(gè)地方半天，猜測(cè)是這里的問(wèn)題，但是想了想貌似又不應(yīng)該啊。

結(jié)果最后發(fā)現(xiàn)，原來(lái)的RPC框架傳輸中使用的是valueOf，從緩存中取值，加上自動(dòng)裝箱拆箱，判斷可以通過(guò)。但是，新的框架使用的是new  Byte()，所以這個(gè)老代碼就永遠(yuǎn)無(wú)法通過(guò)了，因?yàn)檫@是一個(gè)新的對(duì)象。

看看這個(gè)測(cè)試的結(jié)果。

后面，通過(guò)安裝Alibaba Java Coding Guidelines插件統(tǒng)一掃描所有代碼，還又發(fā)現(xiàn)了一個(gè)坑爹的問(wèn)題。

這個(gè)寫(xiě)法又不太一樣，這個(gè)枚舉只是單純的把code成員變量定義成了byte基礎(chǔ)類型，不是包裝類型。這樣，代碼用==判斷又都OK了。

坑爹1

想象一下，因?yàn)槭腔A(chǔ)數(shù)據(jù)類型，拆箱后==判斷當(dāng)然是通過(guò)的。

還有更奇葩的寫(xiě)法，成員變量是Byte包裝類型，getEnumByCode(byte code)這里用的又是基礎(chǔ)類型，當(dāng)然，這種寫(xiě)法也能判斷通過(guò)。

坑爹2

所以，心累... ...

最后，我想再補(bǔ)充一下關(guān)于基礎(chǔ)數(shù)據(jù)類型緩存的知識(shí)。能用==判斷的原因也都是依賴于緩存的原因。

最后，奉勸大家一句，千萬(wàn)，千萬(wàn)，在項(xiàng)目中判斷基礎(chǔ)數(shù)據(jù)類型都用equals，因?yàn)榫退氵@段代碼你很確信現(xiàn)在是對(duì)的，然而鬼都不知道后面會(huì)發(fā)生什么!不要抱有僥幸心理。

日志打滿

項(xiàng)目技改上線后不久，發(fā)現(xiàn)接口成功率直接跌0(跌0的告警監(jiān)控必須得有，不然死都不知道怎么死的)。排查了很久，看其他都是正常的，最后發(fā)現(xiàn)GC耗時(shí)狂增，登錄服務(wù)器一看，居然是硬盤(pán)被打滿了。

然后果斷去看日志，因?yàn)槲覀兊挠脖P(pán)實(shí)際上很小，先懷疑日志，果不其然，日志炸了。通過(guò)ls -lht查看文件大小。

通過(guò)rm -rf刪除后發(fā)現(xiàn)硬盤(pán)空間并沒(méi)有釋放。正常情況下是不會(huì)出現(xiàn)這個(gè)問(wèn)題的，但是如果文件被鎖定或者有另外的進(jìn)程在向文件寫(xiě)數(shù)據(jù)的話就會(huì)有問(wèn)題了。

在Linux中，一個(gè)文件在文件系統(tǒng)中存放包含兩個(gè)部分：

1. 指針部分：指針位于文件系統(tǒng)的meta-data中，在將數(shù)據(jù)刪除后，這個(gè)指針就從meta-data中清除了。

2. 數(shù)據(jù)部分：而數(shù)據(jù)部分存儲(chǔ)在磁盤(pán)中。

像上面的情況，雖然我們刪除了service.log，但是由于進(jìn)程鎖定，指針部分沒(méi)有從meta-data中刪除，所以也就看到存儲(chǔ)空間沒(méi)有釋放的問(wèn)題。

解決辦法有兩種：

使用lsof -n |grep  delete查看什么進(jìn)程在寫(xiě)service.log，通過(guò)命令發(fā)現(xiàn)是我們的java進(jìn)程在一直寫(xiě)文件，然后通過(guò)后臺(tái)工具直接重啟應(yīng)用，重啟之后發(fā)現(xiàn)恢復(fù)正常。

清空日志文件，執(zhí)行命令echo "">/service.log，這個(gè)方法可以立刻釋放磁盤(pán)空間，進(jìn)程繼續(xù)寫(xiě)入日志也不會(huì)受到影響。

到此，關(guān)于“總結(jié)最近線上發(fā)生的兩個(gè)坑爹鍋”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！