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

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

FindBugs也不能發現非java的Bug。對于非java撰寫的代碼，如javascript，SQL等等，要找出其中可能的bug，FindBugs是無能為力的。當然，javascript中的bug似乎還不至于使系統崩潰，而SQL中的bug往往又跟業務邏輯相關，只要測試仔細一些應該是可以發現的。

Java靜態檢查工具對比

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

FindBugs在Eclipse中使用的情況

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

FindBugs是一個可以在Java程序中發現Bugs的程序。它是專門用來尋找處于"Bug Patterns"列表中的代碼的。Bug Patterns指很有可能是錯誤的代碼的實例。

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

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

我們建立一個簡單的測試文件Test.java 內容如下：

我們點中"Find Bugs"，運行時會出現如下進度框：

運行結束后可以在Problems中看到增加了如下的警告信息內容

FindBugs運行后的警告信息內容不僅在Problems視圖中顯示，而且將標記在源代碼標記框中，在源代碼編輯器中我們可以看到警告標識，如下圖：

當光標指向你的警告信息的代碼上面時，就會有相應的錯誤提示信息，與Eclipse本身的錯誤或警告信息提示類似。

選中Problems視圖里出現的相應問題，就會在代碼編輯器里切換到相應的代碼上去，方便根據相應的提示信息進行代碼的修改。

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

點中它，會切換到Bug Details視圖上去，顯示更加詳細的提示信息。

當然，在代碼編輯窗口中，點擊帶有警告提示信息的圖標時，也會自動切換到Bud Details窗口去，查看詳細的警告信息，如下圖所示。

根據這里詳細的信息，你可以得到FindBugs為什么會對你的代碼報警告信息，及相應的處理辦法，根據它的提示，你可以快速方便地進行代碼修改。

根據提示，我們將代碼修改成如下，再運行就不會報有警告信息了。

配置FindBugs

選擇你的項目，右鍵 => Properties => FindBugs =>

可以配置的信息包括如上圖所示的四個選項的相關設置：

1. Run FindBugs Automatically開關

當此項選中后，FindBugs將會在你修改Java類時自動運行，如你設置了Eclipse自動編譯開關后，當你修改完Java文件保存，FindBugs就會運行，并將相應的信息顯示出來。

當此項沒有選中，你只能每次在需要的時候自己去運行FindBugs來檢查你的代碼。

2. Minimum priority to report選擇項

這個選擇項是讓你選擇哪個級別的信息進行顯示，有Low、Medium、High三個選擇項可以選擇，很類似于Log4J的級別設置啦。 比如：

你選擇了High選擇項，那么只有是High級別的提示信息才會被顯示。

你選擇了Medium選擇項，那么只有是Medium和High級別的提示信息才會被顯示。

你選擇了Low選擇項，那么所有級別的提示信息都會被顯示。

3. Enable bug categories選擇項

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

Correctness關于代碼正確性相關方面的

Performance關于代碼性能相關方面的

Internationalization關于代碼國際化相關方面的

Multithreaded correctness關于代碼多線程正確性相關方面的

Style關于代碼樣式相關方面的

Malicious code vulnerability關于惡意破壞代碼相關方面的

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

4. Select bug patterns to check for選擇項

在這里你可以選擇所要進行檢查的相關的Bug Pattern條目

可以從Bug codes、Detector name、Detector description中看到相應的是要檢查哪些方面的內容，你可以根據需要選擇或去掉相應的 檢查條件。

三、詳細說明

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

Bad practice 壞的實踐

一些不好的實踐，下面列舉幾個：

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

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

SQL： Statement 的execute方法調用了非常量的字符串；或Prepared Statement是由一個非常量的字符串產生。

DE： ?方法終止或不處理異常，一般情況下，異常應該被處理或報告，或被方法拋出。

Correctness 一般的正確性問題

可能導致錯誤的代碼，下面列舉幾個：

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

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

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

UwF： 所有的write都把屬性置成null，這樣所有的讀取都是null，這樣這個屬性是否有必要存在；或屬性從沒有被write。

Internationalization 國際化

當對字符串使用upper或lowercase方法，如果是國際的字符串，可能會不恰當的轉換。

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

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

FI： ?一個類的finalize()應該是protected，而不是public的。

MS： 屬性是可變的數組；屬性是可變的Hashtable；屬性應該是package protected的。

Multithreaded correctness 多線程的正確性

多線程編程時，可能導致錯誤的代碼，下面列舉幾個：

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

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

使用wait()。

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

SC： ?構造器調用了Thread.start()，當該類被繼承可能會導致錯誤。

Performance 性能問題

可能導致性能不佳的代碼，下面列舉幾個：

DM： 方法調用了低效的Boolean的構造器，而應該用Boolean.valueOf(…)；用類似

Integer.toString(1) 代替new Integer(1).toString()；方法調用了低效的float的構造器，應該用靜態的valueOf方法。

SIC： 如果一個內部類想在更廣泛的地方被引用，它應該聲明為static。

SS： ?如果一個實例屬性不被讀取，考慮聲明為static。

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

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

Dodgy 危險的

具有潛在危險的代碼，可能運行期產生錯誤，下面列舉幾個：

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

DLS： 對一個本地變量賦值，但卻沒有讀取該本地變量；本地變量賦值成null，卻沒有讀取該本地變量。

ICAST： ?整型數字相乘結果轉化為長整型數字，應該將整型先轉化為長整型數字再相乘。

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

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

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

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

Findbugs學習小結&使用筆記