經(jīng)驗貼 | 聊聊線上發(fā)生的兩個坑爹鍋 ~

最近由于在技改，發(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)用方的寫法：

本來，這個代碼在線上跑了兩年了，一點問題沒有，怎么就突然不行了呢？

但是，切換框架之后，這個接口報錯了，當(dāng)時我也看了這個地方半天，猜測是這里的問題，但是想了想貌似又不應(yīng)該啊。

結(jié)果最后發(fā)現(xiàn)，原來的RPC框架傳輸中使用的是valueOf，從緩存中取值，加上自動裝箱拆箱，判斷可以通過。但是，新的框架使用的是new Byte()，所以這個老代碼就永遠無法通過了，因為這是一個新的對象。

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

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

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

想象一下，因為是基礎(chǔ)數(shù)據(jù)類型，拆箱后==判斷當(dāng)然是通過的。

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

所以，心累... ...

最后，我想再補充一下關(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ù)寫入日志也不會受到影響。