Github即将破百萬的PDF：編寫高品質代碼改善JAVA程式的151個建議

全書-共12章，第1~ 3章針對Java文法本身提出了51條建議，例如覆寫變長方法

時應該注意哪些事項、final 修飾的常量不要在運作期修改、匿名類的構造函數特殊在什麼

地方等:第4~9章重點針對JDK API的使用提出了80條建議，例如字元串的拼接方法該

如何選擇、枚舉使用時有哪些注意事項、出現NullPointerException該如何處理、泛型的多

重界限該如何使用、多線程程式設計如何預防死鎖，等等r第10~ 12章針對程式性能、開源

的工具和架構、編碼風格和程式設計思想等方面提出了20條建議。

希望本文能讓你少走一些彎路

您是否曾經為了提供一個"One Line"的解決方案而徹夜地檢視源代碼?現在您不用了。
您是否曾經為了了解某個算法而冥思苦想、閱覽群書?現在您不用了。
您是否曾經為了提升0.1秒的性能而對N種實作方案進行嚴格測試和對比?現在您不用了。
您是否曾經為了避免多線程死鎖問題而遍尋高手共同診治?現在您不用了。

廢話不多說直接把本書部分内容展示出來

建議1:不要在常量和變量中出現易混淆的字母/2
建議2:莫讓常量蛻變成變量12
建議3:三元操作符的類型務必一緻/3
建議4:避免帶有變長參數的方法重載14
建議5:别讓null值和空值威脅到變長方法/6
建議6:覆寫變長方法也循規蹈矩17
建議7:警惕自增的陷阱/8
建議8:不要讓舊文法困擾你/10
建議9:少用靜态導人/11
建議10:不要在本類中覆寫靜态導人的變量和方法/13
建議11:養成良好習慣，顯式聲明UID/14
建議12:避免用序列化類在構造函數中為不變量指派/17
建議13:避免為final變量複雜指派/19
建議14:使用序列化類的私有方法巧妙解決部分屬性持久化問題/20
建議15: break萬萬不可忘/23
建議16:易變業務使用腳本語言編寫/25
建議17:慎用動态編譯/27
建議18:避免instanceof非預期結果/29
建議19:斷言絕對不是雞肋/31
建議20:不要隻替換一個類/33

第2章基本類型 /35

建議21:用偶判斷，不用奇判斷/36
建議22:用整數類型處理貨币/37
建議23:不要讓類型默默轉換/38
建議24:邊界，邊界，還是邊界/39
建議25:不要讓四舍五人虧了一方/41
建議26:提防包裝類型的null值/43
建議27:謹慎包裝類型的大小比較/145
建議28:優先使用整型池/46
建議29:優先選擇基本類型148
建議30:不要随便設定随機種子149

第3章類、對象及方法152

建議31:在接口中不要存在實作代碼/53
建議32:靜态變量- -定要先聲明後指派/54
建議33:不要覆寫靜态方法155
建議34:構造函數盡量簡化157
建議35:避免在構造函數中初始化其他類/58
建議36:使用構造代碼塊精煉程式/60
建議37:構造代碼塊會想你所想/61
建議38:使用靜态内部類提高封裝性/63
建議39:使用匿名類的構造函數/65
建議40:置名類的構造函數很特殊/66
建議41:讓多重繼承成為現實/68
建議42:讓工具類不可執行個體化170
建議43:避免對象的淺拷貝/71
建議44:推薦使用序列化實作對象的拷貝/73
建議45:覆寫equals方法時不要識别不出自己1/74
建議46: equals 應該考慮null值情景176
建議47:在equals中使用getClass進行類型判斷177
建議48:覆寫equals方法必須覆寫hashCode方法178
建議49:推薦覆寫toString方法/80
建議50:使用package-info 類為包服務/81
建議51:不要主動進行垃圾回收/82

第4章字元串/83

建議52:推薦使用String直接量指派/84
建議53:注意方法中傳遞的參數要求/85
建議54:正确使用String、StringBuffer. StringBuilder/86
建議55:注意宇符串的位置/87
建議56:***選擇字元申拼接方法/88
建議57:推薦在複雜字元串操作中使用正規表達式/90
建議58:強烈建議使用UTF編碼/92
建議59;對字元串排序持一種寬容的心态/94

第5章數組和集合 /97

建議60:性能考慮，數組是首選/98
建議61:若有必要，使用變長數組/99
建議62:警惕數組的淺拷貝/100
建議63:在明确的場景下，為集合指定初始容量/101
建議64:多種最值算法，适時選擇/104
建議65:避開基本類型數組轉換清單陷阱/105
建議66; asList 方法産生的List對象不可更改/107
建議67:不同的清單選擇不同的周遊方法/108
建議68:頻繁插入和删除時使用LinkedList/112
建議69;清單相等隻需關心元素資料/115
建議70:子清單隻是原清單的-一個視圖/117
建議71:推薦使用subList處理局部清單/119
建議72:生成子清單後不要再操作原清單/120
建議73:使用Comparator進行排序/122
建議74:不推薦使用binarySearch對清單進行檢索/125
建議75;集合中的元素必須做到compareTo和equals同步/127
建議76:集合運算時使用更優雅的方式/129
建議77;使用shufle打亂清單/131
建議78;減少HashMap中元素的數量/132
建議79;集合中的哈希碼不要重複/135
建議80;多線程使用Vector 或HashTable/139
建議81:非穩定排序推薦使用List/141
建議82:由點及面，一葉知秋一集合大家族/143

第6章枚舉和注解 /145

建議83:推薦使用枚舉定義常量/146
建議84:使用構造函數協助描述枚舉項/149
建議85:小心switch帶來的空值異常/150
建議86;在switch的default 代碼塊中增加AsserionError錯誤/152
建議87:使用valueOf前必須進行校驗/152
建議88:用枚舉實作工廠方法模式更簡潔/155
建議89:枚舉項的數量限制在64個以内/157
建議90:小心注解繼承/160
建議91:枚舉和注解結合使用威力更大/162
建議92:注意@Override不同版本的差別/164

第7章泛型和反射 /166

建議93: Java的泛型是類型擦除的/167
建議94:不能初始化泛型參數和數組/169
建議95:強制聲明泛型的實際類型/170
建議96:不同的場景使用不同的泛型通配符/172
建議97;警惕泛型是不能協變和逆變的/174
建議98:建議采用的順序是List<T>、List<?>、 List<Object>/176
建議99;嚴格限定泛型類型采用多重界限/177
建議100:數組的真實類型必須是泛型類型的子類型/179
建議101:注意Class類的特殊性/181
建議102:适時選擇getDeclaredXxx和getxx X/181
建議103:反射通路屬性或方法時将Acessible設定為true /182
建議104:使用forName動态加載類檔案/184
建議105:動态加載不适合數組/186
建議106;動态代理可以使代理模式更加靈活/188
建議107:使用反射增加裝飾模式的普适性/190
建議108:反射讓模闆方法模式更強大/192
建議109:不需要太多關注反射效率/194

第8章異常/197

建議110:提倡異常封裝/198
建議111:采用異常鍊傳遞異常/200
建議112:受檢異常盡可能轉化為非受檢異常/202
建議113:不要在finally塊中處理傳回值/204
建議114:不要在構造函數中抛出異常/207
建議115;使用Throwable獲得棧資訊/210
建議116:異常隻為異常服務/212
建議117:多使用異常，把性能問題放- -邊 /213

第9章多線程和并發 /215

建議118:不推薦覆寫start方法/216
建議119:啟動線程前stop方法是不可靠的/218
建議120:不使用stop方法停止線程/220
建議121:線程優先級隻使用三個等級/224
建議122:使用線程異常處理器提升系統可靠性/226
建議123: volatile 不能保證資料同步1228
建議124:異步運算考慮使用Callable接口/232
建議125:優先選擇線程池/233
建議126:适時選擇不同的線程池來實作/237
建議127: Lock與synchronized是不一樣的/240
建議128:預防線程死鎖/245
建議129:适當設定阻塞隊列長度/250
建議130:使用CountDownLatch協調子線程/252
建議131: CyclicBarrier 讓多線程齊步走/254

第10章性能和效率 /256

建議132:提升Java性能的基本方法/257
建議133:若非必要，不要克隆對象/259
建議134:推薦使用“望聞問切”的方式診斷性能/261
建議135:必須定義性能衡量标準/263
建議136:槍打出頭鳥一解決首要系統性能問題/264
建議137:調整JVM參數以提升性能/266
建議138:性能是個大“咕咚”/268

第11章開源世界/271

建議139:大膽采用開源工具1/272
建議140:推薦使用Guava擴充工具包1/273
建議141: Apache護展包1/276
建議142:推薦使用Joda日期時間擴充包/280
建議143:可以選擇多種Collections擴充/282

第12章思想為源/285

建議144:提倡良好的代碼風格/286
建議145:不要完全依靠單元測試來發現問題/287
建議146:讓注釋正确、清晰、簡潔/290
建議147:讓接口的職責保持單一/294
建議148:增強類的可替換性/295
建議149:依賴抽象而不是實作/298
建議150:抛棄7條不良的編碼習慣/299
建議151:以技術員自律而不是勞工/301

Github即将破百萬的PDF：編寫高品質代碼改善JAVA程式的151個建議

目錄