前言

Findbugs很多人都并不陌生，Eclipse中有插件可以幫助查找代碼中隱藏的bug，IDEA中也有這款插件。這個(gè)插件可以幫助我們查找隱藏的bug,比較重要的功能就是查找潛在的null指針。
在編寫代碼的過程中,我們可能不會(huì)一直記得檢查空的引用,在我們測試時(shí)可能很難發(fā)現(xiàn)問題,但是應(yīng)用上線之后，面對大量的用戶，很多問題就會(huì)浮現(xiàn)出來。所以在編碼時(shí)，使用findbugs檢查一下很有必要。

安裝

安裝完之后，重啟studio,會(huì)發(fā)現(xiàn)左下角會(huì)出現(xiàn)findbugs的圖標(biāo)

可以分析單個(gè)文件，包下面的所有文件，整個(gè)module下的文件，整個(gè)project下的文件，右鍵想要分析的文件名/包名/module名/project

分析完之后就會(huì)出現(xiàn)結(jié)果面板

點(diǎn)擊對應(yīng)的item在右邊會(huì)定位到具體的代碼

根據(jù)需要可以進(jìn)行更改，其中Correctness這個(gè)錯(cuò)誤使我們重點(diǎn)關(guān)注的對象，這里大多是空指針的錯(cuò)誤，根據(jù)提示進(jìn)行處理。

附：一些常見的錯(cuò)誤信息

Bad practice 代碼中的一些壞習(xí)慣

Class names should start with an upper case letter 主要包括類名的命名，以大寫字母開頭
Method names should start with a lower case letter 方法名以小寫字母開頭
Field names should start with a lower case letter 字段名以小寫字母開頭
equals()method does not check for null argument equals()方法應(yīng)該檢查非空
Class defines equals() and uses Object.hashCode() 一個(gè)類覆寫了equals方法，沒有覆寫hashCode方法，使用了Object對象的hashCode方法
Method ignores exceptional return value 方法忽略返回值的異常信息
Equals method should not assume anything about the type of its argument equals(Object o)方法不能對參數(shù)o的類型做任何的假設(shè)。比較此對象與指定的對象。當(dāng)且僅當(dāng)該參數(shù)不為 null，并且是表示與此對象相同的類型的對象時(shí)，結(jié)果才為 true。
Comparison of String objects using == or != 用==或者！=去比較String類型的對象
Method might ignore exception 方法可能忽略異常
Method invokes System.exit() 在方法中調(diào)用System.exit(…)語句，考慮用RuntimeException來代替
Method ignores result of InputStream.read() InputStream.read方法忽略返回的多個(gè)字符，如果對結(jié)果沒有檢查就沒法正確處理用戶讀取少量字符請求的情況。

Dodgy code 糟糕的代碼

Switch statement found where default case is missing Switch沒有默認(rèn)情況下執(zhí)行的case語句
Switch statement found where one case falls through to the next case Switch語句中一個(gè)分支執(zhí)行后又執(zhí)行了下一個(gè)分支。通常case后面要跟break 或者return語句來跳出。
Dead store to local variable 該指令為局部變量賦值，但在其后的沒有對她做任何使用。通常，這表明一個(gè)錯(cuò)誤，因?yàn)橹祻奈词褂眠^。
Write to static field from instance method 在實(shí)例方法寫入靜態(tài)字段
Redundant nullcheck of value known to be non-null 方法中對不為空的值進(jìn)行為空的判斷。
Method uses the same code for two branches 此方法使用相同的代碼，以實(shí)現(xiàn)兩個(gè)有條件的分支。檢查以確保這是不是一個(gè)編碼錯(cuò)誤
Exception is caught when Exception is not thrown 在try/catch塊中捕獲異常，但是異常沒有在try語句中拋出而RuntimeException又沒有明確的被捕獲
Integral division result cast to double or float 整形數(shù)除法強(qiáng)制轉(zhuǎn)換為double或者float類型。
Possible null pointer dereference due to return value of called method 方法的返回值沒有進(jìn)行是否為空的檢查就重新賦值，這樣可能會(huì)出現(xiàn)空指針異常。
Useless object created 對象創(chuàng)建了并沒有用
Unread public/protected field 沒有用到的字段
Internationalization 關(guān)于代碼國際化相關(guān)方面的

Consider using Locale parameterized version of invoked method
使用平臺(tái)默認(rèn)的編碼格式對字符串進(jìn)行大小寫轉(zhuǎn)換，這可能導(dǎo)致國際字符的轉(zhuǎn)換不當(dāng)。使用以下方式對字符進(jìn)行轉(zhuǎn)換

Performance 關(guān)于代碼性能相關(guān)方面的

Boxing/unboxing to parse a primitive 類型轉(zhuǎn)換 比如字符串轉(zhuǎn)換成int 應(yīng)該使用Integer.parseInt(“”) 代替Integer.valueOf(“”)
Method concatenates string using + in aloop
每次循環(huán)里的字符串+連接，都會(huì)新產(chǎn)生一個(gè)string對象，在java中，新建一個(gè)對象的代價(jià)是很昂貴的，特別是在循環(huán)語句中，效率較低
解決辦法：使用StringBuffer或者StringBuilder重用對象。
Private method is never called 私有方法沒有被調(diào)用
Explicit garbage collection;extremely dubious except in benchmarking code
在代碼中顯式的調(diào)用垃圾回收命名，這樣做并不能起作用。在過去，有人在關(guān)閉操作或者finalize方法中調(diào)用垃圾回收方法導(dǎo)致了很多的性能浪費(fèi)。這樣大規(guī)?；厥諏ο髸r(shí)會(huì)造成處理器運(yùn)行緩慢。
Unread field:should this field be static? 沒有用到的static 字段
should be a static inner class 此內(nèi)部類應(yīng)該使用static修飾

Experimental

Method may fail to clean up stream or resource on checked exception
這種方法可能無法清除（關(guān)閉，處置）一個(gè)流，數(shù)據(jù)庫對象，或其他資源需要一個(gè)明確的清理行動(dòng)
解決方法：流的關(guān)閉都寫在finally里面
Malicious code vulnerability 關(guān)于惡意破壞代碼相關(guān)方面的

May expose internal representation by incorporating reference to mutable object
此代碼把外部可變對象引用存儲(chǔ)到對象的內(nèi)部表示。如果實(shí)例受到不信任的代碼的訪問和沒有檢查的變化危及對象和重要屬性的安全。存儲(chǔ)一個(gè)對象的副本，在很多情況下是更好的辦法。
Field isn't final but should be 此字段前應(yīng)該加final
Field isn't final and can't be protected from malicious code 此字段前應(yīng)該加final
Field should be package protected
一個(gè)靜態(tài)字段是可以被惡意代碼或其他的包訪問修改?？梢园堰@種類型的字段聲明為final類型的以防止這種錯(cuò)誤。

Multithreaded correctness 關(guān)于代碼正確性相關(guān)方面的

Static DateFormat DateFormat 在多線程中本身就是不安全的，如果在線程范圍中共享一個(gè)DateFormat的實(shí)例而不使用一個(gè)同步的方法在應(yīng)用中就會(huì)出現(xiàn)一些奇怪的行為。
Call to static DateFormat DateFormats多線程使用本事就是不安全的,改進(jìn)方法：需要?jiǎng)?chuàng)建多實(shí)例或線程同步

Correctness 關(guān)于代碼正確性相關(guān)方面的

Nullcheck of value previously dereferenced 此代碼之前廢棄null值檢查。解決辦法 進(jìn)行null檢查
Possible null pointer dereference 可能為null
Null pointer dereference 對象賦為null值后 沒有被重新賦值
Possible null pointer dereference in method on exception path 在異常null值處理分支調(diào)用的方法上，可能存在對象去除引用操作
value is null and guaranteed to be dereferenced on exception path exception分支上，存在引用一個(gè)null對象的方法，引發(fā)空指針異常。
Self comparison of value with itself 方法中對一個(gè)局部變量自身進(jìn)行比較運(yùn)算，并可說明錯(cuò)誤或邏輯錯(cuò)誤。請確保您是比較正確的事情。
An apparent infinite recursive loop 明顯的無限迭代循環(huán),將導(dǎo)致堆棧溢出.

到此這篇關(guān)于IDEA插件FindBugs的使用詳解的文章就介紹到這了,更多相關(guān)IDEA插件FindBugs內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論