白話阿里巴巴Java開發手冊

時間 2019-11-22

原文原文鏈接

最近，阿里巴巴發佈了《阿里巴巴Java開發手冊》，總結了阿里人多年一線實戰中積累的研發流程規範，這些流程規範在必定程度上可以保證最終的項目交付質量，經過限制開發人員的編程風格、實現方式來避免研發人員在實踐中容易犯的錯誤，一樣的問題你們使用一樣的模式解決，便於後期維護和擴展，確保最終在大規模協做的項目中達成既定目標。無獨有偶，筆者去年在公司裏負責升級和制定研發流程、設計模板、設計標準、代碼標準等規範，並在實際工做中進行了應用和推廣，收效頗豐，也總結了適合支付平臺的技術規範，因爲阿里巴巴Java開發手冊自己定位爲規約和規範，語言簡單、精煉，沒有太多的解讀和示例，有些條款對於通常開發人員理解起來比較困難，本文藉着阿里巴巴發佈的Java開發手冊，詳細解讀Java平臺下開發規範和標準的制定和實施，強調那些在開發過程當中須要重點關注的技術點，特別是解決某類已識別問題的模式和反模式。《阿里巴巴Java開發手冊》分爲編程規約、異常日誌、MySQL規約、工程規約、安全規約五大部分，本系列文章以這五部分主題爲主線，分爲五篇文章發佈，本文爲系列文章的第一篇-編程規約，後續會盡快發佈其他的文章。 1 命名規約【強制】代碼中的命名均不能如下劃線或美圓符號開始，也不能如下劃線或美圓符號結束。反例: _name / _name / / Object$ 白話：這條不夠嚴格，普通的變量、類名、方法名必須使用駝峯式命名，最好不要使用下劃線和美圓符號，不然看起來像腳本語言似得，常量能夠使用下劃線，可是也不要放在常量開頭和結尾。【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。說明: 正確的英文拼寫和語法可讓閱讀者易於理解，避免歧義。注意，即便純拼音命名方式也要避免採用。反例: DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變量 = 3 正例: alibaba / taobao / youku / hangzhou 等國際通用的名稱，可視同英文。白話：中英混合的人種咱不歧視，變量名混合太醜了。 Java編譯器支持Unicode（UTF-8)，容許中文命名變量，不過打中文仍是沒有英文快。英文！英文起名，洋氣、大方、高大上... 【強制】類名使用 UpperCamelCase 風格，必須聽從駝峯形式，但如下情形例外:(領域模型的相關命名)DO / BO / DTO / VO等。正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion 白話：約定俗成的名稱或者縮寫例外。【強制】方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須聽從駝峯形式。正例: localValue / getHttpMessage() / inputUserId 白話：約定俗稱的名稱或者縮寫例外。 ID爲簡寫，Id和ID都可。【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。正例: MAX_STOCK_COUNT 反例: MAX_COUNT 白話：必須所有大寫，除了字母數字只能夠使用下劃線，而且不能用在開頭和結尾。【強制】抽象類命名使用 Abstract 或 Base 開頭;異常類命名使用 Exception 結尾;測試類命名以它要測試的類的名稱開始，以 Test 結尾。白話：家裏放一瓶敵敵畏，上面不寫標籤，萬一喝大了、渴了、喝了、就慘了，你懂的。【強制】中括號是數組類型的一部分，數組定義以下:String[] args; 反例: 使用String args[]的方式來定義。白話：這種語法編譯器也認，可是咱們畢竟寫Java程序，而不是寫C/C++程序。這怪Java編譯器小組，一開始就不該該支持這種語法。【強制】POJO 類中布爾類型的變量，都不要加 is，不然部分框架解析會引發序列化錯誤。反例: 定義爲基本數據類型Boolean isSuccess;的屬性，它的方法也是isSuccess()，RPC 框架在反向解析的時候，「覺得」對應的屬性名稱是 success，致使屬性獲取不到，進而拋出異常。白話：一些框架使用getter和setter作序列化，有的根據屬性自己取值，帶了is前綴就找不到了，變量名不要帶be動詞，語法不對，英文補考！【強制】包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英語單詞。包名統一使用單數形式，可是類名若是有複數含義，類名能夠使用複數形式。正例: 應用工具類包名爲com.alibaba.open.util、類名爲MessageUtils(此規則參考 spring 的框架結構) 白話：包名大寫、帶下劃線等，不專業、難看、不高大上。【強制】杜絕徹底不規範的縮寫，避免望文不知義。反例: AbstractClass「縮寫」命名成 AbsClass;condition「縮寫」命名成 condi，此類隨意縮寫嚴重下降了代碼的可閱讀性。白話：不要太摳，不是太長的名字直接寫上就好，編譯器編譯優化後變量名將不存在，會編譯成相對於方法堆棧bp指針地址的相對地址，長變量名不會佔用更多空間。英文中的縮寫有個慣例，去掉元音留下輔音便可，不能亂縮寫。【推薦】若是使用到了設計模式，建議在類名中體現出具體模式。說明: 將設計模式體如今名字中，有利於閱讀者快速理解架構設計思想。正例: public class OrderFactory; public class LoginProxy; public class ResourceObserver; 白話：讓全世界都知道你會設計模式，這是個崇尚顯擺的社會。【推薦】接口類中的方法和屬性不要加任何修飾符號(public 也不要加)，保持代碼的簡潔性，並加上有效的 Javadoc 註釋。儘可能不要在接口裏定義變量，若是必定要定義變量，確定是與接口方法相關，而且是整個應用的基礎常量。正例: 接口方法簽名:void f(); 接口基礎常量表示:String COMPANY = "alibaba"; 反例: 接口方法定義:public abstract void f(); 說明:JDK8 中接口容許有默認實現，那麼這個 default 方法，是對全部實現類都有價值的默認實現。白話：脫了褲子放屁始終有點麻煩。接口和實現類的命名有兩套規則: 1)【強制】對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務必定是接口，內部的實現類用 Impl 的後綴與接口區別。正例: CacheServiceImpl 實現 CacheService 接口。 2)【推薦】若是是形容能力的接口名稱，取對應的形容詞作接口名(一般是–able 的形式)。正例: AbstractTranslator 實現 Translatable。白話：嚴重贊成！但是想一想Observer和Observable，我就不說話了。【參考】枚舉類名建議帶上 Enum 後綴，枚舉成員名稱須要全大寫，單詞間用下劃線隔開。說明: 枚舉其實就是特殊的常量類，且構造方法被默認強制是私有。正例: 枚舉名字:DealStatusEnum，成員名稱: SUCCESS / UNKOWN_REASON。白話：不要駝峯！記住枚舉不要駝峯！老是有好多人枚舉用駝峯。【參考】各層命名規約: A) Service/DAO層方法命名規約java

獲取單個對象的方法用get作前綴。
獲取多個對象的方法用list作前綴。
獲取統計值的方法用count作前綴。
插入的方法用save(推薦)或insert作前綴。
刪除的方法用remove(推薦)或delete作前綴。
修改的方法用update作前綴。 B) 領域模型命名規約
數據對象:xxxDO，xxx即爲數據表名。
數據傳輸對象:xxxDTO，xxx爲業務領域相關的名稱。
展現對象:xxxVO，xxx通常爲網頁名稱。
POJO是DO/DTO/BO/VO的統稱，禁止命名成xxxPOJO。白話：你們都這麼認爲很重要。 2 常量定義【強制】不容許出現任何魔法值(即未經定義的常量)直接出如今代碼中。反例: String key = "Id#taobao_"+tradeId; cache.put(key, value); 白話：這個不用說了，隨地吐痰和隨地大小即是不該該的，新加坡是要鞭刑的！【強制】long 或者 Long 初始賦值時，必須使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，形成誤解。說明: Long a = 2l; 寫的是數字的21，仍是Long型的2? 白話：看看區塊鏈中用了base58，而不是base64，秒懂什麼是從用戶角度考慮產品設計！【推薦】不要使用一個常量類維護全部常量，應該按常量功能進行歸類，分開維護。如:緩存相關的常量放在類: CacheConsts 下; 系統配置相關的常量放在類: ConfigConsts 下。說明: 大而全的常量類，非得使用查找功能才能定位到修改的常量，不利於理解和維護。白話：儘可能讓功能自閉包，標準是一個小模塊拷貝出去直接就能用，而不是缺這缺那的，是否是讀者不少時候拷貝了一套類，運行時候發現不能用，缺常量，把常量類拷貝過來，發現常量類中有不少不相關的常量，還得清理。【推薦】常量的複用層次有五層: 跨應用共享常量、應用內共享常量、子工程內共享常量、包內共享常量、類內共享常量。
跨應用共享常量: 放置在二方庫中，一般是client.jar中的constant目錄下。
應用內共享常量: 放置在一方庫的modules中的constant目錄下。反例: 易懂變量也要統必定義成應用內共享常量，兩位攻城師在兩個類中分別定義了表示「是」的變量: 類A中: public static final String YES = "yes"; 類B中: public static final String YES = "y"; A.YES.equals(B.YES)，預期是 true，但實際返回爲 false，致使產生線上問題。
子工程內部共享常量: 即在當前子工程的constant目錄下。
包內共享常量: 即在當前包下單獨的constant目錄下。
類內共享常量: 直接在類內部private static final定義。白話：一方庫、二方庫、三方庫，叫法很專業，放在離本身最近的上面一個層次便可。【推薦】若是變量值僅在一個範圍內變化用 Enum 類。若是還帶有名稱以外的延伸屬性，必須使用 Enum 類，下面正例中的數字就是延伸信息，表示星期幾。正例: public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);} 白話：枚舉值須要定義延伸屬性的場景一般是要持久數據庫，或者顯示在界面上。 3 格式規約【強制】大括號的使用約定。若是是大括號內爲空，則簡潔地寫成{}便可，不須要換行; 若是是非空代碼塊則:
左大括號前不換行。
左大括號後換行。
右大括號前換行。
右大括號後還有else等代碼則不換行;表示終止右大括號後必須換行。白話：好風格，討厭那種左大括號前換行的，看不慣。【強制】左括號和後一個字符之間不出現空格; 一樣，右括號和前一個字符之間也不出現空格。詳見第 5 條下方正例提示。白話：程序寫完能夠用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程序的時候有個習慣，每次謝了一段代碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。【強制】if/for/while/switch/do 等保留字與左右括號之間都必須加空格。白話：程序寫完能夠用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程序的時候有個習慣，每次謝了一段代碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。【強制】任何運算符左右必須加一個空格。說明: 運算符包括賦值運算符=、邏輯運算符&&、加減乘除符號、三目運算符等。白話：程序寫完能夠用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程序的時候有個習慣，每次謝了一段代碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。【強制】縮進採用 4 個空格，禁止使用 tab 字符。說明: 若是使用 tab 縮進，必須設置 1 個 tab 爲 4 個空格。IDEA 設置 tab 爲 4 個空格時，請勿勾選Use tab character; 而在 eclipse 中，必須勾選 insert spaces for tabs。正例: (涉及1-5點) public static void main(String[] args) { // 縮進 4 個空格 String say = "hello"; // 運算符的左右必須有一個空格 int flag = 0; // 關鍵詞 if 與括號之間必須有一個空格，括號內的 f 與左括號，0 與右括號不須要空格 if (flag == 0) { System.out.println(say); } // 左大括號前加空格且不換行;左大括號後換行 if (flag == 1) { System.out.println("world"); // 右大括號前換行，右大括號後有 else，不用換行 } else { System.out.println("ok"); // 在右大括號後直接結束，則必須換行 } } 白話：這樣看慣了，怎麼看怎麼清晰。【強制】單行字符數限制不超過 120 個，超出須要換行，換行時遵循以下原則:
第二行相對第一行縮進 4 個空格，從第三行開始，再也不繼續縮進，參考示例。
運算符與下文一塊兒換行。
方法調用的點符號與下文一塊兒換行。
在多個參數超長，逗號後進行換行。
在括號前不要換行，見反例。正例: StringBuffer sb = new StringBuffer();//超過 120 個字符的狀況下，換行縮進 4 個空格，而且方法前的點符號一塊兒換行 sb.append("zi").append("xin")... .append("huang")... .append("huang")... .append("huang"); 反例: StringBuffer sb = new StringBuffer();//超過 120 個字符的狀況下，不要在括號前換行 sb.append("zi").append("xin")...append ("huang");//參數不少的方法調用可能超過 120 個字符，不要在逗號前換行 method(args1, args2, args3, ... , argsX); 白話：一行代碼儘可能不要寫太長，長了拆開不就得了。【強制】方法參數在定義和傳入時，多個參數逗號後邊必須加空格。正例: 下例中實參的"a", 後邊必需要有一個空格。 method("a", "b", "c"); 白話：不加空格太擠了，就像人沒長開似得。【強制】IDE的text file encoding設置爲UTF-8; IDE中文件的換行符使用Unix格式，不要使用 windows 格式。白話：請不要用GB字符集，換了環境總有問題，Java程序多數跑在Linux上，固然要用Unix換行符。【推薦】沒有必要增長若干空格來使某一行的字符與上一行的相應字符對齊。正例: int a = 3; long b = 4L; float c = 5F; StringBuffer sb = new StringBuffer(); 說明: 增長 sb 這個變量，若是須要對齊，則給 a、b、c 都要增長几個空格，在變量比較多的狀況下，是一種累贅的事情。白話：不必，不必，那樣反而很差看。【推薦】方法體內的執行語句組、變量的定義語句組、不一樣的業務邏輯之間或者不一樣的語義之間插入一個空行。相同業務邏輯和語義之間不須要插入空行。說明: 沒有必要插入多行空格進行隔開。白話：和個人習慣同樣同樣的，一段邏輯空一行。 4 OOP 規約【強制】避免經過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增長編譯器解析成本，直接用類名來訪問便可。白話：也不直觀，看調用代碼看不出來是靜態方法，容易誤解。【強制】全部的覆寫方法，必須加@Override 註解。反例:getObject()與 get0bject()的問題。一個是字母的 O，一個是數字的 0，加@Override 能夠準確判斷是否覆蓋成功。另外，若是在抽象類中對方法簽名進行修改，其實現類會立刻編譯報錯。白話： Java和C++不同，C++是在父類先聲明虛擬函數子類才覆寫，Java是任何方法都能覆寫，也能夠不覆寫，因此覆寫不覆寫是沒有編譯器檢查的，除非接口中某一個方法徹底沒有被實現纔會編譯報錯。【強制】相同參數類型，相同業務含義，才能夠使用 Java 的可變參數，避免使用 Object。說明: 可變參數必須放置在參數列表的最後。(提倡同窗們儘可能不用可變參數編程) 正例: public User getUsers(String type, Integer... ids) 白話：用處不大，能夠用重載方法或者數組參數代替。通常應用在日誌的 API 定義上，用於傳不定的日誌參數。【強制】外部正在調用或者二方庫依賴的接口，不容許修改方法簽名，避免對接口調用方產生影響。接口過期必須加@Deprecated 註解，並清晰地說明採用的新接口或者新服務是什麼。白話：設計時沒有考慮周全，須要改造接口，須要經過增長新接口，遷移後下線老接口的方式實現。 REST接口只能增長參數，不能減小參數，返回值的內容也是隻增不減。【強制】不能使用過期的類或方法。說明: java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已通過時，應該使用雙參數 decode(String source, String encode)。接口提供方既然明確是過期接口，那麼有義務同時提供新的接口; 做爲調用方來講，有義務去考證過期方法的新實現是什麼。白話：明確了責任和義務，接口提供方也有義務推進接口使用方儘早遷移，不要積累技術負債。【強制】Object 的 equals 方法容易拋空指針異常，應使用常量或肯定有值的對象來調用 equals。正例: "test".equals(object); 反例: object.equals("test"); 說明: 推薦使用java.util.Objects#equals (JDK7引入的工具類) 白話：常量比變量，永遠都不變的原則。【強制】全部的相同類型的包裝類對象之間值的比較，所有使用 equals 方法比較。說明: 對於Integer var = ?在-128至127之間的賦值，Integer對象是在 IntegerCache.cache 產生，會複用已有對象，這個區間內的 Integer 值能夠直接使用==進行判斷，可是這個區間以外的全部數據，都會在堆上產生，並不會複用已有對象，這是一個大坑，推薦使用 equals 方法進行判斷。白話： Java世界裏相等請用equals方法，==表示對象相等，通常在框架開發中會用到。關於基本數據類型與包裝數據類型的使用標準以下:
【強制】全部的POJO類屬性必須使用包裝數據類型。
【強制】RPC方法的返回值和參數必須使用包裝數據類型。
【推薦】全部的局部變量使用基本數據類型。說明: POJO 類屬性沒有初值是提醒使用者在須要使用時，必須本身顯式地進行賦值，任何 NPE 問題，或者入庫檢查，都由使用者來保證。正例: 數據庫的查詢結果多是 null，由於自動拆箱，用基本數據類型接收有 NPE 風險。反例: 好比顯示成交總額漲跌狀況，即正負 x%，x 爲基本數據類型，調用的 RPC 服務，調用不成功時，返回的是默認值，頁面顯示:0%，這是不合理的，應該顯示成中劃線-。因此包裝數據類型的 null 值，可以表示額外的信息，如:遠程調用失敗，異常退出。白話：其實包裝數據類型與基本數據類型相比，增長了一個null的狀態，能夠攜帶更多的語義。【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性默認值。反例: POJO類的gmtCreate默認值爲new Date(); 可是這個屬性在數據提取時並無置入具體值，在更新其它字段時又附帶更新了此字段，致使建立時間被修改爲當前時間。白話：雖然這裏反例不太容易看懂，可是要記得持久領域對象以前由應用層統一賦值gmtCreate和gmtModify字段。【強制】序列化類新增屬性時，請不要修改 serialVersionUID 字段，避免反序列失敗; 如果徹底不兼容升級，避免反序列化混亂，那麼請修改 serialVersionUID 值。說明:注意 serialVersionUID 不一致會拋出序列化運行時異常。白話：不到萬不得已不要使用JDK自身的序列化，機制很重，信息冗餘有版本。【強制】構造方法裏面禁止加入任何業務邏輯，若是有初始化邏輯，請放在 init 方法中。白話：這樣作一種是規範，代碼清晰，還有就是異常堆棧上更容易識別出錯的方法和語句。【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具:source> generate toString 時，若是繼承了另外一個 POJO 類，注意在前面加一下 super.toString。說明: 在方法執行拋出異常時，能夠直接調用 POJO 的 toString()方法打印其屬性值，便於排查問題。白話：這裏還有一個大坑，寫toString的時候要保證不會發生NPE，有的時候toString調用實例變量的toString，實例變量因爲某些緣由爲null，致使NPE，代碼沒有處理好就終止，這個問題坑了好屢次。【推薦】使用索引訪問用 String 的 split 方法獲得的數組時，需作最後一個分隔符後有無內容的檢查，不然會有拋 IndexOutOfBoundsException 的風險。說明: String str = "a,b,c,,"; String[] ary = str.split(","); //預期大於 3，結果是 3 System.out.println(ary.length); 白話：編程要留心眼，任何不肯定的地方都要判斷、處理，不然掉到坑裏了本身爬出來很費勁。 Java編程判空的思想要實施縈繞在每一個開發人員的腦海裏。【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一塊兒，便於閱讀。白話：這規範說的咋就和個人習慣如出一轍呢！【推薦】類內方法定義順序依次是: 公有方法或保護方法 > 私有方法 > getter/setter 方法。說明: 公有方法是類的調用者和維護者最關心的方法，首屏展現最好; 保護方法雖然只是子類關心，也多是「模板設計模式」下的核心方法; 而私有方法外部通常不須要特別關心，是一個黑盒實現; 由於方法信息價值較低，全部 Service 和 DAO 的 getter/setter 方法放在類體最後。白話：我推薦把一套邏輯的共有方法、保護方法、私有方法放在一塊兒，全部getter/setter放在最後，這樣感受更有邏輯！【推薦】setter 方法中，參數名稱與類成員變量名稱一致，this.成員名 = 參數名。在 getter/setter 方法中，儘可能不要增長業務邏輯，增長排查問題的難度。反例: public Integer getData() { if (true) { return data + 100; } else { return data - 100; } } 白話：雙手同意。【推薦】循環體內，字符串的鏈接方式，使用 StringBuilder 的 append 方法進行擴展。反例: String str = "start"; for (int I = 0; I < 100; i++) { str = str + "hello"; } 說明: 反編譯出的字節碼文件顯示每次循環都會 new 出一個 StringBuilder 對象，而後進行 append 操做，最後經過 toString 方法返回 String 對象，形成內存資源浪費。白話：必定使用StringBuilder，不要使用StringBuffer，StringBuffer是線程安全的，過重。我就一直想不明白Java編譯器爲何不作個優化呢？【推薦】下列狀況，聲明成 final 會更有提示性:
不須要從新賦值的變量，包括類屬性、局部變量。
對象參數前加final，表示不容許修改引用的指向。
類方法肯定不容許被重寫。白話：儘可能多使用final關鍵字，保證編譯器的校驗機制起做用，也體現了「契約式編程」的思想。【推薦】慎用 Object 的 clone 方法來拷貝對象。說明: 對象的 clone 方法默認是淺拷貝，若想實現深拷貝須要重寫 clone 方法實現屬性對象的拷貝。白話：最好是使用構造函數來從新構造對象，使用clone淺拷貝的時候，對象引用關係可能很複雜，不直觀，很差理解。【推薦】類成員與方法訪問控制從嚴:
若是不容許外部直接經過new來建立對象，那麼構造方法必須是private。
工具類不容許有public或default構造方法。
類非static成員變量而且與子類共享，必須是protected。
類非static成員變量而且僅在本類使用，必須是private。
類static成員變量若是僅在本類使用，必須是private。
如果static成員變量，必須考慮是否爲final。
類成員方法只供類內部調用，必須是private。
類成員方法只對繼承類公開，那麼限制爲protected。說明: 任何類、方法、參數、變量，嚴控訪問範圍。過寬泛的訪問範圍，不利於模塊解耦。思考: 若是是一個 private 的方法，想刪除就刪除，但是一個 public 的 Service 方法，或者一個 public 的成員變量，刪除一下，不得手心冒點汗嗎?變量像本身的小孩，儘可能在本身的視線內，變量做用域太大，若是無限制的處處跑，那麼你會擔憂的。白話：沒什麼好說的，兩個詞，高內聚，低耦合，功能模塊閉包，哦，是三個詞。 5 集合處理【強制】關於 hashCode 和 equals 的處理，遵循以下規則:
只要重寫equals，就必須重寫hashCode。
由於Set存儲的是不重複的對象，依據hashCode和equals進行判斷，因此Set存儲的對象必須重寫這兩個方法。
若是自定義對象作爲Map的鍵，那麼必須重寫hashCode和equals。說明: String 重寫了 hashCode 和 equals 方法，因此咱們能夠很是愉快地使用 String 對象做爲 key 來使用。白話： Hash是個永恆的話題，你們能夠看下times33和Murmurhash算法。【強制】ArrayList的subList結果不可強轉成ArrayList，不然會拋出ClassCastException 異常: java.util.RandomAccessSubList cannot be cast to java.util.ArrayList ; 說明: subList 返回的是 ArrayList 的內部類 SubList，並非 ArrayList ，而是 ArrayList 的一個視圖，對於SubList子列表的全部操做最終會反映到原列表上。白話：這種問題原本測試能夠測試到，可是開發永遠都不要有依賴測試的想法，一切靠本身，固然咱們的測試人員都是很靠譜的。【強制】在 subList 場景中，高度注意對原集合元素個數的修改，會致使子列表的遍歷、增加、刪除均產生ConcurrentModificationException 異常。白話：若是必定要更改子列表，從新構造新的ArrayList，使用public ArrayList(Collection<? extends E> c)。【強制】使用集合轉數組的方法，必須使用集合的toArray(T[] array)，傳入的是類型徹底同樣的數組，大小就是 list.size()。說明: 使用 toArray 帶參方法，入參分配的數組空間不夠大時，toArray 方法內部將從新分配內存空間，並返回新數組地址; 若是數組元素大於實際所需，下標爲[ list.size() ]的數組元素將被置爲 null，其它數組元素保持原值，所以最好將方法入參數組大小定義與集合元素個數一致。正例: List list = new ArrayList(2); list.add("guan"); list.add("bao"); String[] array = new String[list.size()]; array = list.toArray(array); 反例: 直接使用 toArray 無參方法存在問題，此方法返回值只能是 Object[]類，若強轉其它類型數組將出現 ClassCastException 錯誤。白話：搞不懂Java編譯器爲何不作優化，人用邏輯能推導的，程序必定能夠自動實現。【強制】使用工具類 Arrays.asList()把數組轉換成集合時，不能使用其修改集合相關的方法，它的 add/remove/clear 方法會拋出 UnsupportedOperationException 異常。說明: asList 的返回對象是一個 Arrays 內部類，並無實現集合的修改方法。Arrays.asList 體現的是適配器模式，只是轉換接口，後臺的數據還是數組。 String[] str = new String[] { "a", "b" }; List list = Arrays.asList(str); 第一種狀況: list.add("c"); 運行時異常。第二種狀況: str[0] = "gujin"; 那麼list.get(0)也會隨之修改。白話：若是須要對asList返回的List作更改，能夠構造新的ArrayList，使用public ArrayList(Collection<? extends E> c)構造器。【強制】泛型通配符<? extends T>來接收返回的數據，此寫法的泛型集合不能使用add方法，而<? super T>不能使用get方法，作爲接口調用賦值時易出錯。說明: 擴展說一下PECS(Producer Extends Consumer Super)原則: 1)頻繁往外讀取內容的，適合用上界 Extends。 2)常常往裏插入的，適合用下界 Super。白話：下面是示例，test1和test2在編譯時都有錯誤提示。 package com.robert.javaspec;import java.util.LinkedList;import java.util.List;/**

Created by WangMeng on 2017-04-13.
FIX ME */public class Main { public static void main(String[] args) { } public void test1(){ List<? extends A> childofa=new LinkedList<>(); B b=new B(); A a=new A(); childofa.add(a); childofa.add(b); A ta= childofa.get(0); } public void test2(){ List<? super B> superOfb = new LinkedList<>(); B b = new B(); A a = new A(); superOfb.add(a); superOfb.add(b); A ta = superOfb.get(0); B tb = superOfb.get(0); } }class A { @Override public String toString() { return "A"; } }class B extends A { @Override public String toString() { return "B"; } }

， ? 必須是T或T的子類集合寫(add)：由於不能肯定集合實例化時用的是T或T的子類，因此沒有辦法寫。例如：List<? extends Number> foo = new ArrayList<Number/Integer/Double>()，你不能add Number，由於也多是Integer或Double的List，同理也不能add Integer或Double，即，extends T，不能集合add。集合讀(get)：只能讀出T類型的數據。， ? 必須是T或T的父類集合寫(add)：能夠add T或T的子類。集合讀(get)：不能肯定從集合裏讀出的是哪一個類型（多是T也多是T的父類，或者Object），因此沒有辦法使用get。例如：List<? super Integer> foo3 = new ArrayList<Integer/Number/Object>(); 只能保證get出來是Object。【強制】不要在 foreach 循環裏進行元素的 remove/add 操做。remove 元素請使用 Iterator 方式，若是併發操做，須要對 Iterator 對象加鎖。反例: List a = new ArrayList(); a.add("1"); a.add("2");for (String temp : a) { if ("1".equals(temp)) { a.remove(temp); } } 說明: 以上代碼的執行結果確定會出乎你們的意料，那麼試一下把「1」換成「2」，會是一樣的結果嗎? 正例: Iterator it = a.iterator(); while (it.hasNext()) { String temp = it.next(); if (刪除元素的條件) { it.remove(); } } 白話：修改必定要使用Iterator。反例中改爲2，拋出ConcurrentModificationException，由於2是數組的結束邊界。【強制】在 JDK7 版本及以上，Comparator 要知足以下三個條件，否則 Arrays.sort， Collections.sort 會報 IllegalArgumentException 異常。說明: 1) x，y的比較結果和y，x的比較結果相反。 2) x>y，y>z，則x>z。 3) x=y，則x，z比較結果和y，z比較結果相同。反例: 下例中沒有處理相等的狀況，實際使用中可能會出現異常: new Comparator() { @Override public int compare(Student o1, Student o2) { return o1.getId() > o2.getId() ? 1 : -1; } } 白話：除非邏輯混亂，不然這些條件都能知足。【推薦】集合初始化時，儘可能指定集合初始值大小。說明: ArrayList儘可能使用ArrayList(int initialCapacity) 初始化。白話：預估數組大小，可以提升程序效率，寫代碼的時候腦殼裏面要有運行的思想。想了解性能和容量評估，請參考互聯網性能與容量評估的方法論和典型案例。【推薦】使用 entrySet 遍歷 Map 類集合 KV，而不是 keySet 方式進行遍歷。說明: keySet 實際上是遍歷了 2 次，一次是轉爲 Iterator 對象，另外一次是從 hashMap 中取出 key 所對應的 value。而 entrySet 只是遍歷了一次就把 key 和 value 都放到了 entry 中，效率更高。若是是 JDK8，使用 Map.foreach 方法。正例: values()返回的是 V 值集合，是一個 list 集合對象;keySet()返回的是 K 值集合，是一個 Set 集合對象; entrySet()返回的是 K-V 值組合集合。白話：寫代碼其實就是在程序員腦殼裏執行代碼的過程，直覺就是兩次確定不如一次作完事更快。【推薦】高度注意 Map 類集合 K/V 能不能存儲 null 值的狀況，以下表格: 集合類 Key Value Super 說明 Hashtable 不容許爲 null 不容許爲 null Dictionary 線程安全 ConcurrentHashMap 不容許爲 null 不容許爲 null AbstractMap 分段鎖技術 TreeMap 不容許爲 null 容許爲 null AbstractMap 線程不安全 HashMap 容許爲 null 容許爲 null AbstractMap 線程不安全反例: 因爲 HashMap 的干擾，不少人認爲 ConcurrentHashMap 是能夠置入 null 值，注意存儲 null 值時會拋出 NPE 異常。白話：存儲null值場景很少，在防止緩存穿透的狀況下，有的時候會緩存null key 【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和不穩定性(unorder)帶來的負面影響。說明: 有序性是指遍歷的結果是按某種比較規則依次排列的。穩定性指集合每次遍歷的元素次序是必定的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort。白話：數值： HashMap map = new HashMap(); map.put(3, 3); map.put(1, 1); map.put(2, 2); map.put(4, 4);for (Entry entry : map.entrySet()) { System.out.println(entry.getKey()); } 事實證實，每次輸出也是一、二、三、4，有序而且穩定的。字符串值： HashMap map = new HashMap(); map.put("3000", "3"); map.put("1000", "1"); map.put("2000", "2"); map.put("4000", "4");for (Entry entry : map.entrySet()) { System.out.println(entry.getKey()); } 事實證實，每次輸出也是4000、1000、2000、3000，無序可是穩定的。與阿里專家諮詢，這裏HashMap不穩定性是指rehash後輸出順序則會變化。對於HashMap理論上是無序的，我作了個試驗，每次輸出都是穩定的。【參考】利用 Set 元素惟一的特性，能夠快速對一個集合進行去重操做，避免使用 List 的 contains 方法進行遍歷、對比、去重操做。白話：若是不須要精確去重，參考布隆過濾器（Bloom Filter）。 6 併發處理【強制】獲取單例對象須要保證線程安全，其中的方法也要保證線程安全。說明: 資源驅動類、工具類、單例工廠類都須要注意。白話：若是延遲加載實現的單例須要併發控制；若是初始化的時候new單例對象，自己是線程安全的，取得實例方法不須要同步。【強制】建立線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。正例: public class TimerTaskThread extends Thread { public TimerTaskThread() { super.setName("TimerTaskThread"); ... } } 白話：寫代碼的時候就要想到查bug的時候要用到什麼信息，而後決定如何命名、打印日誌等。【強制】線程資源必須經過線程池提供，不容許在應用中自行顯式建立線程。說明: 使用線程池的好處是減小在建立和銷燬線程上所花的時間以及系統資源的開銷，解決資源不足的問題。若是不使用線程池，有可能形成系統建立大量同類線程而致使消耗完內存或者「過分切換」的問題。白話：一個是使用線程池緩存線程能夠提升效率，另外線程池幫咱們作了管理線程的事情，提供了優雅關機、interrupt等待IO的線程，飽和策略等功能。【強制】線程池不容許使用 Executors 去建立，而是經過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同窗更加明確線程池的運行規則，規避資源耗盡的風險。說明: Executors 返回的線程池對象的弊端以下: 1)FixedThreadPool 和 SingleThreadPool: 容許的請求隊列長度爲 Integer.MAX_VALUE，可能會堆積大量的請求，從而致使 OOM。 2)CachedThreadPool 和 ScheduledThreadPool: 容許的建立線程數量爲 Integer.MAX_VALUE，可能會建立大量的線程，從而致使 OOM。白話：線程池若是沒有限制最大數量，線程池撐開的時候，因爲內存不夠或者系統配置的最大線程數超出，都會產生oom: unalbe to create native thread。一個組件的核心參數最好要顯式的傳入，不要默認，就像你交給屬下一個任務，任務的目標、原則、時間點、邊界都要明確，不能模糊處理同樣，省得扯皮。【強制】SimpleDateFormat 是線程不安全的類，通常不要定義爲static變量，若是定義爲 static，必須加鎖，或者使用 DateUtils 工具類。正例: ：注意線程安全，使用 DateUtils。亦推薦以下處理:： private static final ThreadLocal df = new ThreadLocal() { @Override protected DateFormat initialValue() { return new SimpleDateFormat("yyyy-MM-dd"); } }; 說明：若是是 JDK8 的應用，能夠使用 Instant 代替 Date，LocalDateTime 代替 Calendar， DateTimeFormatter 代替 Simpledateformatter，官方給出的解釋: simple beautiful strong immutable thread-safe。 ***白話：***- 記住，打死你，我也不會把SimpleDateFormat共享到類中。【強制】高併發時，同步調用應該去考量鎖的性能損耗。能用無鎖數據結構，就不要用鎖; 能鎖區塊，就不要鎖整個方法體; 能用對象鎖，就不要用類鎖。白話：優先無鎖，不用鎖能解決的必定不要用鎖，即便用鎖也要控制粒度，越細越好。【強制】對多個資源、數據庫表、對象同時加鎖時，須要保持一致的加鎖順序，不然可能會造成死鎖。說明: 線程一須要對錶 A、B、C 依次所有加鎖後才能夠進行更新操做，那麼線程二的加鎖順序也必須是 A、B、C，不然可能出現死鎖。白話：解決死鎖的方法：按順序鎖資源、超時、優先級、死鎖檢測等。可參考哲學家進餐問題學習更深刻的併發機制。【強制】併發修改同一記錄時，避免更新丟失，須要加鎖。要麼在應用層加鎖，要麼在緩存加鎖，要麼在數據庫層使用樂觀鎖，使用 version 做爲更新依據。說明: 若是每次訪問衝突機率小於 20%，推薦使用樂觀鎖，不然使用悲觀鎖。樂觀鎖的重試次數不得小於 3 次。白話：狀態流轉、維護可用餘額等最好直接利用數據庫的行級鎖，不須要顯式的加鎖。【強制】多線程並行處理定時任務時，Timer 運行多個 TimerTask 時，只要其中之一沒有捕獲拋出的異常，其它任務便會自動終止運行，使用 ScheduledExecutorService 則沒有這個問題。白話：線程執行體、任務最上層等必定要抓住Throwable並進行相應的處理，不然會使線程終止。【推薦】使用 CountDownLatch 進行異步轉同步操做，每一個線程退出前必須調用 countDown 方法，線程執行代碼注意 catch 異常，確保 countDown 方法能夠執行，避免主線程沒法執行至 await 方法，直到超時才返回結果。說明: 注意，子線程拋出異常堆棧，不能在主線程 try-catch 到。白話：請在try...finally語句裏執行countDown方法，與關閉資源相似。【推薦】避免 Random 實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一 seed 致使的性能降低。說明: Random 實例包括 java.util.Random 的實例或者 Math.random()實例。正例: 在 JDK7 以後，能夠直接使用 API ThreadLocalRandom，在 JDK7 以前，能夠作到每一個線程一個實例。白話：能夠把Random放在ThreadLocal裏，只在本線程中使用。【推薦】在併發場景下，經過雙重檢查鎖(double-checked locking)實現延遲初始化的優化問題隱患(可參考 The "Double-Checked Locking is Broken" Declaration)，推薦問題解決方案中較爲簡單一種(適用於 JDK5 及以上版本)，將目標屬性聲明爲 volatile 型。反例: class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) synchronized(this) { if (helper == null) helper = new Helper(); } return helper; } // other functions and members...} 白話：網上對雙檢鎖有N多討論，這裏很負責任的告訴你們，只要不是特別老的JDK版本(1.4如下)，雙檢鎖是沒問題的。【參考】volatile 解決多線程內存不可見問題。對於一寫多讀，是能夠解決變量同步問題，可是若是多寫，一樣沒法解決線程安全問題。若是是 count++操做，使用以下類實現: AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 若是是 JDK8，推薦使用 LongAdder 對象，比 AtomicLong 性能更好(減小樂觀鎖的重試次數)。白話： volatile只有內存可見性語義，synchronized有互斥語義，一寫多讀使用volatile就能夠，多寫就必須使用synchronized，fetch-mod-get也必須使用synchronized。【參考】 HashMap 在容量不夠進行 resize 時因爲高併發可能出現死鏈，致使 CPU 飆升，在開發過程當中注意規避此風險。白話：開發程序的時候要預估使用量，根據使用量來設置初始值。 resize須要重建hash表，嚴重影響性能，會讓程序產生長尾的響應時間。【參考】ThreadLocal 沒法解決共享對象的更新問題，ThreadLocal 對象建議使用 static 修飾。這個變量是針對一個線程內全部操做共有的，因此設置爲靜態變量，全部此類實例共享此靜態變量，也就是說在類第一次被使用時裝載，只分配一塊存儲空間，全部此類的對象(只要是這個線程內定義的)均可以操控這個變量。白話： ThreadLocal其實是一個從線程ID到變量的Map，每次取得ThreadLocal變量，其實是先取得當前線程ID，再用當前線程ID取得關聯的變量。 ThreadLocal使用了WeakHashMap，在key被回收的時候，value也被回收了，不用擔憂內存泄露。 7 控制語句【強制】在一個 switch 塊內，每一個 case 要麼經過 break/return 等來終止，要麼註釋說明程序將繼續執行到哪個 case 爲止;在一個 switch 塊內，都必須包含一個 default 語句而且放在最後，即便它什麼代碼也沒有。白話：最好每一個case都用break結束，不要組合幾個分支到一個邏輯，太不直觀。【強制】在 if/else/for/while/do 語句中必須使用大括號，即便只有一行代碼，避免使用下面的形式:if (condition) statements; 白話：這條有歧義，我的認爲有的時候就一行語句不加也能夠。【推薦】推薦儘可能少用 else， if-else 的方式能夠改寫成: if (condition) { ... return obj; }// 接着寫 else 的業務邏輯代碼; 說明: 若是非得使用if()...else if()...else...方式表達邏輯，【強制】請勿超過3層，超過請使用狀態設計模式。正例: 邏輯上超過 3 層的 if-else 代碼能夠使用衛語句，或者狀態模式來實現。白話： public void handleProcess() { // 骨架邏輯 validate(); doProcess(); declareResource(); } public double getPayAmount() { if (isDead()) return deadPayAmount(); if (isSeparated()) return separatedPayAmount(); if (isRetired()) return retiredPayAmount(); return normalPayAmount(); } 不提倡的寫法： public double getPayAmount() { if (isDead()) return deadPayAmount(); else if (isSeparated()) return separatedPayAmount(); else if (isRetired()) return retiredPayAmount(); else return normalPayAmount(); } 普及一下，以下相似排比句的代碼就是衛語句，之前天天都這麼寫可是還真是剛剛知道這叫衛語句:) 朋友說超過三層考慮狀態設計模式也不徹底正確，大概能夠理解爲多層的邏輯嵌套不是好的代碼風格，須要使用對應的重構方法作出優化，而每種壞味都有對應的優化方法和步驟，以及優缺點限制條件。寫程序必定要遵照紅花綠葉原則，主邏輯放在主方法中，這是紅花，子邏輯封裝成小方法調用，這是綠葉，不要把不一樣層次的邏輯寫在一個大方法體裏，很難理解，就像綠葉把紅花擋住了，誰還能看到。舉例說明：【推薦】除經常使用方法(如 getXxx/isXxx)等外，不要在條件判斷中執行其它複雜的語句，將復雜邏輯判斷的結果賦值給一個有意義的布爾變量名，以提升可讀性。說明: 不少 if 語句內的邏輯至關複雜，閱讀者須要分析條件表達式的最終結果，才能明確什麼樣的條件執行什麼樣的語句，那麼，若是閱讀者分析邏輯表達式錯誤呢? 正例: //僞代碼以下boolean existed = (file.open(fileName, "w") != null) && (...) || (...); if (existed) { ... } 反例: if ((file.open(fileName, "w") != null) && (...) || (...)) { ...} 白話：這個反例真的常常見到，寫這個代碼的人本身不以爲這樣很難看嗎？【推薦】循環體中的語句要考量性能，如下操做盡可能移至循環體外處理，如定義對象、變量、獲取數據庫鏈接，進行沒必要要的 try-catch 操做(這個 try-catch 是否能夠移至循環體外)。白話：切記，循環體內儘可能不要獲取資源、不要處理異常。【推薦】接口入參保護，這種場景常見的是用於作批量操做的接口。白話：用白話說，就是控制批量參數的數量，一次不能太多，不然內存溢出。【參考】方法中須要進行參數校驗的場景: 1) 調用頻次低的方法。 2) 執行時間開銷很大的方法，參數校驗時間幾乎能夠忽略不計，但若是由於參數錯誤致使中間執行回退，或者錯誤，那得不償失。 3) 須要極高穩定性和可用性的方法。 4) 對外提供的開放接口，無論是RPC/API/HTTP接口。 5) 敏感權限入口。白話：在這個框框內，根據業務適當調整是能夠的。【參考】方法中不須要參數校驗的場景: 1) 極有可能被循環調用的方法，不建議對參數進行校驗。但在方法說明裏必須註明外部參數檢查要求。 2) 底層的方法調用頻度都比較高，通常不校驗。畢竟是像純淨水過濾的最後一道，參數錯誤不太可能到底層纔會暴露問題。通常 DAO 層與 Service 層都在同一個應用中，部署在同一臺服務器中，因此 DAO 的參數校驗，能夠省略。 3) 被聲明成private只會被本身代碼所調用的方法，若是可以肯定調用方法的代碼傳入參數已經作過檢查或者確定不會有問題，此時能夠不校驗參數。白話：在這個框框呢，根據業務適當調整是能夠的。 8 註釋規約【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/*內容/格式，不得使用 //xxx 方式。說明:在 IDE 編輯窗口中，Javadoc 方式會提示相關注釋，生成 Javadoc 能夠正確輸出相應注釋; 在 IDE 中，工程調用方法時，不進入方法便可懸浮提示方法、參數、返回值的意義，提升閱讀效率。白話：開發環境編輯器可保證這一條。【強制】全部的抽象方法(包括接口中的方法)必需要用 Javadoc 註釋、除了返回值、參數、異常說明外，還必須指出該方法作什麼事情，實現什麼功能。說明: 對子類的實現要求，或者調用注意事項，請一併說明。白話：文檔還要涵蓋校驗，線程安全等，重要方法要給出調用示例。【強制】全部的類都必須添加建立者信息。白話：作好事要留名，要不誰知道是你乾的，方法可參考雷鋒，雷鋒每次作好事不留名，每次時間地點都被記下來了。【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋使用/ /註釋，注意與代碼對齊。白話：關鍵的地方作註釋，也不要太多，代碼最好是自文檔化，看代碼就能讓人理解，這是境界。【強制】全部的枚舉類型字段必需要有註釋，說明每一個數據項的用途。白話：枚舉是個很是重要的類型，業務代碼中大量存在，註釋是必須的。【推薦】與其「半吊子」英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文便可。反例:「TCP 鏈接超時」解釋成「傳輸控制協議鏈接超時」，理解反而費腦筋。白話：仍是那句話，脫了褲子放屁仍是累，又沒人感激你翻譯了。【推薦】代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。說明: 代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。白話：不少線上發生的應急事故都是技術債積累到必定程度，量變致使質變，才發生了重大的災難型事件。所以，代碼要與時俱進，代碼改變，註釋要改變，文檔要改變，要周知相關方。問題是很難實現，由於這是反人性的，作了這個事情對我的沒有什麼利益，有些人就不作，只有對代碼有潔癖的人才會這麼作。【參考】註釋掉的代碼儘可能要配合說明，而不是簡單的註釋掉。說明: 代碼被註釋掉有兩種可能性:1)後續會恢復此段代碼邏輯。2)永久不用。前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉(代碼倉庫保存了歷史代碼)。白話：儘可能不要留下注釋掉的代碼，曾經發生合併代碼的時候不當心把註釋的代碼打開了，因而，悲劇了，源代碼管理工具，例如：git、svn都有歷史記錄可查詢的，不必註釋代碼並留在源碼中。【參考】對於註釋的要求: 第1、可以準確反應設計思想和代碼邏輯;第2、可以描述業務含義，使別的程序員可以迅速瞭解到代碼背後的信息。徹底沒有註釋的大段代碼對於閱讀者形同天書，註釋是給本身看的，即便隔很長時間，也能清晰理解當時的思路;註釋也是給繼任者看的，使其可以快速接替本身的工做。白話：仍是那句話，這個是反人性的，註釋好了又有什麼用，可讓更多的人掌握個人代碼嗎？職場上彷佛不是一個好事 :)，不過專業的程序員更願意碼好每一段代碼是毋庸置疑的。【參考】好的命名、代碼結構是自解釋的，註釋力求精簡準確、表達到位。避免出現註釋的一個極端: 過多過濫的註釋，代碼的邏輯一旦修改，修改註釋是至關大的負擔。反例: // put elephant into fridge put(elephant, fridge); 方法名put，加上兩個有意義的變量名 elephant 和 fridge，已經說明了這是在幹什麼，語義清晰的代碼不須要額外的註釋。白話：寫註釋的最高境界是不用註釋，代碼一目瞭然，看了就懂。【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，經過標記掃描，常常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。 1) 待辦事宜(TODO):( 標記人，標記時間，[預計處理時間]) 表示須要實現，但目前還未實現的功能。這其實是一個 Javadoc 的標籤，目前的 Javadoc 尚未實現，但已經被普遍使用。只能應用於類，接口和方法(由於它是一個 Javadoc 標籤)。 2) 錯誤，不能工做(FIXME):(標記人，標記時間，[預計處理時間]) 在註釋中用 FIXME 標記某代碼是錯誤的，並且不能工做，須要及時糾正的狀況。白話：我很負責人的說，常用TODO和FIXME的程序員都是好程序員。 9 其餘【強制】在使用正則表達式時，利用好其預編譯功能，能夠有效加快正則匹配速度。說明: 不要在方法體內定義:Pattern pattern = Pattern.compile(規則); 白話： Pattern和Random都是線程安全的，而MessageDigest, SimpleDateFormat不是線程安全的。【強制】velocity 調用 POJO 類的屬性時，建議直接使用屬性名取值便可，模板引擎會自動按規範調用 POJO 的 getXxx()，若是是 boolean 基本數據類型變量(boolean 命名不須要加 is 前綴)，會自動調用 isXxx()方法。說明: 注意若是是 Boolean 包裝類對象，優先調用 getXxx()的方法。白話：屬性前不要加is，這類變量最好用形容詞表達。【強制】後臺輸送給頁面的變量必須加$!{var}——中間的感嘆號。說明:若是 var=null 或者不存在，那麼${var}會直接顯示在頁面上。白話：這裏說的是velocity，${var}在var爲null的時候，直接把代碼${var}打印在界面上，太不專業，也有安全問題，必須使用${var}代替。【強制】注意 Math.random() 這個方法返回是 double 類型，注意取值的範圍 0≤x小於1(可以取到零值，注意除零異常)，若是想獲取整數類型的隨機數，不要將 x 放大 10 的若干倍而後取整，直接使用 Random 對象的 nextInt 或者 nextLong 方法。白話：毋庸置疑，用專業的工具幹專業的事兒。【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime(); 說明: 若是想獲取更加精確的納秒級時間值，用 System.nanoTime()。在 JDK8 中，針對統計時間等場景，推薦使用 Instant 類。白話： Date內部也是使用System.currentTimeMillis實現的，使用Date還得多構造一個對象，在量級很大的時候會有一些性能損耗。【推薦】儘可能不要在 velocity 模板中加入變量聲明、邏輯運算符，更不要在模板中加入任何複雜的邏輯。白話： MVC！視圖的職責是展現，不要搶人家模型和控制器的活！【推薦】任何數據結構的構造或初始化，都應指定大小，避免數據結構無限增加吃光內存。白話：尤爲是集合、批量參數、數據庫表都要有最大數量的限制，不然就爲OOM埋下隱患。【推薦】對於「明確中止使用的代碼和配置」，如方法、變量、類、配置文件、動態配置屬性等要堅定從程序中清理出去，避免形成過多垃圾。白話：要保持衛生，屋子太亂了也影響生活的情趣，代碼也要按期捯飭一下。 10 總結在總結的過程當中，又對阿里的每一條規範進行了深刻的思考，並與阿里人員以及業內Java專家進行了討論，對難於理解的條目進行了說明，並進行了適當的信息補充，用白話的形式表達出來，可以感受到阿里開發規範的每一條都是線上大規模服務化系統中的踩坑指南，這和筆者正在作的事情同樣，線上出了問題會覆盤，覆盤後找到問題的緣由，總結概括，並在研發流程規範中體現解決方案和避免措施，而後推廣給開發人員，讓你們在從此的開發中垂手可得的避免犯一樣的錯誤，從而避免發生一樣的生產事故，關於生產事故，向你們推薦電影《深海浩劫》。本文爲五篇系列文章的第一篇-編程規約，後續會陸續發佈其他的文章，內容包括：異常日誌、MySQL規約、工程規約、安全規約等。做者，李豔鵬，『雲時代架構』技術社區創始人，著有《分佈式服務架構：原理、設計與實戰》與《可伸縮服務架構：框架與中間件》，現任某知名支付平臺架構組負責人，曾經在花旗銀行、甲骨文、路透社、新浪微博等大型IT互聯網公司擔任技術負責人和架構師的工做，現專一大規模高併發的線上和線下支付平臺的應用架構和技術架構的規劃與落地，負責交易、支付、渠道、出款、風控、對帳等核心支付系統的設計與實現，在移動支付、聚合支付、合規帳戶、掃碼支付、標記化支付等業務場景上有產品應用架構規劃與落地的實踐經驗。若是你也想在IT行業拿高薪，能夠參加咱們的訓練營課程，選擇最適合本身的課程學習，技術大牛親授，7個月後，進入名企拿高薪。咱們的課程內容有：Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點。若是你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優點的，想進阿里面試但擔憂面試不過的，你均可以來，羣號爲： 454377428 注：加羣要求一、具備1-5工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。 5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！ 6.小號或者小白之類加羣一概不給過，謝謝。目標已經有了，下面就看行動了！記住：學習永遠是本身的事情，你不學時間也不會多，你學了有時候卻可以使用本身學到的知識換得更多自由自在的美好時光！時間是生命的基本組成部分，也是萬物存在的根本尺度，咱們的時間在那裏咱們的生活就在那裏！咱們價值也將在那裏提高或消弭！Java程序員，加油吧