1、Security 關於代碼安全性防禦java
DMI_CONSTANT_DB_PASSWORD
代碼中建立DB的密碼時採用了寫死的密碼。程序員
DMI_EMPTY_DB_PASSWORD
建立數據庫鏈接時沒有爲數據庫設置密碼，這會使數據庫沒有必要的保護。web
HRS_REQUEST_PARAMETER_TO_COOKIE
此代碼使用不受信任的HTTP參數構造一個HTTP Cookie。正則表達式
HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
在代碼中直接把一個HTTP的參數寫入一個HTTP頭文件中，它爲HTTP的響應暴露了漏洞。數據庫
SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE
該方法以字符串的形式來調用SQLstatement的execute方法，它彷佛是動態生成SQL語句的方法。這會更容易受到SQL注入攻擊。windows
XSS_REQUEST_PARAMETER_TO_JSP_WRITER
在代碼中在JSP輸出中直接寫入一個HTTP參數，這會形成一個跨站點的腳本漏洞。數組
2、Experimental 關於代碼實驗性問題
LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE
OpenJDK的引入了一種潛在的不兼容問題，特別是，java.util.logging.Logger的行爲改變時。它如今使用內部弱引用，而不是強引用。–logger配置改變，它就是丟失對logger的引用，這本是一個合理的變化，但不幸的是一些代碼對舊的行爲有依賴關係。這意味着，當進行垃圾收集時對logger配置將會丟失。例如：安全
public static void initLogging() throws Exception {服務器
Logger logger = Logger.getLogger("edu.umd.cs");數據結構
logger.addHandler(new FileHandler()); // call to change logger configuration
logger.setUseParentHandlers(false); // another call to change logger configuration
}
該方法結束時logger的引用就丟失了，若是你剛剛結束調用initLogging方法後進行垃圾回收，logger的配置將會丟失（由於只有保持記錄器弱引用）。
public static void main(String[] args) throws Exception {
initLogging(); // adds a file handler to the logger
System.gc(); // logger configuration lost
Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected
}
OBL_UNSATISFIED_OBLIGATION
這種方法可能沒法清除（關閉，處置）一個流，數據庫對象，或其餘資源須要一個明確的清理行動。
通常來講，若是一個方法打開一個流或其餘資源，該方法應該使用try / finally塊來確保在方法返回以前流或資源已經被清除了。這種錯誤模式基本上和OS_OPEN_STREAM和ODR_OPEN_DATABASE_RESOURCE錯誤模式相同，可是是在不一樣在靜態分析技術。咱們正爲這個錯誤模式的效用收集反饋意見。
3、Bad practice代碼實現中的一些壞習慣
AM_CREATES_EMPTY_JAR_FILE_ENTRY
調用putNextEntry()方法寫入新的 jar 文件條目時當即調用closeEntry()方法。這樣會形成JarFile條目爲空。
AM_CREATES_EMPTY_ZIP_FILE_ENTRY
調用putNextEntry()方法寫入新的 zip 文件條目時當即調用closeEntry()方法。這樣會形成ZipFile條目爲空。
BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS
equals(Object o)方法不能對參數o的類型作任何的假設。比較此對象與指定的對象。當且僅當該參數不爲 null，而且是表示與此對象相同的類型的對象時，結果才爲 true。
DMI_RANDOM_USED_ONLY_ONCE
隨機建立對象只使用過一次就拋棄
BIT_SIGNED_CHECK
檢查位操做符運行是否合理
((event.detail & SWT.SELECTED) > 0)
If SWT.SELECTED is a negative number, this is a candidate for a bug. Even when SWT.SELECTED is not negative, it seems good practice to use '!= 0' instead of '> 0'.
CN_IDIOM
按照慣例，實現此接口的類應該使用公共方法重寫 Object.clone（它是受保護的），以得到有關重寫此方法的詳細信息。此接口不 包含 clone 方法。所以，由於某個對象實現了此接口就克隆它是不可能的,應該實現此接口的類應該使用公共方法重寫 Object.clone
CN_IDIOM_NO_SUPER_CALL
一個非final類型的類定義了clone()方法而沒有調用super.clone()方法。例如：B擴展自A，若是B中clone方法調用了spuer.clone（），而A中的clone沒有調用spuer.clone()，就會形成結果類型不許確。要求A的clone方法中調用spuer.clone()方法。
CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE
類中定義了clone方法可是它沒有實現Cloneable接口
CO_ABSTRACT_SELF
抽象類中定義了多個compareTo()方法，正確的是覆寫Comparable中的compareTo方法，方法的參數爲Object類型，以下例：
int compareTo(T o) 比較此對象與指定對象的順序。
CO_SELF_NO_OBJECT
類中定義了多個compareTo()方法，正確的是覆寫Comparable中的compareTo方法，方法的參數爲Object類型
DE_MIGHT_DROP
方法可能拋出異常
DE_MIGHT_IGNORE
此方法可能忽略異常。一般，應該以某種方式處理或報告異常，或者將異常拋出方法。
DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION
不要用removeAll方法去clear一個集合
DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED
類加載器只能創建在特殊的方法體內
DM_EXIT
在方法中調用System.exit(...)語句，考慮用RuntimeException來代替
DM_RUN_FINALIZERS_ON_EXIT
在方法中調用了System.runFinalizersOnExit 或者Runtime.runFinalizersOnExit方法，由於這樣作是很危險的。
ES_COMPARING_PARAMETER_STRING_WITH_EQ
用==或者!=方法去比較String類型的參數
ES_COMPARING_STRINGS_WITH_EQ
用==或者！=去比較String類型的對象
EQ_ABSTRACT_SELF
This class defines a covariant version of equals(). To correctly override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object.
這個類定義了equals()方法，可是參數倒是Object的子類。正確覆蓋equals()方法，參數必須是Object
EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS
equals方法檢查不一致的操做。兩個類根本就是父子關係而去調用equals方法去判讀對象是否相等。
public boolean equals(Object o) {
if (o instanceof Foo)
return name.equals(((Foo)o).name);
else if (o instanceof String)
return name.equals(o);
else return false;
EQ_COMPARETO_USE_OBJECT_EQUALS
類中定義了compareTo方法可是繼承了Object中的compareTo方法
22.Eq: equals method fails for subtypes (EQ_GETCLASS_AND_CLASS_CONSTANT)
類中的equals方法可能被子類中的方法所破壞，當使用相似於Foo.class == o.getClass()的判斷時考慮用this.getClass() == o.getClass()來替換
EQ_SELF_NO_OBJECT
類中定義了多個equals方法。正確的作法是覆寫Object中的equals方法，它的參數爲Object類型的對象。
FI_EMPTY
爲空的finalizer方法應該刪除。一下關於finalizer的內容省略
GC_UNCHECKED_TYPE_IN_GENERIC_CALL
This call to a generic collection method passes an argument while compile type Object where a specific type from the generic type parameters is expected. Thus, neither the standard Java type system nor static analysis can provide useful information on whether the object being passed as a parameter is of an appropriate type.
此對泛型集合方法的調用在編譯類型對象時傳遞一個參數，其中預期泛型類型參數中的特定類型。所以，標準Java類型系統和靜態分析都不能提供關於做爲參數傳遞的對象是否屬於適當類型的有用信息。
HE_EQUALS_NO_HASHCODE
方法定義了equals方法卻沒有定義hashCode方法
HE_HASHCODE_NO_EQUALS
類定義了hashCode方法去沒有定義equal方法
HE_EQUALS_USE_HASHCODE
一個類覆寫了equals方法，沒有覆寫hashCode方法，使用了Object對象的hashCode方法
HE_INHERITS_EQUALS_USE_HASHCODE
子類繼承了父類的equals方法卻使用了Object的hashCode方法
IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION
子類在父類未初始化以前使用父類對象實例
public class CircularClassInitialization {
static class InnerClassSingleton extends CircularClassInitialization {
static InnerClassSingleton singleton = new InnerClassSingleton();
}
static CircularClassInitialization foo = InnerClassSingleton.singleton;
}
IMSE_DONT_CATCH_IMSE
捕捉違法的監控狀態異常，例如當沒有獲取到對象鎖時使用其wait和notify方法
ISC_INSTANTIATE_STATIC_CLASS
爲使用靜態方法而建立一個實例對象。調用靜態方法時只須要使用類名+靜態方法名就能夠了。
IT_NO_SUCH_ELEMENT
迭代器的next方法不可以拋出NoSuchElementException
J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION
在HttpSession對象中保存非連續的對象
JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS
The class is annotated with net.jcip.annotations.Immutable, and the rules for that annotation require that all fields are final. .
該類使用net.jcip.annotations進行註釋。不可變的，該註釋的規則要求全部字段都是final
NP_BOOLEAN_RETURN_NULL
返回值爲boolean類型的方法直接返回null，這樣會致使空指針異常
NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
變量調用equals方法時沒有進行是否爲null的判斷
NP_TOSTRING_COULD_RETURN_NULL
toString方法可能返回null
NM_CLASS_NAMING_CONVENTION
類的名稱以大寫字母名稱開頭
NM_CLASS_NOT_EXCEPTION
類的名稱中含有Exception可是卻不是一個異常類的子類，這種名稱會形成混淆
NM_CONFUSING
使人迷惑的方面命名
NM_FIELD_NAMING_CONVENTION
非final類型的字段須要遵循駝峯命名原則
NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER
驗證是不是java預留關鍵字
NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER
驗證是否時java中的關鍵字
NM_METHOD_NAMING_CONVENTION
方法名稱以小寫字母開頭
NM_SAME_SIMPLE_NAME_AS_INTERFACE
實現同一接口實現類不能使用相同的名稱，即便它們位於不一樣的包中
NM_SAME_SIMPLE_NAME_AS_SUPERCLASS
繼承同一父類的子類不能使用相同的名稱，即便它們位於不一樣的包中
NM_VERY_CONFUSING_INTENTIONAL
很容易混淆的方法命名，例如方法的名稱名稱使用使用大小寫來區別兩個不一樣的方法。
NM_WRONG_PACKAGE_INTENTIONAL
因爲錯誤引用了不一樣包中相同類名的對象而不可以正確的覆寫父類中的方法
import alpha.Foo;
public class A {
public int f(Foo x) { return 17; }
}
import beta.Foo;
public class B extends A {
public int f(Foo x) { return 42; }
public int f(alpha.Foo x) { return 27; }
}
ODR_OPEN_DATABASE_RESOURCE
方法中可能存在關閉數據鏈接失敗的狀況
OS_OPEN_STREAM
方法中可能存在關閉流失敗的狀況
OS_OPEN_STREAM_EXCEPTION_PATH
方法中可能存在關閉流時出現異常狀況
RC_REF_COMPARISON_BAD_PRACTICE
當二者爲不一樣類型的對象時使用equals方法來比較它們的值是否相等，而不是使用==方法。例如比較的二者爲java.lang.Integer, java.lang.Float
RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN
使用== 或者 !=操做符來比較兩個 Boolean類型的對象，建議使用equals方法。
RR_NOT_CHECKED
InputStream.read方法忽略返回的多個字符，若是對結果沒有檢查就無法正確處理用戶讀取少許字符請求的狀況。
SR_NOT_CHECKED
InputStream.skip()方法忽略返回的多個字符，若是對結果沒有檢查就無法正確處理用戶跳過少許字符請求的狀況
RV_RETURN_VALUE_IGNORED_BAD_PRACTICE
方法忽略返回值的異常信息
SI_INSTANCE_BEFORE_FINALS_ASSIGNED
在全部的static final字段賦值以前去使用靜態初始化的方法建立一個類的實例。
SE_BAD_FIELD_STORE
非序列化的值保存在聲明爲序列化的的非序列化字段中
SE_COMPARATOR_SHOULD_BE_SERIALIZABLE
Comparator接口沒有實現Serializable接口
SE_INNER_CLASS
序列化內部類
SE_NONFINAL_SERIALVERSIONID
關於UID類的檢查內容省略
SE_NO_SUITABLE_CONSTRUCTOR
子類序列化時父類沒有提供一個void的構造函數
SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION
Externalizable 實例類沒有定義一個void類型的構造函數
SE_READ_RESOLVE_MUST_RETURN_OBJECT
readResolve從流中讀取類的一個實例，此方法必須聲明返回一個Object類型的對象
SE_TRANSIENT_FIELD_NOT_RESTORED
This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.
該類包含一個在類中的多個位置更新的字段，所以它彷佛是類狀態的一部分。可是，因爲字段被標記爲transient，而且沒有在readObject或readResolve中設置，因此它將在類的任何反序列化實例中包含默認值。
SE_NO_SERIALVERSIONID
一個類實現了Serializable接口可是沒有定義serialVersionUID類型的變量。序列化運行時使用一個稱爲 serialVersionUID 的版本號與每一個可序列化類相關聯，該序列號在反序列化過程當中用於驗證序列化對象的發送者和接收者是否爲該對象加載了與序列化兼容的類。若是接收者加載的該對象的類的 serialVersionUID 與對應的發送者的類的版本號不一樣，則反序列化將會致使 InvalidClassException。可序列化類能夠經過聲明名爲 "serialVersionUID" 的字段（該字段必須是靜態 (static)、最終 (final) 的 long 型字段）顯式聲明其本身的 serialVersionUID：
ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
UI_INHERITANCE_UNSAFE_GETRESOURCE
當一個類被子類繼承後不要使用this.getClass().getResource(...)來獲取資源
4、Correctness關於代碼正確性相關方面的
BC_IMPOSSIBLE_CAST
不可能的類轉換，執行時會拋出ClassCastException
BC_IMPOSSIBLE_DOWNCAST
父類在向下進行類型轉換時拋出ClassCastException
BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY
集合轉換爲數組元素時發生的類轉換錯誤。
This code is casting the result of calling toArray() on a collection to a type more specific than Object[], as in:
String[] getAsArray(Collection<String> c) {
return (String[]) c.toArray();
}
This will usually fail by throwing a ClassCastException. The toArray() of almost all collections return an Object[]. They can't really do anything else, since the Collection object has no reference to the declared generic type of the collection.
The correct way to do get an array of a specific type from a collection is to use c.toArray(new String[]); or c.toArray(new String[c.size()]); (the latter is slightly more efficient).
BC_IMPOSSIBLE_INSTANCEOF
採用instaneof方法進行比較時老是返回false。前提是保證它不是因爲某些邏輯錯誤形成的。
BIT_AND
錯誤的使用&位操做符，例如(e & C)
BIT_AND_ZZ
檢查恆等的邏輯錯誤
BIT_IOR
錯誤的使用|位操做符，例如(e | C)
BIT_SIGNED_CHECK_HIGH_BIT
檢查邏輯運算符操做返回的標識。例如((event.detail & SWT.SELECTED) > 0)，建議採用!=0代替>0
BOA_BADLY_OVERRIDDEN_ADAPTER
子類錯誤的覆寫父類中用於適配監聽其餘事件的方法，從而致使當觸發條件發生時不能被監聽者調用
BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR
在三元運算符操做時若是沒有對值進行封裝或者類型轉換。例如：b ? e1 : e2
DLS_DEAD_STORE_OF_CLASS_LITERAL
以類的字面名稱方式爲一個字段賦值後再也沒有去使用它，在1.4jdk中它會自動調用靜態的初始化方法，而在jdk1.5中卻不會去執行。
DLS_OVERWRITTEN_INCREMENT
覆寫增量增長錯誤i = i++
DMI_BAD_MONTH
hashNext方法調用next方法。
DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES
集合沒有包含他們本身自己。
DMI_INVOKING_HASHCODE_ON_ARRAY
數組直接使用hashCode方法來返回哈希碼。
int [] a1 = new int[]{1,2,3,4}; System.out.println(a1.hashCode()); System.out.println(java.util.Arrays.hashCode(a1));
DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT
Double.longBitsToDouble invoked on an int
在int上調用了Double.longBitsToDouble
DMI_VACUOUS_SELF_COLLECTION_CALL
集合的調用不能被感知。例如c.containsAll(c)老是返回true，而c.retainAll(c)的返回值不能被感知。
DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION
Unless an annotation has itself been annotated with @Retention(RetentionPolicy.RUNTIME), the annotation can't be observed using reflection (e.g., by using the isAnnotationPresent method). .
除非註釋自己使用@Retention(RetentionPolicy.RUNTIME)進行了註釋，不然不能使用反射(例如，使用isAnnotationPresent方法)觀察註釋。
DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD
While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the inherited tuning methods are not useful for it. In particular, because it acts as a fixed-sized pool using corePoolSize threads and an unbounded queue, adjustments to maximumPoolSize have no useful effect.
雖然ScheduledThreadPoolExecutor繼承自ThreadPoolExecutor，可是一些繼承的調優方法對它並不有用。特別是，因爲它使用corePoolSize線程和無界隊列充當固定大小的池，因此對maximumPoolSize的調整沒有任何有用的效果。
EC_ARRAY_AND_NONARRAY
數組對象使用equals方法和非數組對象進行比較。即便比較的雙方都是數組對象也不該該使用equals方法，而應該比較它們的內容是否相等使用java.util.Arrays.equals(Object[], Object[]);
EC_INCOMPATIBLE_ARRAY_COMPARE
使用equls方法去比較類型不相同的數組。例如：String[] and StringBuffer[], or String[] and int[]
EC_NULL_ARG
調用equals的對象爲null
EC_UNRELATED_CLASS_AND_INTERFACE
使用equals方法比較不相關的類和接口
EC_UNRELATED_INTERFACES
調用equals方法比較不一樣類型的接口
EC_UNRELATED_TYPES
調用equals方法比較不一樣類型的類
EC_UNRELATED_TYPES_USING_POINTER_EQUALITY
This method uses using pointer equality to compare two references that seem to be of different types. The result of this comparison will always be false at runtime.
該方法使用指針相等來比較兩個彷佛屬於不一樣類型的引用。這個比較的結果在運行時老是錯誤的。
EQ_ALWAYS_FALSE
使用equals方法返回值老是false
EQ_ALWAYS_TRUE
equals方法返回值老是true
EQ_COMPARING_CLASS_NAMES
使用equals方法去比較一個類的實例和類的類型
EQ_DONT_DEFINE_EQUALS_FOR_ENUM
This class defines an enumeration, and equality on enumerations are defined using object identity. Defining a covariant equals method for an enumeration value is exceptionally bad practice, since it would likely result in having two different enumeration values that compare as equals using the covariant enum method, and as not equal when compared normally. Don't do it.
該類定義枚舉，而且使用對象標識定義枚舉上的等式。爲枚舉值定義一個協變等於方法是一個很是糟糕的實踐，由於它可能會致使使用協變枚舉方法將兩個不一樣的枚舉值做爲等於進行比較，而在正常狀況下比較時做爲不相等。不要這樣作。
EQ_OTHER_NO_OBJECT
類中定義的equals方法時不要覆寫equals（Object）方法
EQ_OTHER_USE_OBJECT
類中定義的equals方法時不要覆寫Object中的equals（Object）方法
EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC
name=錯誤用法 - equals方法覆蓋了父類的equals可能功能不符
EQ_SELF_USE_OBJECT
類中定義了一組equals方法，可是都是繼承的java.lang.Object class中的equals(Object)方法
FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER
This code checks to see if a floating point value is equal to the special Not A Number value (e.g., if (x == Double.NaN)). However, because of the special semantics of NaN, no value is equal to Nan, including NaN. Thus, x == Double.NaN always evaluates to false. To check to see if a value contained in x is the special Not A Number value, use Double.isNaN(x) (or Float.isNaN(x) if x is floating point precision).
name=錯誤用法 - 測試是否與NaN相等
VA_FORMAT_STRING_BAD_ARGUMENT
錯誤使用參數類型來格式化字符串
VA_FORMAT_STRING_BAD_CONVERSION
指定的格式字符串和參數類型不匹配，例如：String.format("%d", "1")
VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED
但用String的format方法時實際調用了ＭｅｓｓａｇｅＦｏｒｍａｔ中乾的格式化方法而引發格式化結果出錯。
VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED
使用String的format方法時有非法的參數也通過了格式化操做。
VA_FORMAT_STRING_ILLEGAL
格式化String對象語句錯誤
VA_FORMAT_STRING_MISSING_ARGUMENT
String的format操做缺乏必要的參數。
VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT
格式字符串定義錯誤，例如：formatter.format("%<s %s", "a", "b"); 拋出MissingFormatArgumentException異常
GC_UNRELATED_TYPES
This call to a generic collection method contains an argument with an incompatible class from that of the collection's parameter (i.e., the type of the argument is neither a supertype nor a subtype of the corresponding generic type argument). Therefore, it is unlikely that the collection contains any objects that are equal to the method argument used here. Most likely, the wrong value is being passed to the method.
In general, instances of two unrelated classes are not equal. For example, if the Foo and Bar classes are not related by subtyping, then an instance of Foo should not be equal to an instance of Bar. Among other issues, doing so will likely result in an equals method that is not symmetrical. For example, if you define the Foo class so that a Foo can be equal to a String, your equals method isn't symmetrical since a String can only be equal to a String.
In rare cases, people do define nonsymmetrical equals methods and still manage to make their code work. Although none of the APIs document or guarantee it, it is typically the case that if you check if a Collection<String> contains a Foo, the equals method of argument (e.g., the equals method of the Foo class) used to perform the equality checks.
這個對泛型集合方法的調用包含一個與集合的參數(即，參數的類型既不是相應泛型類型參數的超類型，也不是相應泛型類型參數的子類型)。所以，集合不太可能包含與這裏使用的方法參數相同的任何對象。極可能，傳遞給方法的值是錯誤的。
HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS
A method, field or class declares a generic signature where a non-hashable class is used in context where a hashable class is required. A class that declares an equals method but inherits a hashCode() method from Object is unhashable, since it doesn't fulfill the requirement that equal objects have equal hashCodes.
方法、字段或類聲明一個泛型簽名，其中在須要可耐洗類的上下文中使用不可耐洗類。聲明equals方法但從對象繼承hashCode()方法的類是不可掛起的，由於它不知足equal對象具備相等hashCode的要求。
HE_USE_OF_UNHASHABLE_CLASS
A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance.
類定義了equals(Object)方法，但沒有定義hashCode()方法，所以不能知足equal對象具備相等hashCode的要求。該類的一個實例用於哈希數據結構中，這使得修復這個問題變得極爲重要。
ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL
integral的值轉換爲double後使用了Math.ceil方法
ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND
int 類型的值轉換爲float類型以後調用了Math.round方法
IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD
在JUnit中的斷言在run方法中不會被告知
IJU_BAD_SUITE_METHOD
在一個JUnit類中聲明的一個suite()方法必須聲明爲
public static junit.framework.Test suite()
或者
public static junit.framework.TestSuite suite()的形式。
IL_CONTAINER_ADDED_TO_ITSELF
集合自己做爲add方法的參數，這樣會引發內容溢出。
IL_INFINITE_LOOP
方法的自調用引發的死循環
IM_MULTIPLYING_RESULT_OF_IREM
和整數餘數進行乘法運算。例如：i % 60 * 1000 是進行(i % 60) * 1000運算而不是 i % (60 * 1000)
INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE
保證非負數和負數進行比較
INT_BAD_COMPARISON_WITH_SIGNED_BYTE
比較有符合數，要先把有符號數轉換爲無符合數再進行比較
IO_APPENDING_TO_OBJECT_OUTPUT_STREAM
宣佈試圖在對象的輸出流處添加元素，若是你但願可以添加進一個對象的輸出流中必須保證對象的輸出流處於打開狀態。
IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN
The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.
傳入參數的值被忽略，可是對傳入值進行了修改，並返回給了調用者
MF_CLASS_MASKS_FIELD
子類中定義了和父類中同名的字段。在調用時會出錯
MF_METHOD_MASKS_FIELD
在方法中定義的局部變量和類變量或者父類變量同名，從而引發字段混淆。
NP_ALWAYS_NULL
對象賦爲null值後 沒有被從新賦值
NP_ALWAYS_NULL_EXCEPTION
A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
空指針引用上調用去除引用方法，將發生空指針異常
NP_ARGUMENT_MIGHT_BE_NULL
方法沒有判斷參數是否爲空
NP_CLOSING_NULL
一個爲空的對象調用close方法
NP_GUARANTEED_DEREF
There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
在正常的null判斷分支上，對象去除引用操做是受保護的不容許的
NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH
There is a statement or branch on an exception path that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
異常路徑上有一個語句或分支，若是執行該語句或分支，則該語句或分支將確保此時值爲空，而且該值將被取消引用(涉及運行時異常的正向路徑除外)。
NP_NONNULL_PARAM_VIOLATION
方法中爲null的參數沒有被從新賦值 void test(){
String ss = null;
sya(ss); } public void sya(String ad){
ad.getBytes(); }
NP_NONNULL_RETURN_VIOLATION
方法聲明瞭返回值不能爲空，可是方法中有可能返回null
NP_NULL_INSTANCEOF
檢查一個爲null的值是不是想要的類型對象，而不是因爲粗心或者邏輯錯誤引發的
NP_NULL_ON_SOME_PATH
對象可能沒有從新賦值
NP_NULL_ON_SOME_PATH_EXCEPTION
A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
在異常null值處理分支調用的方法上，可能存在對象去除引用操做
NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS
方法參數中聲明爲nonnull類型的參數爲null
void test(){
String ss = null;
sya(ss); } public void sya(@nonnull String ad){
ad.getBytes(); }
NP_STORE_INTO_NONNULL_FIELD
爲一個已經聲明爲不能爲null值的屬性賦值爲null。
NM_BAD_EQUAL
類中定義了一個equal方法可是卻不是覆寫的Object對象的equals方法
NM_LCASE_HASHCODE
類中定義了一個hashCode方法可是卻不是覆寫的Object中的hashCode方法
NM_LCASE_TOSTRING
類中定義了一個toString方法可是卻不是覆寫的Object中的toString方法
NM_METHOD_CONSTRUCTOR_CONFUSION
構造方法定義混亂，保證一個標準的構造函數。 例如： SA(){ } void SA(){ }
NM_VERY_CONFUSING
混亂的方法命名，如getName和getname方法同時出現的時候
NM_WRONG_PACKAGE
方法由於取了不一樣包中的同名的對象而沒有正確覆寫父類中的同名方法
import alpha.Foo;
public class A {
public int f(Foo x) { return 17; }
}
----
import beta.Foo;
public class B extends A {
public int f(Foo x) { return 42; }
}
QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT
再if或者while表達式中使用boolean類型的值時應該使用==去判斷，而不是採用=操做
RC_REF_COMPARISON
比較兩個對象值是否相等時應該採用equals方法，而不是==方法
RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION
對正則表達式使用了錯誤的語法，會拋出未經檢查的異常，代表正則表達式模式中的語法錯誤。
RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION
使用正則表達式使用了錯誤的文件分隔符，在windows系統中正則表達式不會匹配’\’而應該使用'\\'
RV_01_TO_INT
從0到1隨機值被強制爲整數值0。在強制獲得一個整數以前，你可能想獲得多個隨機值。或使用Random.nextInt（n）的方法。
RV_ABSOLUTE_VALUE_OF_HASHCODE
此代碼生成一個哈希碼，而後計算該哈希碼的絕對值。若是哈希碼是Integer.MIN_VALUE的，那麼結果將是負數（由於Math.abs（Integer.MIN_VALUE的）== Integer.MIN_VALUE的）。
在2^ 32值以外字符串有一個Integer.MIN_VALUE的hashCode包括「polygenelubricants」，「GydZG_」和「，」DESIGNING WORKHOUSES 「。
RV_ABSOLUTE_VALUE_OF_RANDOM_INT
此代碼生成一個隨機的符號整數，而後計算該隨機整數的絕對值。若是隨機數生成數絕對值爲Integer.MIN_VALUE的，那麼結果將是負數（由於Math.abs（Integer.MIN_VALUE的）== Integer.MIN_VALUE的）。
RV_EXCEPTION_NOT_THROWN
此代碼建立一個異常（或錯誤）的對象，但不會用它作任何事情。例如：if (x < 0)
new IllegalArgumentException("x must be nonnegative");
這多是程序員的意圖拋出建立的異常：
if (x < 0)
throw new IllegalArgumentException("x must be nonnegative");
86.RV: Method ignores return value (RV_RETURN_VALUE_IGNORED)
該方法的返回值應該進行檢查。這種警告一般出如今調用一個不可變對象的方法，認爲它更新了對象的值。例如：String dateString = getHeaderField(name);
dateString.trim();
程序員彷佛覺得trim（）方法將更新dateString引用的字符串。但因爲字符串是不可改變的，trim（）函數返回一個新字符串值，在這裏它是被忽略了。該代碼應更正：
String dateString = getHeaderField(name);
dateString = dateString.trim();
RpC_REPEATED_CONDITIONAL_TEST
該代碼包含對同一個條件試驗了兩次，兩邊徹底同樣例如：（如X == 0 | | x == 0）。可能第二次出現是打算判斷別的不一樣條件（如X == 0 | | y== 0）。
SA_FIELD_DOUBLE_ASSIGNMENT
方法中的字段包含了雙重任務，例如：
int x;
public void foo() {
x = x = 17;
}
這種爲變量賦值是無用的，並可能代表一個邏輯錯誤或拼寫錯誤。
SA_FIELD_SELF_ASSIGNMENT
方法中包含本身對本身賦值的字段。例如：
int x;
public void foo() {
x = x;
}
SA_FIELD_SELF_COMPARISON
字段本身進行自比較可能代表錯誤或邏輯錯誤。
SA_LOCAL_SELF_COMPARISON
方法中對一個局部變量自身進行比較運算，並可說明錯誤或邏輯錯誤。請確保您是比較正確的事情。
SA_LOCAL_SELF_COMPUTATION
此方法對同一變量執行了荒謬的計算（如x&x或x-x）操做。因爲計算的性質，這一行動彷佛沒有意義，並可能代表錯誤或邏輯錯誤。
SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH
在swtich中先前的case值由於swtich執行失敗而被覆寫，這就像是忘記使用break推出或者沒有使用return語句放回先前的值同樣。
SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW
在swtich中由於出現異常而忽略了對case值的保存。
SIC_THREADLOCAL_DEADLY_EMBRACE
若是是一個靜態內部類。實際上，在內部類和當前線程有死鎖的可能。因爲內部類不是靜態的，它保留了對外部類的引用。若是線程包含對一個內部類實例的引用，那麼內外實例的實例均可以被獲取，這樣就不具有垃圾會回收的資格。
SIO_SUPERFLUOUS_INSTANCEOF
在進行instanceof操做時進行沒有必要的類型檢查
STI_INTERRUPTED_ON_CURRENTTHREAD
此方法調用Thread.currentThread（）調用，只需調用interrupted（）方法。因爲interrupted（）是一個靜態方法， Thread.interrupted（）更簡單易用。
STI_INTERRUPTED_ON_UNKNOWNTHREAD
調用不是當前線程對象的Thread.interrupted()方法，因爲interrupted（）方法是靜態的，interrupted方法將會調用一個和做者原計劃不一樣的對象。
SE_METHOD_MUST_BE_PRIVATE
這個類實現了Serializable接口，並定義自定義序列化的方法/反序列化。但因爲這種方法不能聲明爲private，將被序列化/反序列化的API忽略掉。
SE_READ_RESOLVE_IS_STATIC
爲使readResolve方法獲得序列化機制的識別，不能做爲一個靜態方法來聲明。
UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS
在匿名類中定義了一個既沒有覆寫超類中方法也不能直接調用的方法。由於在其餘類的方法不能直接引用匿名類聲明的方法，彷佛這種方法不能被調用，這種方法可能只是沒有任何做用的代碼，但也可能覆寫超類中聲明。
UR_UNINIT_READ
此構造方法中使用了一個還沒有賦值的字段或屬性。 String a; public SA() {
String abc = a;
System.out.println(abc); }
UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR
方法被超類的構造函數調用時，在當前類中的字段或屬性尚未被初始化。例如：
abstract class A {
int hashCode;
abstract Object getValue();
A() {
hashCode = getValue().hashCode();
}
}
class B extends A {
Object value;
B(Object v) {
this.value = v;
}
Object getValue() {
return value;
}
}
當B是建立時，A的構造函數將在B爲value賦值以前觸發，然而在A的初始化方法調用getValue方法時value這個變量尚未被初始化。
DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY
該代碼調用上匿名數組的toString（）方法，產生的結果形如[@ 16f0472並無實際的意義。考慮使用Arrays.toString方法來轉換成可讀的字符串，提供該數組的內容數組。例如：
String[] a = { "a" };
System.out.println(a.toString());
//正確的使用爲
System.out.println(Arrays.toString(a));
DMI_INVOKING_TOSTRING_ON_ARRAY
該代碼調用上數組的toString（）方法，產生的結果形如[@ 16f0472並不能顯示數組的真實內容。考慮使用Arrays.toString方法來轉換成可讀的字符串，提供該數組的內容數組
UWF_NULL_FIELD
字段的值老是爲null值，全部讀取該字段的值都爲null。檢查錯誤，若是它確實沒有用就刪除掉。
107.UwF: Unwritten field (UWF_UNWRITTEN_FIELD)
此字段是永遠不會寫入值。全部讀取將返回默認值。檢查錯誤（若是它被初始化？），若是它確實沒有用就刪除掉。
五：Performance關於代碼性能相關方面的
BX_UNBOXING_IMMEDIATELY_REBOXED
裝箱的值被取消裝箱，而後當即從新裝箱
BX_BOXING_IMMEDIATELY_UNBOXED
對原始值進行裝箱，而後當即取消裝箱。這多是在一個未要求裝箱的地方進行了手動裝箱，從而迫使編譯器進行當即撤消裝箱的操做
BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION
對原始值進行裝箱而後當即把它強制轉換爲另一種原始類型。例如：
new Double(d).intValue()應該直接進行強制轉換例如：(int) d
DM_BOXED_PRIMITIVE_TOSTRING
僅僅爲了調用封裝類的toString()而對原始類型進行封裝操做。比這種方法更有效的是調用封裝類的toString(…)方法例如：
new Integer(1).toString() 替換爲 Integer.toString(1)
new Long(1).toString() 替換爲 Long.toString(1)
new Float(1.0).toString() 替換爲 Float.toString(1.0)
new Double(1.0).toString() 替換爲 Double.toString(1.0)
new Byte(1).toString() 替換爲 Byte.toString(1)
new Short(1).toString() 替換爲 Short.toString(1)
new Boolean(true).toString() 替換爲 Boolean.toString(true)
DM_FP_NUMBER_CTOR
使用new Double(double)方法老是會建立一個新的對象，然而使用Double.valueOf(double)方法能夠把值保存在編輯器或者class library、JVM中。使用存儲值的方式來避免對象的分配能夠或得更好的代碼性能
除非類必須符合Java 1.5之前的JVM，不然請使用自動裝箱或valueOf（）方法建立Double和Float實例。
DM_NUMBER_CTOR
使用new Integer(int)方法老是會建立一個新的對象，然而使用Integer.valueOf(int)方法能夠把值保存在編輯器或者class library、JVM中。使用存儲值的方式來避免對象的分配能夠或得更好的代碼性能
除非類必須符合Java 1.5之前的JVM，不然請使用自動裝箱或valueOf（）方法建立Long, Integer, Short, Character, Byte實例。
DMI_BLOCKING_METHODS_ON_URL
使用equals和hashCode方法來對url進行資源標識符解析時會引發堵塞。考慮使用java.net.URI來代替。
DMI_COLLECTION_OF_URLS
方法或者字段使用url的map/set集合。由於equals方法或者hashCode方法來進行資源標識符解析時都會引發堵塞。考慮使用java.net.URI來代替。
DM_BOOLEAN_CTOR
使用new方法建立一個java.lang.Boolean類型可以的實例對象是浪費空間的，由於Boolean對象是不可變的並且只有兩個有用的值。使用Boolean.valueOf()或者Java1.5中的自動裝箱功能來建立一個Boolean實例。
DM_GC
在代碼中顯式的調用垃圾回收命名，這樣作並不能起做用。在過去，有人在關閉操做或者finalize方法中調用垃圾回收方法致使了不少的性能浪費。這樣大規模回收對象時會形成處理器運行緩慢。
DM_NEXTINT_VIA_NEXTDOUBLE
若是r是一個java.util.Random對象，你可使r.nextInt(n)生成一個0到n-1以前的隨機數，而不是使用(int)(r.nextDouble() * n)
DM_STRING_CTOR
使用java.lang.String(String)構造函數會浪費內存由於這種構造方式和String做爲參數在功能上容易混亂。只是使用String直接做爲參數的形式
DM_STRING_TOSTRING
調用String.toString()是多餘的操做，只要使用String就能夠了。
DM_STRING_VOID_CTOR
使用沒有參數的構造方法去建立新的String對象是浪費內存空間的，由於這樣建立會和空字符串「」混淆。Java中保證完成相同的構造方法會產生描繪相同的String對象。因此你只要使用空字符串來建立就能夠了。
ITA_INEFFICIENT_TO_ARRAY
當使用集合的toArray()方法時使用數組長度爲0的數組做爲參數。比這更有效的一種方法是
myCollection.toArray(new Foo[myCollection.size()])，若是數組的長度足夠大就能夠直接把集合中的內容包裝到數組中直接返回從而避免了第二次建立一個新的數組來存放集合中值。
LO_APPENDED_STRING_IN_FORMAT_STRING
此方法使用SLF4J記錄器記錄一個字符串，其中第一個（格式）字符串是使用串聯建立的。您應該使用{}標記將動態內容注入到字符串中，以便延遲String的構建，直到須要實際的日誌字符串爲止。若是日誌級別足夠高，以至不使用此日誌語句，則將永遠不會執行附加操做。
NAB_NEEDLESS_BOXING_VALUEOF
此方法將String傳遞給包裝的原始對象的parse方法，該方法又調用valueOf（）方法以轉換爲裝箱的原始對象。當須要從String轉換爲裝箱的原始對象時，使用BoxedPrimitive.valueOf（String）方法更簡單。
而不是這樣的：
Boolean bo = Boolean.valueOf(Boolean.parseBoolean("true"));
Float f = Float.valueOf(Float.parseFloat("1.234"));
只需作：
Boolean bo = Boolean.valueOf("true");
Float f = Float.valueOf("1.234");
NAB_NEEDLESS_BOXING_PARSE
該方法將String傳遞給包裝的原始對象的valueOf方法，該方法進而調用boxedValue（）方法以轉換爲原始對象。當須要從String轉換爲原始值時，使用BoxedPrimitive.parseBoxedPrimitive（String）方法更簡單。
而不是這樣的：
public int someMethod(String data) {
long l = Long.valueOf(data).longValue();
float f = Float.valueOf(data).floatValue();
return Integer.valueOf(data); // There is an implicit .intValue() call
}
只需作：
public int someMethod(String data) {
long l = Long.parseLong(data);
float f = Float.parseFloat(data);
return Integer.parseInt(data);
}
NAB_NEEDLESS_BOOLEAN_CONSTANT_CONVERSION
此方法將一個裝箱的布爾常量分配給一個原始布爾變量，或將一個裝箱的布爾常量分配給一個裝箱的布爾變量。對須要的變量使用正確的常數
PRMC_POSSIBLY_REDUNDANT_METHOD_CALLS
此方法在相同實例上使用相同的常量參數連續兩次調用相同的方法，而無需對對象進行任何中間更改。若是此方法未對對象進行更改（看上去沒有更改），則進行兩次調用將很浪費。經過將結果分配給一個臨時變量，而後第二次使用該變量，能夠合併這些方法調用。
PSC_PRESIZE_COLLECTIONS
這個方法使用默認構造函數分配集合，即便它預先知道集合中將放置多少項(或者至少能夠合理地猜想)，從而沒必要要地致使集合的中間從新分配。
您可使用具備初始大小的構造函數，這樣會好得多，可是因爲映射和集合的加載因子，甚至這也不是一個正確的估計值。
若是您正在使用Guava，請使用它的方法來分配具備預先肯定大小的映射和集合，以得到不從新分配的最佳機會，例如:
Sets.newHashSetWithExpectedSize (int)
Maps.newHashMapWithExpectedSize (int)
若是沒有，一個很好的估計值應該是expectedSize / {LOADING_FACTOR}默認值爲0.75
SBSC_USE_STRINGBUFFER_CONCATENATION
在循環中構建一個String對象時從性能上講使用StringBuffer來代替String對象
例如：
// This is bad
String s = "";
for (int i = 0; i < field.length; ++i) {
s = s + field[i];
}
// This is better
StringBuffer buf = new StringBuffer();
for (int i = 0; i < field.length; ++i) {
buf.append(field[i]);
}
String s = buf.toString();
SEO_SUBOPTIMAL_EXPRESSION_ORDER
例如，此方法在if或while語句中構建條件表達式，該表達式既包含簡單的局部變量比較，又包含方法調用的比較。表達式對這些命令進行排序，以便在簡單的局部變量比較以前進行方法調用。這致使方法調用在不須要的條件下執行，所以有可能致使大量代碼無執行。經過對錶達式進行排序，以便首先包含局部變量條件的簡單條件，能夠消除這種浪費。假定方法調用沒有反作用。若是該方法確實有反作用，則最好將這些調用從條件中拉出並先執行，而後將值分配給局部變量。
例：
if ((calculateHaltingProbability() > 0) && shouldCalcHalting) { }
Better：
if (shouldCalcHalting && (calculateHaltingProbability() > 0) { }
SS_SHOULD_BE_STATIC
類中所包含的final屬性字段在編譯器中初始化爲靜態的值。考慮在定義時就把它定義爲static類型的。
SPP_STRINGBUFFER_WITH_EMPTY_STRING
這個方法調用StringBuffer或StringBuilder構造函數，傳入一個常量空字符串("")。這與調用默認構造函數相同，可是會使代碼更加困難。考慮傳入一個默認大小。
UCPM_USE_CHARACTER_PARAMETERIZED_METHOD
此方法將String長度爲1 的常量文字做爲參數傳遞給方法，該方法公開了一個相似的方法，該方法採用char。處理一個字符而不是一個字符串更簡單方便。
而不是像這樣：
String myString = ...
if (myString.indexOf("e") != -1) {
int i = myString.lastIndexOf("e");
System.out.println(myString + ":" + i); //the Java compiler will use a StringBuilder internally here [builder.append(":")]
...
return myString.replace("m","z");
}
將單字母Strings 替換爲它們的char等價物，以下所示：
String myString = ...
if (myString.indexOf('e') != -1) {
int i = myString.lastIndexOf('e');
System.out.println(myString + ':' + i); //the Java compiler will use a StringBuilder internally here [builder.append(':')]
...
return myString.replace('m','z');
}
UM_UNNECESSARY_MATH
在方法中使用了java.lang.Math的靜態方法代替常量來使用，使用常量速度和準確度會更好。 如下爲Math中的方法產生的值。
Method Parameter
abs -any-
acos 0.0 or 1.0
asin 0.0 or 1.0
atan 0.0 or 1.0
atan2 0.0 cbrt 0.0 or 1.0
ceil -any-
cos 0.0
cosh 0.0
exp 0.0 or 1.0
expm1 0.0
floor -any-
log 0.0 or 1.0
log10 0.0 or 1.0
rint -any-
round -any-
sin 0.0
sinh 0.0
sqrt 0.0 or 1.0
tan 0.0
tanh 0.0
toDegrees 0.0 or 1.0
toRadians 0.0
UPM_UNCALLED_PRIVATE_METHOD
定義爲Private類型方法從未被調用，應該被刪除。
URF_UNREAD_FIELD
類中定義的屬性從未被調用，建議刪除。
UUF_UNUSED_FIELD
類中定義的屬性從未被使用，建議刪除。
WMI_WRONG_MAP_ITERATOR
當方法中接受一個Map類型的參數時，使用keySet的迭代器比使用entrySet的迭代器效率要高。
六：Internationalization關於代碼國際化相關方面的
DM_CONVERT_CASE
使用平臺默認的編碼格式對字符串進行大小寫轉換，這可能致使國際字符的轉換不當。使用如下方式對字符進行轉換
String.toUpperCase( Locale l )
String.toLowerCase( Locale l )
七：Multithreaded correctness關於代碼多線程正確性相關方面的
DL_SYNCHRONIZATION_ON_BOOLEAN
該代碼同步一個封裝的原始常量，例如一個Boolean類型。
private static Boolean inited = Boolean.FALSE;
...
synchronized(inited) {
if (!inited) {
init();
inited = Boolean.TRUE;
}
}
...
因爲一般只存在兩個布爾對象，此代碼多是同步的其餘無關的代碼中相同的對象，這時會致使反應遲鈍和可能死鎖
DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE
該代碼同步一個封裝的原始常量，例如一個Integer類型。
private static Integer count = 0;
...
synchronized(count) {
count++;
}
...
因爲Integer對象能夠共享和保存，此代碼多是同步的其餘無關的代碼中相同的對象，這時會致使反應遲鈍和可能死鎖
DL_SYNCHRONIZATION_ON_SHARED_CONSTANT
同步String類型的常量時，因爲它被JVM中多個其餘的對象所共有，這樣在其餘代碼中會引發死鎖。
DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE
同步一個顯然不是共有封裝的原始值，例如一個Integer類型的對象。例如：
private static final Integer fileLock = new Integer(1);
...
synchronized(fileLock) {
.. do something ..
}
...
它最後被定義爲如下方式來代替：private static final Object fileLock = new Object();
DM_MONITOR_WAIT_ON_CONDITION
方法中以java.util.concurrent.locks.Condition對象調用wait（）。等待一個條件發生時應該使用在Condition接口中定義的await()方法。
DM_USELESS_THREAD
這個方法沒有經過run方法或者具體聲明Thread類，也沒有經過一個Runnable對象去定義一個線程，而這個線程出來浪費資源卻什麼也沒有去作。
ESync_EMPTY_SYNC
該代碼包含一個空的同步塊：synchronized() {}
IS2_INCONSISTENT_SYNC
不合理的同步
IS_FIELD_NOT_GUARDED
域不是良好的同步訪問---
此字段被標註爲net.jcip.annotations.GuardedBy，但能夠在某種程度上違反註釋而去訪問
JLM_JSR166_LOCK_MONITORENTER
實現java.util.concurrent.locks.Lock的對象調用了同步的方法。應該這樣處理，對象被鎖定/解鎖時使用acquire（）/ release（）方法而不是使用同步的方法。
LI_LAZY_INIT_STATIC
靜態域不正確的延遲初始化--
這種方法包含了一個不一樣步延遲初始化的非volatile靜態字段。由於編譯器或處理器可能會從新排列指令，若是該方法能夠被多個線程調用，線程不能保證看到一個徹底初始化的對象。你可讓字段可變來解決此問題
LI_LAZY_INIT_UPDATE_STATIC
這種方法包含一個不一樣步延遲初始化的靜態字段。以後爲字段賦值，對象存儲到該位置後進一步更新或訪問。字段後儘快讓其餘線程可以訪問。若是該方法的進一步訪問該字段爲初始化對象提供服務，而後你有一個很是嚴重的多線程bug，除非別的東西阻止任何其餘線程訪問存儲的對象，直到它徹底初始化。
即便你有信心，該方法是永遠不會被多個線程調用時，在它的值尚未被充分初始化或移動，不把它設定爲static字段時它可能會更好。
ML_SYNC_ON_UPDATED_FIELD
對象獲取一個可變字段時進行同步。這是沒有意義的，由於不一樣的線程能夠在不一樣的對象同步。
MSF_MUTABLE_SERVLET_FIELD
一個web服務通常只能建立一個servlet或者jsp的實例（例如：treates是一個單利類），它會被多個線程調用這個實例的方法服務於多個同時的請求。所以使用易變的字段屬性產生競爭的狀況。
MWN_MISMATCHED_NOTIFY
此方法調用Object.notify（）或Object.notifyAll（）而沒有獲取到該對象的對象鎖。調用notify（）或notifyAll（）而沒有持有該對象的對象鎖，將致使IllegalMonitorStateException異常。
MWN_MISMATCHED_WAIT
此方法調用Object.wait()而沒有獲取到該對象的對象鎖。調用wait（）而沒有持有該對象的對象鎖，將致使IllegalMonitorStateException異常。
NP_SYNC_AND_NULL_CHECK_FIELD
若是代碼塊是同步的，那麼久不可能爲空。若是是空，同步時就會拋出NullPointerException異常。最好是在另外一個代碼塊中進行同步。
NO_NOTIFY_NOT_NOTIFYALL
調用notify（）而不是notifyAll（）方法。 Java的監控器一般用於多個條件。調用notify（）只喚醒一個線程，這意味着該線程被喚醒只是知足的當前的惟一條件。
RS_READOBJECT_SYNC
序列化類中定義了同步的readObject（）。經過定義，反序列化建立的對象只有一個線程能夠訪問，所以沒有必要的readObject（）進行同步。若是的readObject（）方法自己形成對象對另外一個線程可見，那麼這自己就是很差的編碼方式。
RU_INVOKE_RUN
這種方法顯式調用一個對象的run（）。通常來講，類是實現Runnable接口的，由於在一個新的線程他們將有本身的run（）方法，在這種狀況下Thread.start（）方法調用是正確的。
SC_START_IN_CTOR
在構造函數中啓動一個線程。若是類曾經被子類擴展過，那麼這極可能是錯的，由於線程將在子類構造以前開始啓動。
SP_SPIN_ON_FIELD
方法無限循環讀取一個字段。編譯器可合法懸掛宣讀循環，變成一個無限循環的代碼。這個類應該改變，因此使用適當的同步（包括等待和通知要求）
STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE
即便JavaDoc對此不包含暗示，而Calendars自己在多線程中使用就是不安全的。探測器發現當調用Calendars的實例時將會得到一個靜態對象。
Calendar rightNow = Calendar.getInstance();
STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE
在官方的JavaDoc，DateFormats多線程使用本事就是不安全的。探測器發現調用一個DateFormat的實例將會得到一個靜態對象。
myString = DateFormat.getDateInstance().format(myDate);
STCAL_STATIC_CALENDAR_INSTANCE
Calendar在多線程中自己就是不安全的，若是在線程範圍中共享一個Calendarde 實例而不使用一個同步的方法在應用中就會出現一些奇怪的行爲。在sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate()中會拋出ArrayIndexOutOfBoundsExceptions or IndexOutOfBoundsExceptions異常。
STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE
DateFormat 在多線程中自己就是不安全的，若是在線程範圍中共享一個DateFormat的實例而不使用一個同步的方法在應用中就會出現一些奇怪的行爲。
SWL_SLEEP_WITH_LOCK_HELD
當持有對象時調用Thread.sleep（）。這可能會致使不好的性能和可擴展性，或陷入死鎖，由於其餘線程可能正在等待得到鎖。調用wait（）是一個更好的主意，釋放對象的持有以容許其餘線程運行。
UG_SYNC_SET_UNSYNC_GET
這個類包含相似命名的get和set方法。在set方法是同步方法和get方法是非同步方法。這可能會致使在運行時的不正確行爲，由於調用的get方法不必定返回對象一致狀態。 GET方法應該同步。
UL_UNRELEASED_LOCK
方法得到了當前的對象所，可是在方法中始終沒有釋放它。一個正確的示例以下：
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
UL_UNRELEASED_LOCK_EXCEPTION_PATH
方法得到了當前的對象所，可是在全部的異常處理中始終沒有釋放它。一個正確的示例以下：
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
UW_UNCOND_WAIT)
方法中包含調用java.lang.Object.wait（），而卻沒有放到條件流程控制中。該代碼應確認條件還沒有知足以前等待;先前任何通知將被忽略。
VO_VOLATILE_REFERENCE_TO_ARRAY
聲明一個變量引用數組，這可能不是你想要的。若是一個變量引用數組，那麼對引用數組的讀和寫都是不安全的，可是數組元素不是變量。取得數組的變量值你可使用java.util.concurrent包中的數組的原子性特性
WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL
實例的方法中同步this.getClass()，若是這個類有子類集合，那麼子類集合中的對象將會在這個類的各個子類上進行同步，這不是咱們想要的效果，咱們只要同步當前的類對象而不包含它的全部子類，能夠同步類名.getClass()。例如，java.awt.Label的代碼：
private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (getClass()) {
return base + nameCounter++;
}
}
Label中的子類集合不可能在同一個子對象上進行同步，替換上面的方法爲：
private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (Label.class) {
return base + nameCounter++;
}
}
WS_WRITEOBJECT_SYNC
這個類有一個writeObject（）方法是同步的，可是這個類中沒有其餘的同步方法。
WA_AWAIT_NOT_IN_LOOP
方法沒有在循環中調用java.util.concurrent.await()。若是對象是用於多種條件，打算調用wait()方法的條件可能不是實際發生的。
WA_NOT_IN_LOOP
這種方法包含調用java.lang.Object.wait（），而這並非一個循環。若是監視器用於多個條件，打算調用wait()方法的條件可能不是實際發生的。
八：Malicious codevulnerability關於惡意破壞代碼相關方面的
EI_EXPOSE_REP
返回一個易變對象引用並把它保存在對象字段中時會暴露對象內部的字段描述，若是接受不守信任的代碼訪問或者沒有檢查就去改變易變對象的會涉及對象的安全和其餘重要屬性的安全。返回一個對象的新副本，在不少狀況下更好的辦法。
EI_EXPOSE_REP2
此代碼把外部可變對象引用存儲到對象的內部表示。若是實例受到不信任的代碼的訪問和沒有檢查的變化危及對象和重要屬性的安全。存儲一個對象的副本，在不少狀況下是更好的辦法。
FI_PUBLIC_SHOULD_BE_PROTECTED
一個類中的finalize（）方法必須聲明爲protected，而不能爲public類型
MS_EXPOSE_REP
一個public類型的靜態方法返回一個數組，可能引用內部屬性的暴露。任何代碼調用此方法均可以自由修改底層數組。一個解決辦法是返回一個數組的副本。
MS_FINAL_PKGPROTECT
一個靜態字段可能被惡意代碼或另一個包所改變的。字段能夠放到protected包中也能夠定義爲final類型的以免此問題。
MS_MUTABLE_ARRAY
一個定義爲final類型的靜態字段引用一個數組時它能夠被惡意代碼或在另其餘包中所使用。這些代碼能夠自由修改數組的內容。
MS_MUTABLE_HASHTABLE
一個定義爲final類型的靜態字段引用一個Hashtable時能夠被惡意代碼或者在其餘包中被調用，這些方法能夠修改Hashtable的值。
MS_OOI_PKGPROTECT
將域儘可能不要定義在接口中，並聲明爲包保護
在接口中定義了一個final類型的靜態字段，如數組或哈希表等易變對象。這些對象能夠被惡意代碼或者在其餘包中被調用，爲了解決這個問題，須要把它定義到一個具體的實體類中而且聲明爲保護類型以免這種錯誤。
MS_PKGPROTECT
一個靜態字段是能夠改變的惡意代碼或其餘的包訪問修改。能夠把這種類型的字段聲明爲final類型的以防止這種錯誤。
九：Dodgy、style糟糕的代碼
BC_BAD_CAST_TO_ABSTRACT_COLLECTION
在代碼投把一個集合強制類型轉換爲一個抽象的集合（如list，set或map）。保證該對象類型和將要轉換的類型是一致的。若是你只是想要便利一個集合，那麼你就沒必要將它轉換爲Set或List。
BC_BAD_CAST_TO_CONCRETE_COLLECTION
代碼把抽象的集合（如List，Set，或Collection）強制轉換爲具體落實類型（如一個ArrayList或HashSet）。這可能不正確，也可能使您的代碼很脆弱，由於它使得難以在從此的切換指向其餘具體實現。除非你有特別理由這樣作，不然只須要使用抽象的集合類。
BC_UNCONFIRMED_CAST
強制類型轉換操做沒有通過驗證，並且不是全部的此種類型裝換過的類均可以再強制類型轉換爲原類型。在代碼中須要進行邏輯判斷以保證能夠進行這樣的操做。
BC_VACUOUS_INSTANCEOF
instanceof測試將始終返回真（除非被測試的值爲空）。雖然這是安全，確保它是否是說明一些誤解或其餘一些邏輯錯誤。若是你真的想測試是空的價值，也許會更清楚這樣作的更好空試驗，而不是一個instanceof測試。
CC_CYCLOMATIC_COMPLEXITY
該方法具備較高的圈複雜度，能夠計算出分支點的個數。它極可能難以測試，而且很容易更改。考慮將此方法重構爲多個方法以下降風險。
CFS_CONFUSING_FUNCTION_SEMANTICS
此方法將修改參數，而後將此參數做爲方法的返回值返回。這將使這個方法的調用者感到困惑，由於傳入參數的「原始」顯然也不會更改。若是此方法的目的是更改參數，則將該方法更改成具備空返回值的a會更清楚。若是因爲接口或超類契約須要返回類型，則可能應該複製該參數。
CI_CONFUSED_INHERITANCE
這個類被聲明爲final的，而是字段屬性卻聲明爲保護類型的。因爲是final類，它不能再被繼承，而再聲明爲保護類型的很容易形成混淆。爲了從外部能正確的使用它應該把它們聲明爲private或者public類型。
DB_DUPLICATE_BRANCHES
此方法使用相同的代碼，以實現兩個有條件的分支。檢查以確保這是否是一個編碼錯誤。
DB_DUPLICATE_SWITCH_CLAUSES
他的方法使用相同的代碼來實現兩個switch的聲明條款。這多是重複代碼的狀況，但可能也顯示出編碼的錯誤。
DLS_DEAD_LOCAL_STORE
該指令爲局部變量賦值，但在其後的沒有對她作任何使用。一般，這代表一個錯誤，由於值從未使用過。
DLS_DEAD_LOCAL_STORE_IN_RETURN
本聲明把一個局部變量放到方法的返回語句中。這對於方法中局部變量來講是沒有意思的。
DLS_DEAD_LOCAL_STORE_OF_NULL
把一個本地變量賦值爲null值，而且再也沒有對這個變量作任何的操做。這樣多是爲了垃圾回收，而是Java SE 6.0，這已再也不須要。
DMI_HARDCODED_ABSOLUTE_FILENAME
此代碼包含文件對象爲一個絕對路徑名（例如，新的文件（「/ home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment」）;
DMI_NONSERIALIZABLE_OBJECT_WRITTEN
代碼中讓一個非序列化的對象出如今ObjectOutput.writeObject()方法中，這樣會引發一個錯誤。
DMI_USELESS_SUBSTRING
此代碼調用了subString(0)方法，它將返回原來的值。
EXS_EXCEPTION_SOFTENING_HAS_CHECKED
此方法的異常簽名受超類接口的約束，不拋出已捕獲的已檢查異常。所以，此異常被轉換爲未檢查異常並引起。最好拋出最近的已檢查異常，並使用初始緣由字段用原始異常註釋新異常。
EQ_DOESNT_OVERRIDE_EQUALS
該類擴展了定義equals方法的類並添加字段，但自己不定義equals方法。所以，該類實例上的等式將忽略子類的標識和添加的字段。確保這是您想要的，而且您不須要覆蓋equals方法。即便不須要重寫equals方法，也能夠考慮重寫它，以記錄這樣一個事實:子類的equals方法只返回調用super.equals(o)的結果。
FE_FLOATING_POINT_EQUALITY
此操做比較兩個浮點值是否相等。因爲浮點運算可能會涉及到舍入，計算float和double值可能不許確。若是要求值必須準確，如貨幣值，能夠考慮使用固定精度類型，如BigDecimal類型的值來比較
VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN
使用%b去格式化Boolean類型的值不正確的可是它不會拋出異常，任何非空的值都會輸出true，任何爲空的值都會輸出false
IC_INIT_CIRCULARITY
在引用兩個相互調用爲環狀static方法去初始化一個實例時是錯誤的。
ICAST_IDIV_CAST_TO_DOUBLE
整形數除法強制轉換爲double或者float類型。
int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 = x / y;
// Right: yields result 0.4
double value2 = x / (double) y;
ICAST_INTEGER_MULTIPLY_CAST_TO_LONG
整形數作乘法運算結果轉換爲long值時若是採用
long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; } 結果會由於超出整形的範圍而出錯。
若是使用：
long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
或者：
static final long MILLISECONDS_PER_DAY = 24L*3600*1000; long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
均可以免此問題。
ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT
無符號數右移後進行轉換爲short或者byte類型時可能會丟棄掉高位的值，這樣的結果就是有符合數和無符號數沒法區分（這取決於移位大小）
IM_AVERAGE_COMPUTATION_COULD_OVERFLOW
代碼中使用x % 2 == 1的方法去驗證運算是否存在餘數的狀況，可是若是出現負數的狀況就不起做用了。使用x & 1 == 1, or x % 2 != 0來代替
IMC_IMMATURE_CLASS_PRINTSTACKTRACE
此方法將堆棧跟蹤打印到控制檯。這是不可配置的，並致使應用程序看起來不專業。切換到使用日誌記錄器，以便用戶可以控制日誌記錄的內容和位置。
INT_VACUOUS_COMPARISON
整形數進行比較結果老是不變。例如：x <= Integer.MAX_VALUE
MOM_MISLEADING_OVERLOAD_MODEL
該類用實例和靜態版本「重載」相同的方法。因爲這兩種模型的使用是不一樣的，這將使這些方法的用戶感到困惑。
MTIA_SUSPECT_SERVLET_INSTANCE_FIELD
這個類擴展從Servlet類，並使用實例的成員變量。因爲只有一個Servlet類的實例，並在多線程方式使用，這種模式有可能存在問題。考慮只使用方法的局部變量。
MTIA_SUSPECT_STRUTS_INSTANCE_FIELD
類擴展自Struts的Action類並使用這個實例的成員變量，由於在Struts框架中只存在一個Action實例對象而且使用在多線程的狀況下極可能會出現問題。
NP_DEREFERENCE_OF_READLINE_VALUE
對readLine()的結果值沒有進行判空操做就去從新賦值，這樣的操做能夠會拋出空指針異常。
NP_IMMEDIATE_DEREFERENCE_OF_READLINE
對readLine()的結果當即賦值，這樣的操做能夠會拋出空指針異常。
NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE
方法的返回值沒有進行是否爲空的檢查就從新賦值，這樣可能會出現空指針異常。
NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE
參數值在任何狀況下都不能爲空，可是有明確的註釋它能夠爲空。
NS_DANGEROUS_NON_SHORT_CIRCUIT
代碼中使用（& or |）代替（&& or ||）操做，這會形成潛在的危險。
NS_NON_SHORT_CIRCUIT
代碼中使用（& or |）代替（&& or ||）操做，會引發不安全的操做
PZLA_PREFER_ZERO_LENGTH_ARRAYS
考慮返回一個零長度的數組，而不是null值
QF_QUESTIONABLE_FOR_LOOP
肯定這個循環是正確的變量遞增，看起來，另外一個變量被初始化，檢查的循環。這是因爲for循環中太複雜的定義形成的。
RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE
方法中包含一個不能爲空的賦值還包含一個能夠爲空的賦值。冗餘比較非空值爲空。
RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES
方法中對兩個null值進行比較
RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
方法中對不爲空的值進行爲空的判斷。
REC_CATCH_EXCEPTION
在try/catch塊中捕獲異常，可是異常沒有在try語句中拋出而RuntimeException又沒有明確的被捕獲
RI_REDUNDANT_INTERFACES
子類和父類都實現了同一個接口，這種定義是多餘的。
RV_DONT_JUST_NULL_CHECK_READLINE
readLine方法的結果不爲空時被拋棄
RV_REM_OF_RANDOM_INT
此代碼生成一個隨機的符號整數，而後計算另外一個值的。因爲隨機數能夠是負數，因此其他操做的結果也能夠是負面的。考慮使用Random.nextInt（int）方法代替。
RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT
這段代碼調用一個方法並忽略返回值。然而，咱們的分析代表，該方法(若是有的話，包括它在子類中的實現)除了返回值以外不會產生任何效果。所以能夠刪除這個調用。
多是錯誤警告：-該方法旨在被覆蓋，並在其餘超出分析範圍的項目中產生反作用。
-調用該方法來觸發類加載，這可能會產生反作用。
-調用該方法只是爲了得到一些異常。
可使用@CheckReturnValue註釋來指示FindBugs忽略該方法的返回值
SA_LOCAL_DOUBLE_ASSIGNMENT
爲一個局部變量兩次賦值，這樣是沒有意義的。例如：
public void foo() {
int x,y;
x = x = 17;
}
SA_LOCAL_SELF_ASSIGNMENT
局部變量使用自身給本身賦值
public void foo() {
int x = 3;
x = x;
}
SF_SWITCH_FALLTHROUGH
Switch語句中一個分支執行後又執行了下一個分支。一般case後面要跟break 或者return語句來跳出。
SF_SWITCH_NO_DEFAULT
Switch沒有默認狀況下執行的case語句。
SE_PRIVATE_READ_RESOLVE_NOT_INHERITED
聲明爲private的序列化方法被子類繼承
UCF_USELESS_CONTROL_FLOW
沒有任何做用的條件語句。
if (argv.length == 0) { // TODO: handle this case }
UCF_USELESS_CONTROL_FLOW_NEXT_LINE
無效的條件控制語句，注意if (argv.length == 1);以「;」結尾，下面的語句不管是否知足都會運行。
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
UP_UNUSED_PARAMETER
此方法定義了從未使用過的參數。因爲此方法是靜態的或私有的，且不能派生，所以刪除這些參數並簡化方法是安全的。雖然不太可能，但您應該考慮能夠反射性地使用此方法，所以您也但願更改該調用。在這種狀況下，極可能一旦刪除了參數，就會有一系列方法調用花費時間建立該參數並將其傳遞下去。全部這些均可能被移除。
UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR
字段歷來沒有在任何構造函數初始化，對象被建立後值爲空。若是該字段未被定義就從新賦值會產生一個空指針異常。
USBR_UNNECESSARY_STORE_BEFORE_RETURN
該方法將返回結果存儲在局部變量中，而後當即返回局部變量。直接返回分配給局部變量的值會更簡單。
Instead of the following:
public float average(int[] arr) {
float sum = 0;
for (int i = 0; i < arr.length; i++) {
sum += arr[i];
}
float ave = sum / arr.length;
return ave;
}
Simply change the method to return the result of the division:
public float average(int[] arr) {
float sum = 0;
for (int i = 0; i < arr.length; i++) {
sum += arr[i];
}
return sum / arr.length; //Change
}
XFB_XML_FACTORY_BYPASS
方法自定義了一種XML接口的實現類。最好是使用官方提供的工廠類來建立這些對象，以即可以在運行期中改變。例如：
javax.xml.parsers.DocumentBuilderFactory
javax.xml.parsers.SAXParserFactory
javax.xml.transform.TransformerFactory
org.w3c.dom.Document.createXXXX
XSS_REQUEST_PARAMETER_TO_SEND_ERROR
在代碼中在Servlet輸出中直接寫入一個HTTP參數，這會形成一個跨站點的腳本漏洞。
XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER
代碼直接寫入參數的HTTP服務器錯誤頁（使用HttpServletResponse.sendError）。表達了相似的不受信任的輸入會引發跨站點腳本漏洞。