編寫高質量代碼:改善Java程序的151個建議：大多數(shù)Java程序員都會在前進的道路上被以下幾類問題所困擾：一、來自于語言本身的問題。例如：覆寫變長方法為什么會出現(xiàn)不能編譯的情況？final修飾的int類型常量竟然在運行期被修改？匿名類是否有構造函數(shù)？它與普通類的構造函數(shù)有何不同？為什么要把受檢異常轉化為非受檢異常？二、來自于程序設計和常用API的問題。例如：如何用一行代碼實現(xiàn)兩個集合的交、差、并集？如何才能動態(tài)加載一個類？數(shù)組如何動態(tài)加載？在switch中使用枚舉類型，為什么會出現(xiàn)NullPointer Exception異常？為什么使用了volatile關鍵字后數(shù)據(jù)還是出現(xiàn)混亂？顯式鎖（Lock類）和內部鎖（synchronized關鍵宇）完全一樣嗎？三、來自于程序架構和思想方面的問題。例如：Java的性能是否曾經(jīng)讓你擔憂過？或者曾經(jīng)讓你很受傷？到底是該多采用開源工具還是自己寫工具類？若采用開源工具，有什么評測標準？什么樣的代碼風格才是優(yōu)秀的？怎么才能讓一個團隊保持同樣的風格？如果你曾經(jīng)為諸如此類的問題感到疑惑不解或頓然大悟，說明你正在向Java技術的巔峰攀登，正在成長為“振臂一呼，應者云集”的技術大牛，恭喜你！

《編寫高質量代碼:改善Java程序的151個建議》從不同的側面出發(fā)，對Java編碼中各種棘手的疑難雜癥和常見問題奉獻了真知灼見，相信你一定能從中受益。從語法、程序設計和架構、工具和框架、編碼風格、編程思想，5個方面深入探討編寫高質量Java代碼的技巧、禁忌和最佳實踐。

編寫高質量代碼:改善Java程序的151個建議 目錄：

前言
第1章　java開發(fā)中通用的方法和準則
建議1: 不要在常量和變量中出現(xiàn)易混淆的字母
建議2: 莫讓常量蛻變成變量
建議3: 三元操作符的類型務必一致
建議4: 避免帶有變長參數(shù)的方法重載
建議5: 別讓null值和空值威脅到變長方法
建議6: 覆寫變長方法也循規(guī)蹈矩
建議7: 警惕自增的陷阱
建議8: 不要讓舊語法困擾你
建議9: 少用靜態(tài)導入
建議10: 不要在本類中覆蓋靜態(tài)導入的變量和方法
建議11: 養(yǎng)成良好習慣,顯式聲明uid
建議12: 避免用序列化類在構造函數(shù)中為不變量賦值
建議13: 避免為final變量復雜賦值
建議14: 使用序列化類的私有方法巧妙解決部分屬性持久化問題
建議15: break萬萬不可忘
建議16: 易變業(yè)務使用腳本語言編寫
建議17: 慎用動態(tài)編譯
建議18: 避免instanceof非預期結果
建議19: 斷言絕對不是雞肋
建議20: 不要只替換一個類

第2章　基本類型
建議21: 用偶判斷,不用奇判斷
建議22: 用整數(shù)類型處理貨幣
建議23: 不要讓類型默默轉換
建議24: 邊界,邊界,還是邊界
建議25: 不要讓四舍五入虧了一方
建議26: 提防包裝類型的null值
建議27: 謹慎包裝類型的大小比較
建議28: 優(yōu)先使用整型池
建議29: 優(yōu)先選擇基本類型
建議30: 不要隨便設置隨機種子

第3章　類、對象及方法
建議31: 在接口中不要存在實現(xiàn)代碼
建議32: 靜態(tài)變量一定要先聲明后賦值
建議33: 不要覆寫靜態(tài)方法
建議34: 構造函數(shù)盡量簡化
建議35: 避免在構造函數(shù)中初始化其他類
建議36: 使用構造代碼塊精煉程序
建議37: 構造代碼塊會想你所想
建議38: 使用靜態(tài)內部類提高封裝性
建議39: 使用匿名類的構造函數(shù)
建議40: 匿名類的構造函數(shù)很特殊
建議41: 讓多重繼承成為現(xiàn)實
建議42: 讓工具類不可實例化
建議43: 避免對象的淺拷貝
建議44: 推薦使用序列化實現(xiàn)對象的拷貝
建議45: 覆寫equals方法時不要識別不出自己
建議46: equals應該考慮null值情景
建議47: 在equals中使用getclass進行類型判斷
建議48: 覆寫equals方法必須覆寫hashcode方法
建議49: 推薦覆寫tostring方法
建議50: 使用package-info類為包服務
建議51: 不要主動進行垃圾回收

第4章　字符串
建議52: 推薦使用string直接量賦值
建議53: 注意方法中傳遞的參數(shù)要求
建議54: 正確使用string、stringbuffer、stringbuilder
建議55: 注意字符串的位置
建議56: 自由選擇字符串拼接方法
建議57: 推薦在復雜字符串操作中使用正則表達式
建議58: 強烈　建議使用utf編碼
建議59: 對字符串排序持一種寬容的心態(tài)

第5章　數(shù)組和集合
建議60: 性能考慮,數(shù)組是首選
建議61: 若有必要,使用變長數(shù)組
建議62: 警惕數(shù)組的淺拷貝
建議63: 在明確的場景下,為集合指定初始容量
建議64: 多種最值算法,適時選擇
建議65: 避開基本類型數(shù)組轉換列表陷阱
建議66: aslist方法產(chǎn)生的list對象不可更改
建議67: 不同的列表選擇不同的遍歷方法
建議68: 頻繁插入和刪除時使用linkedlist
建議69: 列表相等只需關心元素數(shù)據(jù)
建議70:子列表只是原列表的一個視圖
建議71: 推薦使用sublist處理局部列表
建議72: 生成子列表后不要再操作原列表
建議73: 使用comparator進行排序
建議74: 不推薦使用binarysearch對列表進行檢索
建議75: 集合中的元素必須做到compareto和equals同步
建議76: 集合運算時使用更優(yōu)雅的方式
建議77: 使用shuffle打亂列表
建議78: 減少hashmap中元素的數(shù)量
建議79: 集合中的哈希碼不要重復
建議80: 多線程使用vector或hashtable
建議81: 非穩(wěn)定排序推薦使用list
建議82: 由點及面,一葉知秋-集合大家族

第6章　枚舉和注解
建議83: 推薦使用枚舉定義常量
建議84: 使用構造函數(shù)協(xié)助描述枚舉項
建議85: 小心switch帶來的空值異常
建議86: 在switch的default代碼塊中增加assertionerror錯誤
建議87: 使用valueof前必須進行校驗
建議88: 用枚舉實現(xiàn)工廠方法模式更簡潔
建議89: 枚舉項的數(shù)量限制在64個以內
建議90: 小心注解繼承
建議91: 枚舉和注解結合使用威力更大
建議92: 注意@override不同版本的區(qū)別

第7章　泛型和反射
建議93: java的泛型是類型擦除的
建議94: 不能初始化泛型參數(shù)和數(shù)組
建議95: 強制聲明泛型的實際類型
建議96: 不同的場景使用不同的泛型通配符
建議97: 警惕泛型是不能協(xié)變和逆變的
建議98: 　建議采用的順序是list[t]、list[?]、list[object]
建議99: 嚴格限定泛型類型采用多重界限
建議100: 數(shù)組的真實類型必須是泛型類型的子類型
建議101: 注意class類的特殊性
建議102: 適時選擇getdeclared×××和get×××
建議103: 反射訪問屬性或方法時將accessible設置為true
建議104: 使用forname動態(tài)加載類文件
建議105: 動態(tài)加載不適合數(shù)組
建議106: 動態(tài)代理可以使代理模式更加靈活
建議107: 使用反射增加裝飾模式的普適性
建議108: 反射讓模板方法模式更強大
建議109: 不需要太多關注反射效率

第8章　異常
建議110: 提倡異常封裝
建議111: 采用異常鏈傳遞異常
建議112: 受檢異常盡可能轉化為非受檢異常
建議113: 不要在finally塊中處理返回值
建議114: 不要在構造函數(shù)中拋出異常
建議115: 使用throwable獲得棧信息
建議116: 異常只為異常服務
建議117: 多使用異常,把性能問題放一邊

第9章　多線程和并發(fā)
建議118: 不推薦覆寫start方法
建議119: 啟動線程前stop方法是不可靠的
建議120: 不使用stop方法停止線程
建議121: 線程優(yōu)先級只使用三個等級
建議122: 使用線程異常處理器提升系統(tǒng)可靠性
建議123: volatile不能保證數(shù)據(jù)同步
建議124: 異步運算考慮使用callable接口
建議125: 優(yōu)先選擇線程池
建議126: 適時選擇不同的線程池來實現(xiàn)
建議127: lock與synchronized是不一樣的
建議128: 預防線程死鎖
建議129: 適當設置阻塞隊列長度
建議130: 使用countdownlatch協(xié)調子線程
建議131: cyclicbarrier讓多線程齊步走

第10章　性能和效率
建議132: 提升java性能的基本方法
建議133: 若非必要,不要克隆對象
建議134: 推薦使用“望聞問切”的方式診斷性能
建議135: 必須定義性能衡量標準
建議136: 槍打出頭鳥-解決首要系統(tǒng)性能問題
建議137: 調整jvm參數(shù)以提升性能
建議138: 性能是個大“咕咚”

第11章　開源世界
建議139: 大膽采用開源工具
建議140: 推薦使用guava擴展工具包
建議141: apache擴展包
建議142: 推薦使用joda日期時間擴展包
建議143: 可以選擇多種collections擴展

第12章　思想為源
建議144: 提倡良好的代碼風格
建議145: 不要完全依靠單元測試來發(fā)現(xiàn)問題
建議146: 讓注釋正確、清晰、簡潔
建議147: 讓接口的職責保持單一
建議148: 增強類的可替換性
建議149: 依賴抽象而不是實現(xiàn)
建議150: 拋棄7條不良的編碼習慣
建議151: 以技術員自律而不是工人