• 贵州快3官网

贵州快3官网

作者︰  發布日(ri)期︰2020-02-19 09:26:54
Tag標簽︰錯誤(wu)  

  • 1. EC_UNRELATED_TYPES
    Bug: Call to equals() comparing different types Pattern id: EC_UNRELATED_TYPES, type: EC, category: CORRECTNESS
    解釋︰
    兩個不(bu)同類型的對象調用(yong)equals方法,如果equals方法沒有(you)被(bei)重寫,那麼調用(yong)object的==,永遠不(bu)會(hui)相等(deng);如果equals方法被(bei)重寫,而且含(han)有(you)instanceof邏輯,那麼還是不(bu)會(hui)相等(deng)。
    解決方法︰
    應(ying)該(gai)改為(wei)str.toString()
    2. IM_BAD_CHECK_FOR_ODD
    Bug: Check for oddness that won't work for negative numbers Pattern id: IM_BAD_CHECK_FOR_ODD, type: IM, category: STYLE
    解釋︰
    如果row是負奇數,那麼row % 2 == -1,
    解決方法︰
    考慮使用(yong)x & 1 == 1或者x % 2 != 0
    3. NP_ALWAYS_NULL
    Pattern: Null pointer dereference id: NP_ALWAYS_NULL, type: NP, category: CORRECTNESS
    A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.
    4. RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
    Bug: Redundant nullcheck of bean1, which is known to be non-null Pattern id: RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE, type: RCN, category: STYLE
    This method contains a redundant check of a known non-null value against the constant null.
    這種方法包含(han)了一個稱為(wei)非空對空值(zhi)的不(bu)斷重復檢查。
    修改為(wei)︰
    5. SS_SHOULD_BE_STATIC
    Bug: Unread field: ADDRESS_KEY; should this field be static? Pattern id: SS_SHOULD_BE_STATIC, type: SS, category: PERFORMANCE
    This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.
    解釋︰
    final成員變量表示常(chang)量,只能被(bei)賦chi)zhi)一次wei) 持(chi)zhi)後(hou)值(zhi)不(bu)再(zai)改變。
    這個類包含(han)的一個final變量初始化為(wei)編(bian)譯時靜態值(zhi)。考慮變成靜態常(chang)量
    解決方法︰
    增加(jia)static關鍵(jian)字
    6. EQ_COMPARETO_USE_OBJECT_EQUALS
    Bug: RsInterface defines compareTo(Object) and uses Object.equals() Pattern id: EQ_COMPARETO_USE_OBJECT_EQUALS, type: Eq, category: BAD_PRACTICE
    解釋︰
    第一段代碼,沒有(you)使用(yong)instanceof判斷就直接轉型,有(you)拋出classcastexception異常(chang)的可能。
    這個BUG主題是,遵守約ji)x.compareTo(y)==0) == (x.equals(y)),強烈(lie)建議(yi),但不(bu)嚴格要求。
    在return 0的時候,調用(yong)equals方法返回true,因(yin)為(wei)在PriorityQueue.remove方法中,1.5使用(yong)的是compareTo方法,而1.6使用(yong)的是equals方法,保證(zheng)環境升級(ji)的時候,受影(ying)響最小。
    解決方法︰
    在return 0的時候,調用(yong)equals方法返回true
    7. NM_METHOD_NAMING_CONVENTION
    Bug: The method name MsmPlanDAOTest.TestViewMsmPlanList() doesn't start with a lower case letter Pattern id: NM_METHOD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
    Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
    解釋︰
    方法應(ying)該(gai)是動詞,與第一個字母小寫混合xi)那榭魷攏 朊扛齙dan)詞的首字母大寫的na)誆俊br />解決方法︰
    方法名(ming)稱小寫就通(tong)過(guo)了。
    8. HE_EQUALS_USE_HASHCODE
    Bug: PerfmSingleGraphPanel$RSCategory defines equals and uses Object.hashCode() Pattern id: HE_EQUALS_USE_HASHCODE, type: HE, category: BAD_PRACTICE
    解釋︰
    重載(zai)了equals方法,卻沒有(you)重載(zai)hashCode方法,如果使用(yong)object自己(ji)的hashCode,我們可以從JDK源代碼可以看到object的hashCode方法是native的,它(ta)的值(zhi)由shang)檳食fen)配(某chi)智榭魷麓 嗽諦檳食械牡di)址或者唯一標識),每個對象都不(bu)一樣。所以這很(hen)可能違反“Equals相等(deng),hashcode一定(ding)相等(deng);hashcode相等(deng),equals不(bu)一定(ding)相等(deng)。”除(chu)非你保證(zheng)不(bu)運用(yong)到HashMap/HashTable等(deng)運用(yong)散(san)列表查找值(zhi)的數據結構中。否則,發生任何事(shi)情都是有(you)可能的。
    關于(yu)何時改寫hashcode,請(qing)參考︰在重寫了對象的equals方法後(hou),還需(xu)要重寫hashCode方法嗎?
    關于(yu)編(bian)寫高(gao)質量的equals方法︰
    1.先使用(yong)==操作符檢查是否是同一個對象,==都相等(deng),那麼邏輯相等(deng)肯定(ding)成立;
    2.然後(hou)使用(yong)instanceof操作符檢查“參數是否為(wei)正確的類型”;
    3.把(ba)參數轉換成正確的類型;
    4.對于(yu)該(gai)類中的非基(ji)本類型變量,遞歸調用(yong)equals方法;
    5.變量的比較順序可能會(hui)影(ying)響到equals方法的性能,應(ying)該(gai)最先比較最有(you)可能不(bu)一致的變量,或者是開(kai)銷(xiao)最低的變量。
    當你編(bian)寫完(wan)成equals方法之後(hou),應(ying)該(gai)問自己(ji)三個問題︰它(ta)是否是對稱的、傳遞的、一致的?
    解決方法︰
    除(chu)非你保證(zheng)不(bu)運用(yong)到HashMap/HashTable等(deng)運用(yong)散(san)列表查找值(zhi)的數據結構中,請(qing)重寫hashcode方法。
    9. NM_CONFUSING
    Bug: Confusing to have methods xxx.SellerBrandServiceImpl.getAllGrantSellerBrandsByBrandId(long) and xxx.DefaultSellerBrandManager.getALLGrantSellerBrandsByBrandId(long) Pattern id: NM_CONFUSING, type: Nm, category: BAD_PRACTICE
    The referenced methods have names that differ only by capitalization.
    解釋︰
    同一個包兩個類中有(you)一模一樣的兩個方法(包括參數)
    解決方法︰
    最好可以修改為(wei)不(bu)一樣的方法名(ming)稱
    10. MF_CLASS_MASKS_FIELD
    Bug: Field PDHSubCardInstanceDialogCommand.m_instance masks field in superclass ViewNEProperity Pattern id: MF_CLASS_MASKS_FIELD, type: MF, category: CORRECTNESS
    This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
    解釋︰
    這是什(shi)麼意(yi)思呢?想要字段也能夠具有(you)多(duo)態性yue)穡刻 曰huo)了。
    當你想要更新一個m_instance時,你要更新哪(na)個?你用(yong)到它(ta)時,你知道哪(na)個又被(bei)更新了?
    解決方法︰
    要麼去掉其中一個字段wei)  粗匭旅ming)。
    11. NM_CLASS_NAMING_CONVENTION
    Bug: The class name crossConnectIndexCollecter doesn't start with an upper case letter
    解釋︰ Pattern id: NM_CLASS_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
    看到這樣的命名(ming)方式,我第一個反映就是有(you)點(dian)暈車!
    解決方法︰
    類名(ming)第一個字符請(qing)大寫。
    12. RE_POSSIBLE_UNINTENDED_PATTERN
    Bug: "." used for regular expression Pattern id: RE_POSSIBLE_UNINTENDED_PATTERN, type: RE, category: CORRECTNESS
    解釋︰
    String的split方法傳遞的參數是正則表達式,正則表達式本身用(yong)到的字符需(xu)要轉義,如︰句點(dian)符號“.”,美元符號“$”,乘方符號“^”,大括號“{}”,方括號“[]”,圓(yuan)括號“()” ,豎線(xian)“”,星(xing)號“*”,加(jia)號“+”,問號“?”等(deng)等(deng),這些需(xu)要在前面加(jia)上“\”轉義符。
    解決方法︰
    在前面加(jia)上“\”轉義符。
    13.IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD
    外部類︰
    內部類︰
    ……
    Bug: Ambiguous invocation of either an outer or inherited method JExtendDialog.onOK() Pattern id: IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD, type: IA, category: STYLE
    解釋︰
    TargetSetupDialog是JExtendDialog的子類,JExtendDialog有(you)一個onOK方法,但是JExtendDialog的外部類也有(you)一個onOK方法,到底這個onOK方法調用(yong)的是它(ta)父類onOK方法還是調用(yong)它(ta)外部類onOK方法呢,這不(bu)免讓人(ren)誤(wu)解。
    當然這並沒有(you)編(bian)譯錯誤(wu),實dao)噬嫌you)先調用(yong)的是父類JExtendDialog的onOK方法,如果把(ba)JExtendDialog的onOK方法去掉,它(ta)調用(yong)的就是外部類onOK方法,這個時候不(bu)能寫成this.onOK,因(yin)為(wei)此時的this並不(bu)代表外部類對象。
    解決方法︰
    如果要引用(yong)外部類對象,可以加(jia)上“outclass.this”。
    如果要引用(yong)父類的onOK方法,請(qing)使用(yong)super.onOK()。
    14. DM_FP_NUMBER_CTOR
    Bug: Method OnlineLicenseDAOTest.testUpdateOnlineLicenseByOnlineMerchantId() invokes inefficient Double.valueOf(double) constructor; use OnlineLicenseDAOTest.java:[line 81] instead Pattern id: DM_FP_NUMBER_CTOR, type: Bx, category: PERFORMANCE
    Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.
    Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or the valueOf() method when creating instances of Double and Float.
    解釋︰
    采用(yong)new Ddouble(double)會(hui)產生一個新的對象,采用(yong)Ddouble.valueOf(double)在編(bian)譯的時候可能通(tong)過(guo)緩存經常(chang)請(qing)求的值(zhi)來顯著提高(gao)空間(jian)和(he)時間(jian)性能。
    解決方法︰
    采用(yong)Ddouble.valueOf方法
    類似(si)的案例
    15. CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE
    Bug:AlarmSoundManager$SoundProperty defines clone() but doesn't implement Cloneable Pattern id: CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE, type: CN, category: BAD_PRACTICE
    解釋︰
    SoundProperty類實現了clone方法,但是沒有(you)實現Cloneable接口,當然這沒有(you)任何問題,但是你應(ying)該(gai)知道你為(wei)什(shi)麼這麼做。
    解決方法︰
    最好實現Cloneable接口
    16. STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE
    Bug: Call to method of static java.text.DateFormat Pattern id: STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE, type: STCAL, category: MT_CORRECTNESS
    解釋︰
    TIME_FORMAT是一個DateFormat靜態變量,文(wen)檔中DateFormat不(bu)是線(xian)程安全(多(duo)個線(xian)程訪問一個類時,這些線(xian)程執行順序沒有(you)統(tong)一的調度和(he)約ji)  綣飧隼嗟男形wei)仍(reng)然是正確的,那麼這個類就是線(xian)程安全的。考慮vector的實現)的,如果多(duo)個線(xian)程同時訪問,會(hui)出現zhong)yi)料不(bu)到的情況,詳情參見(jian)Sun Bug #6231579和(he)Sun Bug #6178997。
    因(yin)此對于(yu)DateFormat、SimpleDateFormat、Calendar類對象不(bu)建議(yi)定(ding)義成靜態成員字段使用(yong),同時對它(ta)們在多(duo)線(xian)程環境下的使用(yong)請(qing)一定(ding)要保證(zheng)同步。
    另外,多(duo)說一句,java為(wei)我們提供了很(hen)多(duo)的封裝手段wei) 熱rivate關鍵(jian)字、內部類、全限定(ding)包名(ming)等(deng)等(deng),我們要充分(fen)利(li)用(yong)這些手段封裝信息,對外盡量提供最小集。關于(yu)靜態變量也是如此,就算是vector這種線(xian)程安全的類,在無狀(zhuang)態類中也可能存在並發的問題,參見(jian)︰無狀(zhuang)態類在並發環境chi)芯jue)對安全嗎?
    解決方法︰
    修改類字段為(wei)對象字段wei) 緩hou)改為(wei)private,同時提供get方法,最後(hou)對get方法實現同步機制。
    最好連對象字段也去掉,直接在方法里使用(yong),就不(bu)存在同步的問題了(不(bu)必考慮性能問題,而且DateFormat本身就不(bu)必作為(wei)對象的字段wei) 蟻胝庖彩un為(wei)什(shi)麼不(bu)hua)閹ta)實現為(wei)線(xian)程安全的了)。
    17. SE_NO_SERIALVERSIONID
    Bug: WindowHandlerManager$MySingleSelectionModel is Serializable; consider declaring a serialVersionUID Pattern id: SE_NO_SERIALVERSIONID, type: SnVI, category: BAD_PRACTICE
    This class implements the Serializable interface, but does not define a serialVersionUID field. A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID.
    解釋︰
    實現了Serializable接口,卻沒有(you)實現定(ding)義serialVersionUID字段wei) 蛄謝 氖焙潁 頤塹畝韻蠖急4嫖wei)硬(ying)盤上xi)囊桓鑫wen)件,當通(tong)過(guo)網絡傳輸或者其他類加(jia)載(zai)方式還原為(wei)一個對象時,serialVersionUID字段會(hui)保證(zheng)這個對象的兼容性,考慮兩種情況︰
    1. 新軟件讀取(qu)老文(wen)件,如果新軟件有(you)新的數據定(ding)義,那麼它(ta)們必然會(hui)丟失(shi)。
    2. 老軟件讀取(qu)新文(wen)件,只要數據是向(xiang)下兼容的,就沒有(you)任何問題。
    序列化會(hui)把(ba)所有(you)與你要序列化對象相關的引用(yong)(包括父類,特別是內部類持(chi)有(you)對外部類的引用(yong),這里的例子就符合這種情況)都輸出到一個文(wen)件中,這也是為(wei)什(shi)麼能夠使用(yong)序列化能進行深拷貝。這種序列化算法給我們的忠(zhong)告是,不(bu)要把(ba)一些你無法確fan)ㄆ浠ji)本數據類型的對象引用(yong)作為(wei)你序列化的字段wei) 熱Frame),否則序列化後(hou)的文(wen)件超大,而且會(hui)出現zhong)yi)想不(bu)到的異常(chang)。
    解決方法︰
    定(ding)義serialVersionUID字段
    18.SE_COMPARATOR_SHOULD_BE_SERIALIZABLE
    Bug: ToStringComparator implements Comparator but not Serializable Pattern id: SE_COMPARATOR_SHOULD_BE_SERIALIZABLE, type: Se, category: BAD_PRACTICE
    解釋︰
    ToStringComparator類實現了Comparator接口卻沒有(you)實現Serializable接口,因(yin)為(wei)像TreeMap這種可shang)蛄謝 萁 梗ㄋta)實現了Serializable接口)只有(you)當比較器繼承了Serializable接口時,它(ta)才能被(bei)序列化。
    解決方法︰
    實現Serializable接口並定(ding)義serialVersionUID字段
    19. ES_COMPARING_STRINGS_WITH_EQ
    Bug: Comparison of String objects using == or != Pattern id: ES_COMPARING_STRINGS_WITH_EQ, type: ES, category: BAD_PRACTICE
    解釋︰
    你確fan) 鬩yi)經了解string的全部了?
    如果你不(bu)了解,請(qing)參考FX大神的博文(wen)︰請(qing)別再(zai)拿“String s = new String("xyz");創建了多(duo)少個String實例”來面試了吧
    那麼,接下來我就開(kai)始剝皮(pi)了︰ Object和(he)StringBuilder的toString方法都是返回一個new String(),跟””不(bu)相等(deng)。
    如果你之前是這樣的定(ding)義的︰String name = “”;OK,它(ta)們處于(yu)同一個class常(chang)量池,跟””相等(deng)。
    如果在這之前,你使用(yong)了String. Intern方法,你是高(gao)手,跟””相等(deng)。
    如果你沒有(you)意(yi)識到這些問題,卻仍(reng)然使用(yong)==和(he)!=去比較字符串,那麼請(qing)不(bu)要告訴我是你手滑(hua)了= =!
    解決方法︰
    老實使用(yong)equals方法吧,至少為(wei)了保持(chi)代碼的清晰性。
    20. ES_COMPARING_STRINGS_WITH_EQ
    Bug: Comparison of String parameter using == or != Pattern id: ES_COMPARING_PARAMETER_STRING_WITH_EQ, type: ES, category: BAD_PRACTICE
    解釋︰
    跟前面的例子ying)畈bu)多(duo),你如果不(bu)能確保propertyName來源于(yu)常(chang)量池,那麼用(yong)==比較沒有(you)一點(dian)意(yi)義,難不(bu)成你告訴我這能提高(gao)性能? 如果有(you)功(gong)夫為(wei)這點(dian)性能擔驚(jing)受怕,還不(bu)如花(hua)點(dian)時間(jian)去找找性能瓶頸。
    解決方法︰
    使用(yong)equals方法
    21. IM_AVERAGE_COMPUTATION_COULD_OVERFLOW
    Bug: Computation of average could overflow Pattern id: IM_AVERAGE_COMPUTATION_COULD_OVERFLOW, type: IM, category: STYLE
    解釋︰
    參照了Findbugs的解釋,(low+high)/2當平均數過(guo)大的時候(難道是超過(guo)了int最大值(zhi)?)會(hui)溢出,會(hui)出現zhong)桓齦褐zhi),此問題出現在早期實現zhi)畝撲閹suo)和(he)歸並排序,但是已(yi)經被(bei)修復了。參見(jian)Joshua Bloch(google首席java架(jia)構師(shi))widely publicized the bug pattern(需(xu)FQ).
    解決方法︰
    建議(yi)使用(yong)無符號右移(yi)位運算符︰use (low+high) >>> 1
    22. SC_START_IN_CTOR
    Bug: new AsyncCentral() invokes AsyncCentral$FireThread.start() Pattern id: SC_START_IN_CTOR, type: SC, category: MT_CORRECTNESS
    解釋︰
    構造方法里重啟新的線(xian)程,我還是第一次見(jian)過(guo)這樣寫的。
    首先ren)得魅dian)︰
    1. 對象的創建一hua)惴fen)兩步走,在堆(dui)上new對象操作,執行<init>方法(包含(han)構造方法),為(wei)什(shi)麼我們開(kai)發人(ren)員看見(jian)的只有(you)一步,那是因(yin)為(wei)JVM不(bu)想讓開(kai)發人(ren)員在這個過(guo)程中插(cha)上一腳(jiao),破壞對象的初始化流程。
    2. 類的加(jia)載(zai)和(he)tong)跏薊 怯尚(shang)檳食Vzheng)同步的,但是對象的生成和(he)tong)跏薊 兔揮you)任何同步機制來保證(zheng)了。
    3. 構造器不(bu)能加(jia)synchronized,是一項(xiang)程序語(yu)言設(she)計上xi)難≡見(jian):JLS 8.8.3 Constructor Modifiers),正常(chang)情況下,是不(bu)需(xu)要加(jia)上synchronized,但不(bu)代表所有(you)的情況都不(bu)要加(jia)上synchronized,更不(bu)能認為(wei)一個構造器隱含(han)的就是一個synchronized。
    那什(shi)麼時候構造方法需(xu)要同步呢?通(tong)常(chang)來說,<init>方法在生成sha)韻蟺氖焙蛑槐bei)執行一次wei) 話(hua)ew對象的操作可能因(yin)為(wei)JVM自身的關系(xi)保證(zheng)原子you)圓(yuan)僮鰨ㄗ約ji)臆測的,沒有(you)任何根據),所以我們經常(chang)不(bu)用(yong)關心構造方法同步的問題。但是上述(shu)情況就不(bu)一樣了,在構造方法中新啟線(xian)程,如果AsyncCentral是一個狀(zhuang)態類,FireThread線(xian)程極有(you)可能對AsyncCentral的狀(zhuang)態進行反復讀取(qu)和(he)寫入,更嚴重的一種情況是,AsyncCentral有(you)父類,極有(you)可能在父類的構造方法還沒開(kai)始前,FireThread線(xian)程就已(yi)經開(kai)始執行並對AsyncCentral的狀(zhuang)態進行“破壞”了。這個時候,就有(you)兩個線(xian)程來對AsyncCentral的狀(zhuang)態進行操作了(一個是執行<init>方法的線(xian)程,一個是FireThread線(xian)程),自然而然,就會(hui)存在同步的問題了。
    多(duo)數時候,我們沒有(you)發現,可能是AsyncCentral類沒有(you)狀(zhuang)態,或者是時候未到,我想說的是,我們寫的大部分(fen)程序都ji)嬖諭 降奈侍猓 糾泳褪瞧渲幸桓觶 zhi)得我們好好思考。
    另一種理解(覺得更靠譜,來自于(yu)Java.Concurrency.in.Practice)叫做“對象逃逸”,意(yi)思就是說在構造方法里,this是可以訪問的到的,同一時間(jian),FireThread線(xian)程而是可以訪問到this對象的,所以這時候this就從<init>方法線(xian)程逃逸到了FireThread線(xian)程中,這時候初始化就會(hui)存在並發問題。
    解決方法︰
    不(bu)要再(zai)構造方法中新啟線(xian)程,可以提供init方法,其他方法根據實dao)是榭齠ding)。
    23. EQ_SELF_USE_OBJECT
    Bug: ManageItem defines equals(ManageItem) method and uses Object.equals(Object) Pattern id: EQ_SELF_USE_OBJECT, type: Eq, category: CORRECTNESS
    解釋︰
    這是重載(zai),不(bu)是覆蓋(gai),除(chu)非你能保證(zheng)其他人(ren)調用(yong)這個方法傳入的參數都是ManageItem 的,否則會(hui)調用(yong)Object的boolean equals(Object)方法,這樣的mu)案揪筒bu)會(hui)跑到這個方法里來!!很(hen)多(duo)所謂的大牛都會(hui)犯這麼一個錯誤(wu),我堅信這是你手滑(hua)了。
    解決方法︰
    如果你想覆蓋(gai)父類的方法,請(qing)在上面加(jia)上@Override注解,它(ta)會(hui)防(fang)止(zhi)這種錯誤(wu)的出現(透露一個小細節,JDK1.5覆蓋(gai)接口方法時加(jia)上@Override編(bian)譯器會(hui)報錯,JDK1.6修正,這可能是當初實現者對@Override注解理解的問題)。

    24.DLS_DEAD_LOCAL_STORE

    未使用(yong)的變量。

    Bug: Dead store to date Pattern id: DLS_DEAD_LOCAL_STORE, type: DLS, category: STYLE
    解釋︰
    先看看,我們的程序有(you)多(duo)少個這樣的例子︰
    真是傷不(bu)起啊,不(bu)知道lai)筆鋇淖髡噠饈巧?硪yi)圖?手滑(hua)?還是眼花(hua)?雖然說這不(bu)是神馬問題,也不(bu)會(hui)對程序性能造成sha)啻蟺撓ying)響,但是這就像一顆(ke)沙子,我們每個程序員對待程序都jia)ying)該(gai)是眼里不(bu)能進沙子的態度,當然,你非要這麼寫,我也沒神馬可說的。
    By the way︰
    對本地(di)變量定(ding)義了之後(hou)未使用(yong)到,編(bian)譯器能夠做優(you)化處理,也就是在編(bian)譯之後(hou)的class文(wen)件中刪除(chu)這些本地(di)變量。方法是在eclipse的Preferences里將以下的鉤去除(chu)︰
    解決方法︰
    大膽的去掉或者注釋掉。
    誤(wu)報的案例︰
    上述(shu)案例二種︰ IntegralItemDO integralItem = new IntegralItemDO();
    是一個局部的變量,不(bu)需(xu)要定(ding)義到外部去,定(ding)義在外部,可能會(hui)變成一個無效的變量。
    25.FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER
    Bug: Doomed test for equality to NaN Pattern id: FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER, type: FE, category: CORRECTNESS
    解釋︰
    我也開(kai)眼界了,照搬Findbugs的理解︰
    大概意(yi)思就是說Nan很(hen)特殊(shu)(表示未定(ding)義和(he)不(bu)可表示的值(zhi)),沒有(you)任何值(zhi)跟它(ta)相等(deng),包括它(ta)自身,所以x == Double.NaN永遠返回false。
    解決方法︰
    如果要檢查x是特殊(shu)的,不(bu)是一個數值(zhi),請(qing)用(yong)Double.isNaN(x)方法。
    26. FI_EMPTY
    Bug: FilterIPConfigDialog.finalize() is empty and should be deleted Pattern id: FI_EMPTY, type: FI, category: BAD_PRACTICE
    解釋︰
    空的finalize方法,有(you)什(shi)麼用(yong)?
    根據JDK文(wen)檔, finalize() 是一個用(yong)于(yu)釋放(fang)非 Java 資源的方法。但是, JVM 有(you)很(hen)大的可能不(bu)調用(yong)對象的finalize() 方法,因(yin)此很(hen)難證(zheng)明使用(yong)該(gai)方法釋放(fang)資源是有(you)效的。
    解決方法︰
    刪除(chu)掉finalize方法
    27.REC_CATCH_EXCEPTION
    Bug: Exception is caught when Exception is not thrown Pattern id: REC_CATCH_EXCEPTION, type: REC, category: STYLE
    解釋︰
    我覺得有(you)點(dian)迷惑(huo),有(you)些catch (Exception e)並沒有(you)被(bei)Findbugs捕捉到,開(kai)始以為(wei)它(ta)的意(yi)思是try catch里沒有(you)任何異常(chang)的產生,包括RuntimeException,但是後(hou)來我寫了例子證(zheng)明並不(bu)是這麼回事(shi)。
    總之,它(ta)的意(yi)思jia)ying)該(gai)是說JVM對RuntimeException有(you)統(tong)一的捕獲機制(一hua)愣際譴蠐∫斐chang)棧信息,然後(hou)向(xiang)外拋,沒有(you)遇(yu)到Exception線(xian)程就死lai)簦DT線(xian)程除(chu)外),你搞(gao)一個catch (Exception e)這樣也把(ba)RuntimeException就捕獲了。但是如果你的處理機制中沒有(you)針對這些異常(chang),那就可能有(you)問題了。通(tong)常(chang)來說,很(hen)多(duo)應(ying)用(yong)程序都把(ba)異常(chang)記錄在日(ri)志(zhi)之中,但是我覺得也應(ying)該(gai)同時打印在調試屏幕(mu)中,這樣有(you)利(li)于(yu)開(kai)發人(ren)員調試。
    比如上面的程序,假如發生了空指針異常(chang),你只有(you)去日(ri)志(zhi)中才能看到,這對我們調試人(ren)員來說很(hen)不(bu)方便的。
    解決方法︰
    其實這樣寫也沒有(you)問題(除(chu)非你有(you)意(yi)),有(you)時候我們確實需(xu)要捕獲RuntimeException,比如我們有(you)一個批處理,這個任務很(hen)重要,必須保證(zheng)某個任務出了問題不(bu)能影(ying)響其他的任務,這個時候就可以在for循環內捕獲RuntimeException,出現了異常(chang)還可以continue。
    不(bu)過(guo)上面的例子最好再(zai)把(ba)異常(chang)信息打印到調試屏幕(mu)上。
    28. DM_GC
    Bug: DBExportTask2.exportDBRecords(DBExportProperty, String) forces garbage collection; extremely dubious except in benchmarking code Pattern id: DM_GC, type: Dm, category: PERFORMANCE
    解釋︰
    有(you)兩點(dian)︰
    1. System.gc()只是建議(yi),不(bu)是命令,JVM不(bu)能保證(zheng)立刻執行垃圾回收(shou)。
    2. System.gc()被(bei)顯示調用(yong)時,很(hen)大可能會(hui)觸發Full GC。
    GC有(you)兩種類型︰Scavenge GC和(he)Full GC,Scavenge GC一hua)閌欽?閱昵崠den區)進行GC,不(bu)會(hui)影(ying)響老年代和(he)永生代(PerGen),由于(yu)大部分(fen)對象都是從Eden區開(kai)始的,所以Scavenge GC會(hui)頻繁進行,GC算法速度也更快,效率更高(gao)。但是Full GC不(bu)同,Full GC是對整個堆(dui)進行整理,包括Young、Tenured和(he)Perm,所以比Scavenge GC要慢,因(yin)此應(ying)該(gai)盡可能減少Full GC的次數。
    解決方法︰
    去掉System.gc()
    28. DP_DO_INSIDE_DO_PRIVILEGED
    Bug: com.taobao.sellerservice.core.test.BaseTestJunit.autoSetBean() invokes reflect.Field.setAccessible(boolean), which should be invoked from within a doPrivileged block Pattern id: DP_DO_INSIDE_DO_PRIVILEGED, type: DP, category: BAD_PRACTICE
    This code invokes a method that requires a security permission check. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the invocation needs to occur inside a doPrivileged block.
    此代碼調用(yong)一個方法,需(xu)要一個安全權限檢查。如果此代碼將被(bei)授予安全權限,但可能是由代碼不(bu)具有(you)安全權限調用(yong),則需(xu)要調用(yong)發生在一個doPrivileged的塊。
    30. MS_SHOULD_BE_FINAL
    Bug: IPv4Document.m_strInitString isn't final but should be Pattern id: MS_SHOULD_BE_FINAL, type: MS, category: MALICIOUS_CODE
    解釋︰
    使用(yong)public和(he)protected,別的包可以輕易修改它(ta),如果你不(bu)想它(ta)被(bei)修改,請(qing)使用(yong)final。
    封裝很(hen)重要,不(bu)管是從you) hu)方面和(he)技術方面來說,都ji)苤匾  也bu)明白為(wei)神馬有(you)那麼多(duo)的人(ren)把(ba)變量都寫成public的(就算要給別人(ren)共享,也要提供get方法),特別是在並發環境chi)校 乇 乇  yi)類變量的共享,而且特別特別特別注意(yi)共享的這個變量是否是線(xian)程安全的。
    解決方法︰
    加(jia)上final
    31. NM_FIELD_NAMING_CONVENTION
    Bug: The field name TopoControlPaneII.SyncSelection doesn't start with a lower case letter Pattern id: NM_FIELD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
    解釋︰
    為(wei)神馬字段是大寫開(kai)頭的?喂神馬?喂神馬啊?
    解決方法︰
    建議(yi)按照sun規定(ding)的命名(ming)方式
    Bug: Field only ever set to null: RaisecomStatus.infoURL Pattern id: UWF_NULL_FIELD, type: UwF, category: CORRECTNESS
    解釋︰
    字段infoURL整個過(guo)程中一直為(wei)null,但卻被(bei)用(yong)來作為(wei)分(fen)支判斷xi)奶跫 bu)知道作者何意(yi)?難道真的是傳說中的手滑(hua)?
    解決方法︰
    這個就要問作者的意(yi)圖了,當時你究竟要干神馬來著?
    32. MS_PKGPROTECT
    Bug: ActionPatternManager.m_This should be package protected Pattern id: MS_PKGPROTECT, type: MS, category: MALICIOUS_CODE
    解釋︰
    Findbugs說,靜態字段m_oThis應(ying)該(gai)是包權限的,如果是protected的mu)埃 梢員bei)其他包訪問到,其實個人(ren)覺得僅(jin)僅(jin)是封裝範(fan)圍的mu)笆且桓ldquo;小問題”,畢竟很(hen)多(duo)人(ren)都沒意(yi)識到public、protected等(deng)關鍵(jian)字zhi)鬧匾 浴5 俏醫幼磐驢矗br />單(dan)例模式??這是神馬單(dan)例模式?字段不(bu)是private,還是單(dan)例模式嗎?我在任何一個地(di)方繼承UserManager,然後(hou)直接m_oThis = new UserManager();這還是一個單(dan)例嗎?
    在看看Findbugs為(wei)我們找ye)雋碩duo)少個︰
    另外,我很(hen)客觀的說一點(dian),我們後(hou)怕,因(yin)為(wei)知道了真相,在想想我們實dao)是榭鮒杏yu)到很(hen)多(duo)不(bu)能復現zhi)奈侍猓 頤怯you)理由去知道這一切。
    解決方法︰
    修改protected為(wei)private,然後(hou)將單(dan)例模式實現方式改為(wei)惡漢,或者雙重校驗鎖定(ding)。
    33. FI_USELESS
    Pattern: Finalizer does nothing but call superclass finalizer id: FI_USELESS, type: FI, category: BAD_PRACTICE
    解釋︰
    finalize() 是一個用(yong)于(yu)釋放(fang)非 Java 資源的方法,這里的finalize直接用(yong)Object的finalize方法,無任何意(yi)義。
    解決方法︰
    勇敢去掉finalize()
    34. NP_NULL_ON_SOME_PATH
    Bug: Possible null pointer dereference of busCatId Pattern id: NP_NULL_ON_SOME_PATH, type: NP, category: CORRECTNESS
    There is a branch of statement that, if executed, guarantees that a null value will be dereferenced, which would generate a NullPointerException when the code is executed. Of course, the problem might be that the branch or statement is infeasible and that the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs.
    解釋︰
    方法中存在空指針
    解決方法︰
    增加(jia)字段busCatId為(wei)空的判斷
    35. NP_NULL_ON_SOME_PATH
    Bug:.HierarchicalManagerImpl.isExistByName(String, long) forgets to throw new exception.HierarchicalServiceException(String, Throwable) Pattern id: RV_EXCEPTION_NOT_THROWN, type: RV, category: CORRECTNESS
    This code creates an exception (or error) object, but doesn't do anything with it. For example, something like
    if (x < 0)
    new IllegalArgumentException("x must be nonnegative");
    It was probably the intent of the programmer to throw the created exception:
    if (x < 0)
    throw new IllegalArgumentException("x must be nonnegative");
    解釋︰
    此代碼創建了一個異常(chang)(或錯誤(wu))的對象,但並不(bu)做任何事(shi)情。
    可能作者是想繼續拋出異常(chang)信息吧,可是卻產生了一個對象,啥(sha)也不(bu)干。
    解決方法︰
    拋出這個錯誤(wu)
    36. FI_FINALIZER_NULLS_FIELDS
    Bug: CustomerResTreeDialog.java:[line 67] is set to null inside finalize method Pattern id: FI_FINALIZER_NULLS_FIELDS, type: FI, category: BAD_PRACTICE
    解釋︰
    關于(yu)finalize方法,前面應(ying)該(gai)已(yi)經介紹(shao)過(guo)了,所以m_UniResTree = null,純粹是多(duo)此一舉,沒有(you)任何意(yi)義。
    解決方法︰
    勇敢去掉finalize()
    37. FI_PUBLIC_SHOULD_BE_PROTECTED
    Bug: FilterIPConfigDialog.finalize() is public; should be protected Pattern id: FI_PUBLIC_SHOULD_BE_PROTECTED, type: FI, category: MALICIOUS_CODE
    解釋︰
    Finalize方法不(bu)是protected的,當然你寫成public也沒錯,依(yi)然可以yuan)哺gai)父類中的finalize方法。
    解決方法︰
    勇敢去掉finalize()
    38. IS2_INCONSISTENT_SYNC
    Bug: Inconsistent synchronization of URLAlarmMonitor.m_Counter; locked 50% of time Pattern id: IS2_INCONSISTENT_SYNC, type: IS, category: MT_CORRECTNESS
    解釋︰
    m_Counter只鎖住(zhu)了50%,它(ta)還是處于(yu)線(xian)程不(bu)hua)踩 淖zhuang)態,如果一個字段只被(bei)read,那麼它(ta)是線(xian)程安全的,不(bu)需(xu)要提供額外的同步開(kai)銷(xiao),可以定(ding)義為(wei)final的(參考不(bu)可變類的實現),如果既有(you)read也有(you)write,那麼就必須保證(zheng)每個get和(he)set方法都同步,而不(bu)能像上面一樣,只對set方法進行了同步。
    解決方法︰
    對get和(he)set方法都實行同步。
    39. LI_LAZY_INIT_UPDATE_STATIC
    Bug: Incorrect lazy initialization and update of static field MonitorRuleManager.m_This Pattern id: LI_LAZY_INIT_UPDATE_STATIC, type: LI, category: MT_CORRECTNESS
    解釋︰
    此問題的m_This也是protected的,這里就不(bu)再(zai)追究了。這里的問題是,當線(xian)程1執行到initMonitorRules方法時,線(xian)程2執行getInstance方法,它(ta)直接返回m_This,這時候它(ta)可以用(yong)m_This做任何事(shi)情,但是此時線(xian)程1的初始化動作還沒有(you)完(wan)成,如果initMonitorRules方法里有(you)對對象狀(zhuang)態進行更新的操作,那麼很(hen)可能線(xian)程2得到的對象的狀(zhuang)態是還沒有(you)初始化的,這就是一個多(duo)線(xian)程的BUG(多(duo)線(xian)程的問題之所以很(hen)嚴重,是因(yin)為(wei)我們很(hen)難復現解決它(ta),但它(ta)又是的確存在的,它(ta)總是在關鍵(jian)時候爆發,讓你感到很(hen)郁悶(men))!
    當然就算沒有(you)initMonitorRules方法,這個單(dan)例模式也不(bu)是線(xian)程安全的,下面會(hui)講到這個問
    題。
    解決方法︰
    將initMonitorRules方法放(fang)在構造方法里,然後(hou)將單(dan)例改成sha)窈耗J劍 蛘呤褂yong)雙重校驗鎖。
    40. LI_LAZY_INIT_STATIC
    Bug: Incorrect lazy initialization of static field TopoController.m_This Pattern id: LI_LAZY_INIT_STATIC, type: LI, category: MT_CORRECTNESS
    解釋︰
    為(wei)什(shi)麼它(ta)存在多(duo)線(xian)程的bug,比如線(xian)程1進入到if語(yu)句內,被(bei)線(xian)程2打斷,線(xian)程2同樣進入了if語(yu)句內然後(hou)生成了一個對象a,隨即(ji)被(bei)線(xian)程1打斷,線(xian)程1又生成了另外一個對象b,這還是一個單(dan)例麼?
    更詳細的解釋請(qing)看︰雙重檢查鎖定(ding)以及單(dan)例模式
    另外,關于(yu)單(dan)例模式更多(duo)的資料,參見(jian)單(dan)例模式的七種寫法
    如果你並發功(gong)底相當好,請(qing)看這篇文(wen)章(zhang)︰用(yong)happen-before規則重新審視(shi)DCL
    解決方法︰
    我比較鐘情于(yu)惡漢,如果需(xu)要傳遞參數,我會(hui)使用(yong)雙重校驗鎖。
    41. WMI_WRONG_MAP_ITERATOR
    案例一︰
    案例二︰
    Bug: Method JTAMainFrame.initView(JFrame) makes inefficient use of keySet iterator instead of entrySet iterator Pattern id: WMI_WRONG_MAP_ITERATOR, type: WMI, category: PERFORMANCE
    This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.
    解釋︰
    很(hen)多(duo)人(ren)都這樣遍(bian)歷Map,沒錯,但是效率很(hen)低,先一個一個的把(ba)key遍(bian)歷,然後(hou)在根據key去查找value,這不(bu)是多(duo)此一舉麼,為(wei)什(shi)麼不(bu)遍(bian)歷entry(桶)然後(hou)直接從entry得到value呢?它(ta)們的執行效率大概為(wei)1.5:1(有(you)人(ren)實dao)什(shi)饈怨guo))。
    我們看看HashMap.get方法的源代碼︰ 1. public V get(Object key) { 2. if (key == null) 3. return getForNullKey(); 4. int hash = hash(key.hashCode()); 5. for (Entry<K,V> e = table[indexFor(hash, table.length)]; 6. e != null; 7. e = e.next) { 8. Object k; 9. if (e.hash == hash && ((k = e.key) == key key.equals(k))) 10. return e.value; 11. } 12. return null; 13. }
    從這里可以看出查找value的原理,先計算出hashcode,然後(hou)散(san)列表里取(qu)出entry,不(bu)管是計算hashcode,還是執行循環for以及執行equals方法,都是CPU密集運算,非常(chang)耗費CPU資源,如果對一個比較大的map進行遍(bian)歷,會(hui)出現CPU迅速 高(gao)的現象,直接影(ying)響機器的響應(ying)速度,在並發的情況下,簡直就是一場災難。
    解決方法︰ 1. for (Map.Entry<String, JMenu> entry : menuList.entrySet()) { 2. mb.add(entry.getValue());
    }
    for(Map.Entry<String, List<BlackListDO>> tempEntiy: companyBlackItemsMap.entrySet()) {
    String key = tempEntiy.getKey();
    List<BlackListDO> eachCompanyBlackItems = tempEntiy.getValue();
    42. BC_VACUOUS_INSTANCEOF
    Bug: instanceof will always return true, since all TopoTreeNode are instances of TopoTreeNode Pattern id: BC_VACUOUS_INSTANCEOF, type: BC, category: STYLE
    解釋︰
    因(yin)為(wei)getSelectedTreeNode方法返回類型就是TopoTreeNode,所以if里的instanceof測試永遠為(wei)true,除(chu)非它(ta)是null,確保你沒有(you)其他的邏輯上xi)奈wu)解,你這樣寫,會(hui)讓men)淥ren)丈sha)he)尚(shang)摸不(bu)著頭腦。
    解決方法︰
    去掉instanceof檢測。
    43. INT_BAD_REM_BY_1
    Bug: Integer remainder modulo 1 computed Pattern id: INT_BAD_REM_BY_1, type: INT, category: STYLE
    解釋︰
    I % 1永遠都為(wei)0,I / 1也為(wei)i,不(bu)知道作者想干嘛。
    解決方法︰
    恕我愚昧,不(bu)明白作者的意(yi)圖。
    Bug: Load of known null value Pattern id: NP_LOAD_OF_KNOWN_NULL_VALUE, type: NP, category: STYLE
    The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was nonnull).
    解釋︰
    Node為(wei)null,還進一步調用(yong)它(ta)上面的方法,除(chu)非你能保證(zheng)當node為(wei)null的時候isDeleteSingleObject為(wei)false,否則很(hen)可能發生空指針異常(chang),我估(gu)計作者是第二個if是想判斷node != null吧。
    解決方法︰
    努力找到原作者,當面詢(xun)問其用(yong)意(yi)。
    44. EI_EXPOSE_REP2
    案例
    DO類
    Bug: SingleNePollConfigDialog.collectValues(Hashtable) may expose internal representation by storing an externally mutable object into SingleNePollConfigDialog.values Pattern id: EI_EXPOSE_REP2, type: EI2, category: MALICIOUS_CODE
    解釋︰
    參數values保存在當前線(xian)程的執行棧中,而this.values保存在堆(dui)上,它(ta)們同時指向(xiang)同一個對象,對yuan)問alues的任何操作都會(hui)影(ying)響到this.values,如果你知道這一點(dian),而且本意(yi)就是這樣的,那麼你可以忽(hu)略上面這些話(hua),但是下面這些話(hua)你應(ying)該(gai)好好听听。
    這是一段正確的代碼,但不(bu)是一段可維護(hu)性強、可理解性強的代碼,參數代表操作的條件,它(ta)們應(ying)該(gai)是只讀的,我們不(bu)應(ying)該(gai)對它(ta)直接進行操作或者賦chi)zhi)。
    解決方法︰
    如果把(ba)上面對yuan)問alues的操作都改成this.values,我相信你和(he)你的同事(shi)都會(hui)覺得這樣的代碼更加(jia)清晰。
    }
    案例二
    DO類
    Bug: SingleNePollConfigDialog.collectValues(Hashtable) may expose internal representation by storing an externally mutable object into SingleNePollConfigDialog.values Pattern id: EI_EXPOSE_REP2, type: EI2, category: MALICIOUS_CODE
    This code stores a reference to an externally mutable object into the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.
    翻譯願(yuan)意(yi)︰
    此代碼存儲到一個到對象的na)誆勘硎就獠靠殺潿韻蟺囊yong)。如果實例是由不(bu)受信任的代碼,並以可變對象會(hui)危(wei)及安全或其他重要的屬性選中更改訪問,你需(xu)要做不(bu)同的東西。存儲一個對象的副(fu)本,在許(xu)多(duo)情況下是更好的辦(ban)法。
    解釋︰
    DO類實例產生之後(hou),里面包含(han)的Date不(bu)是原始數據類型,導(dao)致其gmtCrate屬性yuan)還guang)是set方法可以yuan)謀淦渲zhi),外部引用(yong)修改之後(hou)也可能導(dao)致gmtCreate 被(bei)改變,會(hui)引起可能的不(bu)hua)踩 蛘嘰砦wu)。
    這個是一個不(bu)好的實dao) bu)過(guo)我們應(ying)用(yong)里面DO都是比較簡單(dan)使用(yong),不(bu)太會(hui)出現這種情況。
    解決方法︰
    修改成︰
    public Date getGmtCreate() { return new Date(this.gmtCreate.getTime()); //正確fen)zhi)
    }
    45. EI_EXPOSE_REP
    Bug: temsLoader.getItemsWithPriority() may expose internal representation by returning ItemsLoader.m_htItemsWithPriority Pattern id: EI_EXPOSE_REP, type: EI, category: MALICIOUS_CODE
    解釋︰
    剛開(kai)始一看挺納悶(men)的,這個方法有(you)什(shi)麼問題嗎?後(hou)來仔細看一下,發現返回值(zhi)都jia)you)一個特點(dian),它(ta)們都是集合數組之類的,我想findBugs的本意(yi)是,某些數據集合不(bu)應(ying)該(gai)直接對外提供public返回方法,即(ji)使表面上提供了get方法,但實dao)噬峽梢勻我yi)修改里面的數據。
    解決方法︰
    如果你確fan)ㄕ廡┤菁 喜bu)應(ying)該(gai)被(bei)外界修改,那麼對于(yu)基(ji)本數據類型,你提供get方法即(ji)可,對于(yu)引用(yong),get方法里的返回值(zhi)應(ying)該(gai)是數據的拷貝。
    46. NP_NULL_PARAM_DEREF
    Bug: Method call passes null for nonnull parameter of queryScriptData(ObjService) Pattern id: NP_NULL_PARAM_DEREF, type: NP, category: CORRECTNESS
    解釋︰
    當getAllListFiles方法發生了任何異常(chang)(checked和(he)unchecked),allFiles都為(wei)null,關鍵(jian)是在queryScriptData方法里,並沒有(you)對yuan)問欠裎wei)null進行判斷,它(ta)直接調用(yong)了參數對象上面的方法,這肯定(ding)會(hui)發生空指針異常(chang)。
    一個優(you)秀的程序員,在過(guo)馬路(lu)時都要向(xiang)兩邊看一下,在寫一個方法時,首先要考慮的就是對方法參數的有(you)效性判斷。
    解決方法︰

    在queryScriptData方法里對yuan)問杏you)效性判斷。

    46. SBSC_USE_STRINGBUFFER_CONCATENATION
    Bug: Method InitDBPoolParaTask.execute() concatenates strings using + in a loop Pattern id: SBSC_USE_STRINGBUFFER_CONCATENATION, type: SBSC, category: PERFORMANCE
    The method seems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.
    Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly.
    解釋︰
    每次循環fang) 淖址連接,都會(hui)新產生一個string對象,在java中,新建一個對象的代價是很(hen)昂貴的,特別是在循環語(yu)句中,效率較xi)汀br />解決方法︰
    利(li)用(yong)StringBuffer或者StringBuilder重用(yong)對象。
    47. RV_RETURN_VALUE_IGNORED_BAD_PRACTICE
    Bug: NewScriptAction.actionPerformed(ActionEvent) ignores exceptional return value of java.io.File.delete() Pattern id: RV_RETURN_VALUE_IGNORED_BAD_PRACTICE, type: RV, category: BAD_PRACTICE
    解釋︰
    關于(yu)一個方法邏輯執行是否成功(gong),有(you)兩種方式,一種是拋出異常(chang),一種是提供boolean類型的返回值(zhi)。舉一個例子,用(yong)戶登(deng)錄,某些人(ren)將login方法的返回值(zhi)定(ding)義為(wei)int,然後(hou)枚舉出各個值(zhi)的含(han)義,比如0代表成功(gong),1代表用(yong)戶名(ming)不(bu)存在等(deng)等(deng);而有(you)些人(ren),把(ba)這些枚舉值(zhi)看成是use case中的異常(chang)流,將它(ta)們定(ding)義為(wei)異常(chang)對象,遇(yu)到“異常(chang)”情況直接you)壯 斐chang)從而實現分(fen)支的流程。第一種方式是典型的C語(yu)言面向(xiang)過(guo)程風格,第二種方式,帶(dai)有(you)強烈(lie)的面向(xiang)對象味道,特別是java提供了checked Exception,貌似(si)偏離主題了。
    java中很(hen)多(duo)方法的執行成功(gong)依(yi)賴(lai)于(yu)異常(chang)的分(fen)支實現,但也有(you)提供返回值(zhi)的實現,比如這里的File.delete方法,上面的寫法忽(hu)略了返回值(zhi)(如果調用(yong)某個方法卻不(bu)使用(yong)其返回值(zhi)要特別注意(yi)),刪除(chu)一個文(wen)件很(hen)可能不(bu)成功(gong),但是從代碼里並沒有(you)看到這一層(ceng)面的意(yi)思。
    解決方法︰
    文(wen)件刪除(chu)不(bu)成功(gong)該(gai)怎麼辦(ban)?現在能處理就處理,現在不(bu)能處理就把(ba)父類的方法也改成有(you)返回值(zhi)的,然後(hou)向(xiang)上傳遞,這跟處理異常(chang)的道理是一樣的,當然,你也可以把(ba)它(ta)封裝成一個異常(chang)對象。
    48. RV_RETURN_VALUE_IGNORED
    Bug: BackupFileListPanel$PopupListener.maybeShowPopup(MouseEvent) ignores return value of String.trim() Pattern id: RV_RETURN_VALUE_IGNORED, type: RV, category: CORRECTNESS
    解釋︰
    String是一個不(bu)可變類,調用(yong)String上xi)娜魏尾僮鞫薊hui)返回新的String對象,雖然String是一個class,但實dao)噬隙運ta)的任何操作都可以把(ba)它(ta)看成基(ji)本數據類型,比如s.trim方法是不(bu)會(hui)改變s值(zhi)的。
    解決方法︰
    S = s.trim
    49. DM_BOOLEAN_CTOR
    Bug: TopoCardManagerAction.processLocalCard(Hashtable) invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead Pattern id: DM_BOOLEAN_CTOR, type: Dm, category: PERFORMANCE
    解釋︰
    不(bu)必創建一個新的Boolean對象,使用(yong)Boolean.valueOf方法可以重用(yong)Boolean.FALSE和(he)Boolean.TRUE對象。
    我們可以從API中可以看到public Boolean(boolean value)方法的解釋︰注︰一hua)闈榭魷露疾bu)宜(yi)使用(yong)該(gai)構造方法。若不(bu)需(xu)要新 的實例,則靜態工廠 valueOf(boolean) 通(tong)常(chang)是一個更好的選擇。這有(you)可能顯著提高(gao)空間(jian)和(he)時間(jian)性能。
    解決方法︰
    使用(yong)Boolean.valueOf方法或者直接返回Boolean.FALSE和(he)Boolean.TRUE對象。
    50. RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE
    Pattern id: RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE,
    解釋︰

    StringBuffer連接更有(you)?柯剩 yin)此,建議(yi)使用(yong)StringBuffer

    51. DM_NUMBER_CTOR
    new Integer(int) 和(he) Integer.valueOf(int)
    bug描(miao)述(shu)︰
    [Bx] Method invokes inefficient Number constructor; use static valueOf instead [DM_NUMBER_CTOR]
    Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.
    說明:
    [參考]http://www.cnblogs.com/hyddd/articles/1391318.html
    FindBugs推薦使用(yong)Integer.ValueOf(int)代替new Integer(int),因(yin)為(wei)這樣可以提高(gao)性能。如果當你的int值(zhi)介于(yu)-128~127時,Integer.ValueOf(int)的效率比Integer(int)快大約3.5倍。
    下面看看JDK的源碼,看看到Integer.ValueOf(int)里面做了什(shi)麼優(you)化︰
    public static Integer valueOf(int i) { final int offset = 128; if (i >= -128 && i <= 127) { // must cache return IntegerCache.cache[i + offset]; } return new Integer(i); } private static class IntegerCache { private IntegerCache(){} static final Integer cache[] = new Integer[-(-128) + 127 + 1]; static { for(int i = 0; i < cache.length; i++) cache = new Integer(i - 128); } }
    從源代碼可以知道,ValueOf對-128~127這256個值(zhi)做了緩存(IntegerCache),如果int值(zhi)的範(fan)圍是︰-128~127,在ValueOf(int)時,他會(hui)直接返回IntegerCache的mu)捍娓恪br />所以你會(hui)看到這樣的一個現象︰
    public static void main(String []args) { Integer a = 100; Integer b = 100; System.out.println(a==b); Integer c = new Integer(100); Integer d = new Integer(100); System.out.println(c==d); }
    結果是︰
    true false
    因(yin)為(wei)︰java在編(bian)譯的時候 Integer a = 100; 被(bei)翻譯成-> Integer a = Integer.valueOf(100);,所以a和(he)b得到都是一個Cache對象,並且是同一個!而c和(he)d是新創建的兩個不(bu)同的對象,所以c自然不(bu)等(deng)于(yu)d。
    再(zai)看看這段代碼︰
    public static void main(String args[]) throws Exception{ Integer a = 100; Integer b = a; a = a + 1; //或者a++; System.out.println(a==b); }
    結果是︰false

    因(yin)為(wei)在對a操作時(a=a+1或者a++),a重新創建了一個對象,而b對應(ying)的mu)故腔捍  00,所以輸出的結果為(wei)false。

     

    52 : SE_BAD_FIELD_STORE

    Category︰BAD_PRACTICE

    描(miao)述(shu)︰不(bu)可shang)蛄謝 鬧zhi)存儲在一個可shang)蛄謝 嗟氖道佷沃/p>

     

    53.Type : OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE

    Category︰EXPERIMENTAL

    描(miao)述(shu)︰在處理異常(chang)時,方法可能未能成功(gong)清理流或資源

    54.Type : NP_NULL_ON_SOME_PATH_EXCEPTION

    Category︰CORRECTNESS

    描(miao)述(shu)︰方法中的異常(chang)路(lu)徑上xi)目贍艿目罩剛虢庖yong)

    55.Type : NP_LOAD_OF_KNOWN_NULL_VALUE

    Category︰STYLE

    描(miao)述(shu)︰加(jia)載(zai)已(yi)知為(wei)空的值(zhi)

     

     

    58. Type : EQ_DOESNT_OVERRIDE_EQUALS

    Category︰STYLE

    描(miao)述(shu)︰類沒有(you)覆蓋(gai)父類中的equals方法

     

    59.Type : DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION

    Category︰BAD_PRACTICE

    描(miao)述(shu)︰不(bu)要使用(yong)removeAll方法清空一個集合

     

     

    60.Type : DM_NEXTINT_VIA_NEXTDOUBLE

    Category︰PERFORMANCE(性能)

    描(miao)述(shu)︰為(wei)了生成一個隨機整數,調用(yong)Random對象的nextInt方法,而不(bu)是nextDouble方法

    61.Type : DM_BOXED_PRIMITIVE_FOR_PARSING

    Category︰PERFORMANCE(性能)

    描(miao)述(shu)︰使用(yong)封裝/反封裝來解析一個基(ji)本類型

    例如1︰

    renturnRecord.setParts(Integer.valueOf(parts[i]));

    處理︰

    renturnRecord.setParts(Integer.valueOf(parts[i]).intValue());

    62.Type : BX_UNBOXING_IMMEDIATELY_REBOXED

    Category︰PERFORMANCE(性能)

    描(miao)述(shu)︰反封裝已(yi)經封裝的值(zhi),然後(hou)又立即(ji)重新lu)庾/p>

     

    63.規則︰LSYC_LOCAL_SYNCHRONIZED_COLLECTION

    問題描(miao)述(shu)︰局部變量,無需(xu)定(ding)義成線(xian)程安全的,可使用(yong)非同步版(ban)本的類替代,如StringBuffer可替換成StringBuilder,不(bu)然會(hui)帶(dai)來不(bu)必要的開(kai)銷(xiao)。


    64.規則︰DOUBLE_CHECK_IN_SINGLETON_CLASS

    問題描(miao)述(shu)︰在多(duo)線(xian)程中創建單(dan)例未使用(yong)double check,當有(you)兩個線(xian)程同時到達時bei)嵊you)性能隱患。參考︰

    http://blog.sina.com.cn/s/blog_7f311ef50102uxvs.html

    65.規則︰FIND_NEW_IN_ONDRAW

    問題修改︰view.ondraw方法在view繪制過(guo)程中會(hui)被(bei)頻繁調用(yong),在方法內進行對象實例化操作會(hui)導(dao)致頻繁的na)詿嬪昵qing)與回收(shou),對性能影(ying)響較大。可以考慮將對象定(ding)義為(wei)view的成員變量並在ondraw方法外進行實例化,每次調用(yong)ondraw時進行 clear或者reset操作。

    66.規則︰REDOS

    問題描(miao)述(shu)︰錯誤(wu)的使用(yong)正則表達式,頻繁的檢索(suo)會(hui)造成shang)閱 侍/p>

    67.規則︰SPP_TOSTRING_ON_STRING

    問題描(miao)述(shu)︰String類調用(yong)toString

    修改方法︰去掉toString方法

    68.規則︰NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE

    問題描(miao)述(shu)︰方法的返回值(zhi)沒有(you)進行是否為(wei)空的檢查就重新賦chi)zhi),這樣可能會(hui)出現空指針異常(chang)

    修改方法︰賦chi)zhi)deng)凹觳槭欠裎wei)空

    69.規則︰RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
    問題修改︰無效的校驗,校驗前已(yi)使用(yong),把(ba)判斷xi)諾絞褂yong)之前

    70.規則︰UUF_UNUSED_FIELD

    問題描(miao)述(shu)︰類中定(ding)義的屬性從you)幢bei)使用(yong),造成資源的浪(lang)費

    問題修改︰建議(yi)刪除(chu)

    71.規則︰DB_DUPLICATE_BRANCHES

    問題描(miao)述(shu)︰不(bu)同的條件分(fen)支實現是相同的,做了很(hen)多(duo)無用(yong)的判斷

    問題修改︰把(ba)相同實現zhi)奶跫fen)支合在一起

    72.規則︰DMI_USELESS_SUBSTRING

    問題描(miao)述(shu)︰無用(yong)的Substring(0) 調用(yong)

    問題修改︰刪除(chu)無用(yong)的Substring(0)調用(yong)

    73.規則︰ICAST_IDIV_CAST_TO_DOUBLE

    問題描(miao)述(shu)︰整形除(chu)法應(ying)該(gai)對除(chu)數轉換成double型,否則結果為(wei)0.

    問題修改︰對除(chu)數進行類型轉換

     

    74.規則︰PCAIL_POSSIBLE_CONSTANT_ALLOCATION_IN_LOOP

    問題描(miao)述(shu)︰對循環體內局部變量使用(yong)固定(ding)常(chang)量實例化,其中shareCore成員變量均為(wei)customizeCallback

    問題修改︰將shareCore放(fang)在循環外定(ding)義

    75.規則︰LSC_LITERAL_STRING_COMPARISON

    問題描(miao)述(shu)︰string.equare之前沒有(you)對string判斷是否為(wei)null,如果為(wei)null會(hui)出現空指針異常(chang)

    問題修改︰預先進行校驗是否為(wei)null

    76.規則︰SPP_USE_ISEMPTY

    問題描(miao)述(shu)︰判斷list是否為(wei)空是建議(yi)使用(yong)isEmpty

    77.規則︰NM_METHOD_NAMING_CONVENTION
    問題描(miao)述(shu)︰方法名(ming)稱以小寫字母開(kai)頭

    78.規則︰SF_SWITCH_NO_DEFAULT

    問題描(miao)述(shu)︰switch語(yu)句中沒有(you)寫default case,當其他case不(bu)能覆蓋(gai)所有(you)情況時可能出現zhong)斐chang);

贵州快3官网

About IT165 -廣告服務 -隱私聲明 -版(ban)權申明 -免責(ze)條款 -網站地(di)圖 -網友投稿 -聯系(xi)方式
本站內容來自于(yu)互聯網,僅(jin)供用(yong)于(yu)網絡技術學習(xi),學習(xi)中xing)qing)遵循相關法律法規
贵州快3官网 | 下一页