一、Security 關於代碼安全性防護
DMI_CONSTANT_DB_PASSWORD
代碼中創建DB的密碼時采用了寫死的密碼。
DMI_EMPTY_DB_PASSWORD
創建數據庫連接時沒有為數據庫設置密碼，這會使數據庫沒有必要的保護。
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注入攻擊。
XSS_REQUEST_PARAMETER_TO_JSP_WRITER
在代碼中在JSP輸出中直接寫入一個HTTP參數，這會造成一個跨站點的腳本漏洞。
二、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錯誤模式相同，但是是在不同在靜態分析技術。我們正為這個錯誤模式的效用收集反饋意見。
三、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(...)來獲取資源
四、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）。表達了類似的不受信任的輸入會引起跨站點腳本漏洞。