FindBugs is an open source program created by Bill Pugh and David Hovemeyer which looks for bugs in Java code. It uses static analysis to identify hundreds of different potential types of errors in Java programs.

Potential errors are classified in four ranks:

(i) scariest,(ii) scary,(iii) troubling and(iv) of concern.

This is a hint to the developer about their possible impact/severity. FindBugs operates on Java bytecode, rather than source code. The software is distributed as a stand-alone GUI application. There are also plug-ins available for Eclipse, NetBeans, IntelliJ IDEA,Gradle, Hudson and Jenkins.
Additional rules sets can be plugged in FindBugs to increase the set of checks performed.

FindBugs 是什么
FindBugs 是一個(gè)靜態(tài)分析工具，它檢查類或者 JAR 文件，將字節(jié)碼與一組缺陷模式進(jìn)行對(duì)比以發(fā)現(xiàn)可能的問題。有了靜態(tài)分析工具，就可以在不實(shí)際運(yùn)行程序的情況對(duì)軟件進(jìn)行分析。不是通過分析類文件的形式或結(jié)構(gòu)來確定程序的意圖，而是通常使用 Visitor 模式。
在FindBugs的GUI中，需要先選擇待掃描的.class文件(FindBugs其實(shí)就是對(duì)編譯后的class進(jìn)行掃描，藉以發(fā)現(xiàn)一些隱藏的bug。)。如果你擁有這些.class檔對(duì)應(yīng)的源文件，可把這些.java文件再選上，這樣便可以從稍后得出的報(bào)告中快捷的定位到出問題的代碼上面。此外，還可以選上工程所使用的library，這樣似乎可以幫助FindBugs做一些高階的檢查，藉以發(fā)現(xiàn)一些更深層的bug。
選定了以上各項(xiàng)后，便可以開始檢測了。檢測的過程可能會(huì)花好幾分鐘，具體視工程的規(guī)模而定。檢測完畢可生成一份詳細(xì)的報(bào)告，藉由這份報(bào)告，可以發(fā)現(xiàn)許多代碼中間潛在的bug。比較典型的，如引用了空指針(null pointer dereference), 特定的資源(db connection)未關(guān)閉，等等。如果用人工檢查的方式，這些bug可能很難才會(huì)被發(fā)現(xiàn)，或許永遠(yuǎn)也無法發(fā)現(xiàn)，直到運(yùn)行時(shí)發(fā)作…當(dāng)除掉了這些典型的(classic) bug后，可以確信的是，我們的系統(tǒng)穩(wěn)定度將會(huì)上一個(gè)新的臺(tái)階。

以目前遇到的狀況來看，F(xiàn)indBugs可以有兩種使用時(shí)機(jī)。
開發(fā)階段
當(dāng)Developer完成了某一部分功能模塊開發(fā)的時(shí)候(這通常是指代碼撰寫完成，并已debug通過之后)，可藉由FindBugs對(duì)該模塊涉及的java文件進(jìn)行一次掃描，以發(fā)現(xiàn)一些不易察覺的bug或是效能問題。交付新版的時(shí)候，開發(fā)團(tuán)隊(duì)可以跑一下FindBugs，除掉一些隱藏的Bug。FindBugs得出的報(bào)告可以作為該版本的一個(gè)參考文檔一并交付給測試團(tuán)隊(duì)留檔待查。
在開發(fā)階段使用FindBugs，一方面開發(fā)人員可以對(duì)新版的品質(zhì)更有信心，另一方面，測試人員藉此可以把更多的精力放在業(yè)務(wù)邏輯的確認(rèn)上面，而不是花大量精力去進(jìn)一些要在特殊狀況下才可能出現(xiàn)的BUG(典型的如Null Pointer Dereference)。從而可以提高測試的效率。
維護(hù)階段
這里指的是系統(tǒng)已經(jīng)上線，卻發(fā)現(xiàn)因?yàn)榇a中的某一個(gè)bug導(dǎo)致系統(tǒng)崩潰。在除掉這個(gè)已暴露的bug之后，為了快速的找出類似的但還未暴露的 bug，可以使用FindBugs對(duì)該版的代碼進(jìn)行掃描。當(dāng)然，在維護(hù)階段使用FindBugs往往是無奈之舉，且時(shí)間緊迫。此外，如果本來在新版交付的時(shí)候就使用過FindBugs的話，往往意味著這種bug是FindBugs還無法檢測出的。這也是FindBugs局限的地方。
FindBugs出到目前的版本，功能已經(jīng)相當(dāng)強(qiáng)大，不過也有待完善的地方。從實(shí)際使用來看，有一些隱藏的bug并不能靠FindBugs直接發(fā)現(xiàn)。那么，可不可以撰寫一個(gè)新的 Detector，來發(fā)現(xiàn)這種將一個(gè)未初始化的reference傳來傳去而形成的潛在的bug呢？理論上來講，應(yīng)該是可以的。這個(gè) Detector目前還未實(shí)現(xiàn)。哪位如果有興趣的話，可以參考FindBugs, Part 2: Writing custom detectors這篇文章，幫忙實(shí)現(xiàn)這個(gè)Detector。實(shí)現(xiàn)一個(gè)新的Detector，便可以檢測出一種新型的bug，這樣不知又可以幫開發(fā)人員省去多少人工檢查的時(shí)間，功德無量啊。

FindBugs也不能發(fā)現(xiàn)非java的Bug。對(duì)于非java撰寫的代碼，如javascript，SQL等等，要找出其中可能的bug，F(xiàn)indBugs是無能為力的。當(dāng)然，javascript中的bug似乎還不至于使系統(tǒng)崩潰，而SQL中的bug往往又跟業(yè)務(wù)邏輯相關(guān)，只要測試仔細(xì)一些應(yīng)該是可以發(fā)現(xiàn)的。

Java靜態(tài)檢查工具對(duì)比

FindBugs不過是一個(gè)工具。作為開發(fā)人員，當(dāng)然首先要在編程的時(shí)候努力避免引入bug，而不要依賴于某個(gè)工具來為自己把關(guān)。不過由于代碼的復(fù)雜性，一些隱藏的bug確實(shí)很難靠咱們的肉眼發(fā)現(xiàn)。這時(shí)，應(yīng)用一些好的工具或許就可以幫你發(fā)現(xiàn)這樣的bug。這便是FingBug存在的價(jià)值。
為什么應(yīng)該將 FindBugs 集成到編譯過程中？
經(jīng)常問到的第一個(gè)問題是為什么要將 FindBugs 加入到編譯過程中？雖然有大量理由，最明顯的回答是要保證盡可能早地在進(jìn)行編譯時(shí)發(fā)現(xiàn)問題。當(dāng)團(tuán)隊(duì)擴(kuò)大，并且不可避免地在項(xiàng)目中加入更多新開發(fā)人員時(shí)，F(xiàn)indBugs 可以作為一個(gè)安全網(wǎng)，檢測出已經(jīng)識(shí)別的缺陷模式。我想重申在一篇 FindBugs 論文中表述的一些觀點(diǎn)。如果讓一定數(shù)量的開發(fā)人員共同工作，那么在代碼中就會(huì)出現(xiàn)缺陷。像 FindBugs 這樣的工具當(dāng)然不會(huì)找出所有的缺陷，但是它們會(huì)幫助找出其中的部分。現(xiàn)在找出部分比客戶在以后找到它們要好——特別是當(dāng)將 FindBugs 結(jié)合到編譯過程中的成本是如此低時(shí)。
一旦確定了加入哪些過濾器和類，運(yùn)行 FindBugs 就沒什么成本了，而帶來的好處就是它會(huì)檢測出新缺陷。如果編寫特定于應(yīng)用程序的檢測器，則這個(gè)好處可能更大。
生成有意義的結(jié)果
重要的是要認(rèn)識(shí)到這種成本/效益分析只有在不生成大量誤檢時(shí)才有效。換句話說，如果在每次編譯時(shí)，不能簡單地確定是否引入了新的缺陷，那么這個(gè)工具的價(jià)值就會(huì)被抵消。分析越自動(dòng)化越好。如果修復(fù)缺陷意味著必須吃力地分析檢測出的大量不相干的缺陷，那么您就不會(huì)經(jīng)常使用它，或者至少不會(huì)很好地使用它。
確定不關(guān)心哪些問題并從編譯中排除它們。也可以挑出 確實(shí)關(guān)注的一小部分檢測器并只運(yùn)行它們。另一種選擇是從個(gè)別的類中排除一組檢測器，但是其他的類不排除。FindBugs 提供了使用過濾器的極大靈活性，這可幫助生成對(duì)團(tuán)隊(duì)有意義的結(jié)果，由此我們進(jìn)入下一節(jié)。
確定用 FindBugs 的結(jié)果做什么
可能看來很顯然，但是您想不到我參與的團(tuán)隊(duì)中有多少加入了類似 FindBugs 這樣的工具而沒有真正利用它。讓我們更深入地探討這個(gè)問題——用結(jié)果做什么？明確回答這個(gè)問題是困難的，因?yàn)檫@與團(tuán)隊(duì)的組織方式、如何處理代碼所有權(quán)問題等有很大關(guān)系。不過，下面是一些指導(dǎo)：
可以考慮將 FindBugs 結(jié)果加入到源代碼管理（SCM）系統(tǒng)中。一般的經(jīng)驗(yàn)做法是不將編譯工件（artifact）放到 SCM 系統(tǒng)中。不過，在這種特定情況下，打破這個(gè)規(guī)則可能是正確的，因?yàn)樗鼓梢员O(jiān)視代碼質(zhì)量隨時(shí)間的變化。
可以選擇將 XML 結(jié)果轉(zhuǎn)換為可以發(fā)送到團(tuán)隊(duì)的網(wǎng)站上的 HTML 報(bào)告。轉(zhuǎn)換可以用 XSL 樣式表或者腳本實(shí)現(xiàn)。有關(guān)例子請(qǐng)查看 FindBugs 網(wǎng)站或者郵件列表。

FindBugs在Eclipse中使用的情況

http://www.cnblogs.com/doit8791/archive/2012/10/22/2734730.html

FindBugs是一個(gè)可以在Java程序中發(fā)現(xiàn)Bugs的程序。它是專門用來尋找處于"Bug Patterns"列表中的代碼的。Bug Patterns指很有可能是錯(cuò)誤的代碼的實(shí)例。

打開Bug Details視圖Windows => Show View => Other… => FindBugs => BugDetails

在Package Explorer或Navigator視圖中，選中你的Java項(xiàng)目，右鍵，可以看到"Find Bugs"菜單項(xiàng)，子菜單項(xiàng)里有"Find Bugs"和"Clear Bug Markers"兩項(xiàng)內(nèi)容，如下圖所示：

我們建立一個(gè)簡單的測試文件Test.java 內(nèi)容如下：

我們點(diǎn)中"Find Bugs"，運(yùn)行時(shí)會(huì)出現(xiàn)如下進(jìn)度框：

運(yùn)行結(jié)束后可以在Problems中看到增加了如下的警告信息內(nèi)容

FindBugs運(yùn)行后的警告信息內(nèi)容不僅在Problems視圖中顯示，而且將標(biāo)記在源代碼標(biāo)記框中，在源代碼編輯器中我們可以看到警告標(biāo)識(shí)，如下圖：

當(dāng)光標(biāo)指向你的警告信息的代碼上面時(shí)，就會(huì)有相應(yīng)的錯(cuò)誤提示信息，與Eclipse本身的錯(cuò)誤或警告信息提示類似。

選中Problems視圖里出現(xiàn)的相應(yīng)問題，就會(huì)在代碼編輯器里切換到相應(yīng)的代碼上去，方便根據(jù)相應(yīng)的提示信息進(jìn)行代碼的修改。

在Problems視圖里，選中相應(yīng)的問題條目，右鍵，在彈出的菜單中，可以看到"Show Bug Details"，如下圖所示：

點(diǎn)中它，會(huì)切換到Bug Details視圖上去，顯示更加詳細(xì)的提示信息。

當(dāng)然，在代碼編輯窗口中，點(diǎn)擊帶有警告提示信息的圖標(biāo)時(shí)，也會(huì)自動(dòng)切換到Bud Details窗口去，查看詳細(xì)的警告信息，如下圖所示。

根據(jù)這里詳細(xì)的信息，你可以得到FindBugs為什么會(huì)對(duì)你的代碼報(bào)警告信息，及相應(yīng)的處理辦法，根據(jù)它的提示，你可以快速方便地進(jìn)行代碼修改。

根據(jù)提示，我們將代碼修改成如下，再運(yùn)行就不會(huì)報(bào)有警告信息了。

配置FindBugs

選擇你的項(xiàng)目，右鍵 => Properties => FindBugs =>

可以配置的信息包括如上圖所示的四個(gè)選項(xiàng)的相關(guān)設(shè)置：

1. Run FindBugs Automatically開關(guān)

當(dāng)此項(xiàng)選中后，F(xiàn)indBugs將會(huì)在你修改Java類時(shí)自動(dòng)運(yùn)行，如你設(shè)置了Eclipse自動(dòng)編譯開關(guān)后，當(dāng)你修改完Java文件保存，F(xiàn)indBugs就會(huì)運(yùn)行，并將相應(yīng)的信息顯示出來。

當(dāng)此項(xiàng)沒有選中，你只能每次在需要的時(shí)候自己去運(yùn)行FindBugs來檢查你的代碼。

2. Minimum priority to report選擇項(xiàng)

這個(gè)選擇項(xiàng)是讓你選擇哪個(gè)級(jí)別的信息進(jìn)行顯示，有Low、Medium、High三個(gè)選擇項(xiàng)可以選擇，很類似于Log4J的級(jí)別設(shè)置啦。 比如：

你選擇了High選擇項(xiàng)，那么只有是High級(jí)別的提示信息才會(huì)被顯示。

你選擇了Medium選擇項(xiàng)，那么只有是Medium和High級(jí)別的提示信息才會(huì)被顯示。

你選擇了Low選擇項(xiàng)，那么所有級(jí)別的提示信息都會(huì)被顯示。

3. Enable bug categories選擇項(xiàng)

在這里是一些顯示Bug分類的選擇：

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

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

Internationalization關(guān)于代碼國際化相關(guān)方面的

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

Style關(guān)于代碼樣式相關(guān)方面的

Malicious code vulnerability關(guān)于惡意破壞代碼相關(guān)方面的

比如：如果你把Style的檢查框去掉不選擇中它，那么與Style分類相關(guān)的警告信息就不會(huì)顯示了。其它的類似。

4. Select bug patterns to check for選擇項(xiàng)

在這里你可以選擇所要進(jìn)行檢查的相關(guān)的Bug Pattern條目

可以從Bug codes、Detector name、Detector description中看到相應(yīng)的是要檢查哪些方面的內(nèi)容，你可以根據(jù)需要選擇或去掉相應(yīng)的 檢查條件。

三、詳細(xì)說明

Findbugs是一個(gè)靜態(tài)分析工具，它檢查類或者JAR 文件，將字節(jié)碼與一組缺陷模式進(jìn)行對(duì)比以發(fā)現(xiàn)可能的問題。Findbugs自帶檢測器，其中有60余種Bad practice，80余種Correctness，1種 Internationalization，12種Malicious code vulnerability，27種Multithreaded correctness，23種Performance，43種Dodgy。

Bad practice 壞的實(shí)踐

一些不好的實(shí)踐，下面列舉幾個(gè)：

HE： ?類定義了equals()，卻沒有hashCode()；或類定義了equals()，卻使用

Object.hashCode()；或類定義了hashCode()，卻沒有equals()；或類定義了hashCode()，卻使用Object.equals()；類繼承了equals()，卻使用Object.hashCode()。

SQL： Statement 的execute方法調(diào)用了非常量的字符串；或Prepared Statement是由一個(gè)非常量的字符串產(chǎn)生。

DE： ?方法終止或不處理異常，一般情況下，異常應(yīng)該被處理或報(bào)告，或被方法拋出。

Correctness 一般的正確性問題

可能導(dǎo)致錯(cuò)誤的代碼，下面列舉幾個(gè)：

NP： ?空指針被引用；在方法的異常路徑里，空指針被引用；方法沒有檢查參數(shù)是否null；null值產(chǎn)生并被引用；null值產(chǎn)生并在方法的異常路徑被引用；傳給方法一個(gè)聲明為@NonNull的null參數(shù)；方法的返回值聲明為@NonNull實(shí)際是null。

Nm： ?類定義了hashcode()方法，但實(shí)際上并未覆蓋父類Object的hashCode()；類定義了tostring()方法，但實(shí)際上并未覆蓋父類Object的toString()；很明顯的方法和構(gòu)造器混淆；方法名容易混淆。

SQL： 方法嘗試訪問一個(gè)Prepared Statement的0索引；方法嘗試訪問一個(gè)ResultSet的0索引。

UwF： 所有的write都把屬性置成null，這樣所有的讀取都是null，這樣這個(gè)屬性是否有必要存在；或?qū)傩詮臎]有被write。

Internationalization 國際化

當(dāng)對(duì)字符串使用upper或lowercase方法，如果是國際的字符串，可能會(huì)不恰當(dāng)?shù)霓D(zhuǎn)換。

Malicious code vulnerability 可能受到的惡意攻擊

如果代碼公開，可能受到惡意攻擊的代碼，下面列舉幾個(gè)：

FI： ?一個(gè)類的finalize()應(yīng)該是protected，而不是public的。

MS： 屬性是可變的數(shù)組；屬性是可變的Hashtable；屬性應(yīng)該是package protected的。

Multithreaded correctness 多線程的正確性

多線程編程時(shí)，可能導(dǎo)致錯(cuò)誤的代碼，下面列舉幾個(gè)：

ESync： 空的同步塊，很難被正確使用。

MWN： 錯(cuò)誤使用notify()，可能導(dǎo)致IllegalMonitorStateException異常；或錯(cuò)誤的

使用wait()。

No： ?使用notify()而不是notifyAll()，只是喚醒一個(gè)線程而不是所有等待的線程。

SC： ?構(gòu)造器調(diào)用了Thread.start()，當(dāng)該類被繼承可能會(huì)導(dǎo)致錯(cuò)誤。

Performance 性能問題

可能導(dǎo)致性能不佳的代碼，下面列舉幾個(gè)：

DM： 方法調(diào)用了低效的Boolean的構(gòu)造器，而應(yīng)該用Boolean.valueOf(…)；用類似

Integer.toString(1) 代替new Integer(1).toString()；方法調(diào)用了低效的float的構(gòu)造器，應(yīng)該用靜態(tài)的valueOf方法。

SIC： 如果一個(gè)內(nèi)部類想在更廣泛的地方被引用，它應(yīng)該聲明為static。

SS： ?如果一個(gè)實(shí)例屬性不被讀取，考慮聲明為static。

UrF： 如果一個(gè)屬性從沒有被read，考慮從類中去掉。

UuF： 如果一個(gè)屬性從沒有被使用，考慮從類中去掉。

Dodgy 危險(xiǎn)的

具有潛在危險(xiǎn)的代碼，可能運(yùn)行期產(chǎn)生錯(cuò)誤，下面列舉幾個(gè)：

CI： ?類聲明為final但聲明了protected的屬性。

DLS： 對(duì)一個(gè)本地變量賦值，但卻沒有讀取該本地變量；本地變量賦值成null，卻沒有讀取該本地變量。

ICAST： ?整型數(shù)字相乘結(jié)果轉(zhuǎn)化為長整型數(shù)字，應(yīng)該將整型先轉(zhuǎn)化為長整型數(shù)字再相乘。

INT： 沒必要的整型數(shù)字比較，如X <= Integer.MAX_VALUE。

NP： ?對(duì)readline()的直接引用，而沒有判斷是否null；對(duì)方法調(diào)用的直接引用，而方法可能返回null。

REC： 直接捕獲Exception，而實(shí)際上可能是RuntimeException。

ST： ?從實(shí)例方法里直接修改類變量，即static屬性。

Findbugs學(xué)習(xí)小結(jié)&使用筆記