做者:李豔鵬,現任螞蟻金服高級技術專家,著有《分佈式服務架構:原理、設計與實戰》和《可伸縮服務架構:框架與中間件》,曾經在易寶支付、花旗銀行、甲骨文、新浪微博、路透社等大型IT互聯網公司擔任技術負責人和首席架構師的工做,現專一於區塊鏈平臺的研發與推廣,擅長大規模高併發的線上與線下相結合的第三方支付平臺的架構規劃與實施。java
最近,阿里巴巴發佈了《阿里巴巴Java開發手冊》,總結了阿里人多年一線實戰中積累的研發流程規範,這些流程規範在必定程度上可以保證最終的項目交付質量,經過限制開發人員的編程風格、實現方式來避免研發人員在實踐中容易犯的錯誤,一樣的問題你們使用一樣的模式解決,便於後期維護和擴展,確保最終在大規模協做的項目中達成既定目標。git
無獨有偶,筆者去年在公司裏負責升級和制定研發流程、設計模板、設計標準、代碼標準等規範,並在實際工做中進行了應用和推廣,收效頗豐,也總結了適合支付平臺的技術規範,因爲阿里巴巴Java開發手冊自己定位爲規約和規範,語言簡單、精煉,沒有太多的解讀和示例,有些條款對於通常開發人員理解起來比較困難,本文藉着阿里巴巴發佈的Java開發手冊,詳細解讀Java平臺下開發規範和標準的制定和實施,強調那些在開發過程當中須要重點關注的技術點,特別是解決某類已識別問題的模式和反模式。程序員
《阿里巴巴Java開發手冊》分爲編程規約、異常日誌、MySQL規約、工程規約、安全規約五大部分,本系列文章以這五部分主題爲主線,分爲五篇文章發佈,本文爲系列文章的第一篇-編程規約,後續會盡快發佈其他的文章。正則表達式
【強制】 代碼中的命名均不能如下劃線或美圓符號開始,也不能如下劃線或美圓符號結束。算法
反例: _name / _name / $Object / name / name$ / Object$spring
白話:數據庫
【強制】 代碼中的命名嚴禁使用拼音與英文混合的方式,更不容許直接使用中文的方式。編程
說明: 正確的英文拼寫和語法可讓閱讀者易於理解,避免歧義。注意,即便純拼音命名方式 也要避免採用。windows
反例: 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
白話:
約定俗稱的名稱或者縮寫例外。
【強制】常量命名所有大寫,單詞間用下劃線隔開,力求語義表達完整清楚,不要嫌名字長。
正例: MAX_STOCK_COUNT
反例: MAX_COUNT
白話:
【強制】抽象類命名使用 Abstract 或 Base 開頭;異常類命名使用 Exception 結尾;測試類命名以它要測試的類的名稱開始,以 Test 結尾。
白話:
【強制】中括號是數組類型的一部分,數組定義以下:String[] args;
反例: 使用String args[]的方式來定義。
白話:
這種語法編譯器也認,可是咱們畢竟寫Java程序,而不是寫C/C++程序。
【強制】POJO 類中布爾類型的變量,都不要加 is,不然部分框架解析會引發序列化錯誤。
反例: 定義爲基本數據類型Boolean isSuccess;的屬性,它的方法也是isSuccess(),RPC 框架在反向解析的時候,「覺得」對應的屬性名稱是 success,致使屬性獲取不到,進而拋出異常。
白話:
【強制】包名統一使用小寫,點分隔符之間有且僅有一個天然語義的英語單詞。包名統一使用 單數形式,可是類名若是有複數含義,類名能夠使用複數形式。
正例: 應用工具類包名爲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。
白話:
【參考】枚舉類名建議帶上 Enum 後綴,枚舉成員名稱須要全大寫,單詞間用下劃線隔開。
說明: 枚舉其實就是特殊的常量類,且構造方法被默認強制是私有。
正例: 枚舉名字:DealStatusEnum,成員名稱: SUCCESS / UNKOWN_REASON。
白話:
【參考】各層命名規約:
A) Service/DAO層方法命名規約
1) 獲取單個對象的方法用get作前綴。
2) 獲取多個對象的方法用list作前綴。
3) 獲取統計值的方法用count作前綴。
4) 插入的方法用save(推薦)或insert作前綴。
5) 刪除的方法用remove(推薦)或delete作前綴。
6) 修改的方法用update作前綴。
B) 領域模型命名規約
1) 數據對象:xxxDO,xxx即爲數據表名。
2) 數據傳輸對象:xxxDTO,xxx爲業務領域相關的名稱。
3) 展現對象:xxxVO,xxx通常爲網頁名稱。
4) POJO是DO/DTO/BO/VO的統稱,禁止命名成xxxPOJO。
白話:
【強制】不容許出現任何魔法值(即未經定義的常量)直接出如今代碼中。
反例: String key = "Id#taobao_"+tradeId; cache.put(key, value);
白話:
【強制】long 或者 Long 初始賦值時,必須使用大寫的 L,不能是小寫的 l,小寫容易跟數字 1 混淆,形成誤解。
說明: Long a = 2l; 寫的是數字的21,仍是Long型的2?
白話:
【推薦】不要使用一個常量類維護全部常量,應該按常量功能進行歸類,分開維護。如:緩存相關的常量放在類: CacheConsts 下; 系統配置相關的常量放在類: ConfigConsts 下。
說明: 大而全的常量類,非得使用查找功能才能定位到修改的常量,不利於理解和維護。
白話:
【推薦】常量的複用層次有五層: 跨應用共享常量、應用內共享常量、子工程內共享常量、包內共享常量、類內共享常量。
1) 跨應用共享常量: 放置在二方庫中,一般是client.jar中的constant目錄下。
2) 應用內共享常量: 放置在一方庫的modules中的constant目錄下。
反例: 易懂變量也要統必定義成應用內共享常量,兩位攻城師在兩個類中分別定義了表示 「是」的變量:
類A中: public static final String YES = "yes";
類B中: public static final String YES = "y"; A.YES.equals(B.YES)
,預期是 true,但實際返回爲 false,致使產生線上問題。
3) 子工程內部共享常量: 即在當前子工程的constant目錄下。
4) 包內共享常量: 即在當前包下單獨的constant目錄下。
5) 類內共享常量: 直接在類內部private static final定義。
白話:
【推薦】若是變量值僅在一個範圍內變化用 Enum 類。若是還帶有名稱以外的延伸屬性,必須 使用 Enum 類,下面正例中的數字就是延伸信息,表示星期幾。
正例: public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}
白話:
【強制】大括號的使用約定。若是是大括號內爲空,則簡潔地寫成{}便可,不須要換行; 若是 是非空代碼塊則:
1) 左大括號前不換行。
2) 左大括號後換行。
3) 右大括號前換行。
4) 右大括號後還有else等代碼則不換行;表示終止右大括號後必須換行。
白話:
【強制】 左括號和後一個字符之間不出現空格; 一樣,右括號和前一個字符之間也不出現空 格。詳見第 5 條下方正例提示。
白話:
【強制】if/for/while/switch/do 等保留字與左右括號之間都必須加空格。
白話:
【強制】任何運算符左右必須加一個空格。
說明: 運算符包括賦值運算符=、邏輯運算符&&、加減乘除符號、三目運算符等。
白話:
【強制】縮進採用 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 個,超出須要換行,換行時遵循以下原則:
1) 第二行相對第一行縮進 4 個空格,從第三行開始,再也不繼續縮進,參考示例。
2) 運算符與下文一塊兒換行。
3) 方法調用的點符號與下文一塊兒換行。
4) 在多個參數超長,逗號後進行換行。
5) 在括號前不要換行,見反例。
正例:
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 格式。
白話:
【推薦】沒有必要增長若干空格來使某一行的字符與上一行的相應字符對齊。
正例:
int a = 3; long b = 4L; float c = 5F; StringBuffer sb = new StringBuffer();
說明: 增長 sb 這個變量,若是須要對齊,則給 a、b、c 都要增長几個空格,在變量比較多的 狀況下,是一種累贅的事情。
白話:
【推薦】方法體內的執行語句組、變量的定義語句組、不一樣的業務邏輯之間或者不一樣的語義
之間插入一個空行。相同業務邏輯和語義之間不須要插入空行。
說明: 沒有必要插入多行空格進行隔開。
白話:
【強制】避免經過一個類的對象引用訪問此類的靜態變量或靜態方法,無謂增長編譯器解析成
本,直接用類名來訪問便可。
白話:
【強制】全部的覆寫方法,必須加@Override 註解。
反例:getObject()與 get0bject()的問題。一個是字母的 O,一個是數字的 0,加@Override 能夠準確判斷是否覆蓋成功。另外,若是在抽象類中對方法簽名進行修改,其實現類會立刻編譯報錯。
白話:
【強制】相同參數類型,相同業務含義,才能夠使用 Java 的可變參數,避免使用 Object。
說明: 可變參數必須放置在參數列表的最後。(提倡同窗們儘可能不用可變參數編程)
正例: public User getUsers(String type, Integer... ids)
白話:
用處不大,能夠用重載方法或者數組參數代替。
【強制】外部正在調用或者二方庫依賴的接口,不容許修改方法簽名,避免對接口調用方產生 影響。接口過期必須加@Deprecated 註解,並清晰地說明採用的新接口或者新服務是什麼。
白話:
設計時沒有考慮周全,須要改造接口,須要經過增長新接口,遷移後下線老接口的方式實現。
【強制】不能使用過期的類或方法。
說明: 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 方法進行判斷。
白話:
關於基本數據類型與包裝數據類型的使用標準以下:
1) 【強制】全部的POJO類屬性必須使用包裝數據類型。
2) 【強制】RPC方法的返回值和參數必須使用包裝數據類型。
3) 【推薦】全部的局部變量使用基本數據類型。
說明: POJO 類屬性沒有初值是提醒使用者在須要使用時,必須本身顯式地進行賦值,任何
NPE 問題,或者入庫檢查,都由使用者來保證。
正例: 數據庫的查詢結果多是 null,由於自動拆箱,用基本數據類型接收有 NPE 風險。
反例: 好比顯示成交總額漲跌狀況,即正負 x%,x 爲基本數據類型,調用的 RPC 服務,調用不成功時,返回的是默認值,頁面顯示:0%,這是不合理的,應該顯示成中劃線-。因此包裝數據類型的 null 值,可以表示額外的信息,如:遠程調用失敗,異常退出。
白話:
【強制】定義 DO/DTO/VO 等 POJO 類時,不要設定任何屬性默認值。
反例: POJO類的gmtCreate默認值爲new Date(); 可是這個屬性在數據提取時並無置入具體值,在更新其它字段時又附帶更新了此字段,致使建立時間被修改爲當前時間。
白話:
【強制】序列化類新增屬性時,請不要修改 serialVersionUID 字段,避免反序列失敗; 如 果徹底不兼容升級,避免反序列化混亂,那麼請修改 serialVersionUID 值。
說明:注意 serialVersionUID 不一致會拋出序列化運行時異常。
白話:
【強制】構造方法裏面禁止加入任何業務邏輯,若是有初始化邏輯,請放在 init 方法中。
白話:
【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具:source> generate toString 時,若是繼承了另外一個 POJO 類,注意在前面加一下 super.toString。
說明: 在方法執行拋出異常時,能夠直接調用 POJO 的 toString()方法打印其屬性值,便於排 查問題。
白話:
【推薦】使用索引訪問用 String 的 split 方法獲得的數組時,需作最後一個分隔符後有無內容的檢查,不然會有拋 IndexOutOfBoundsException 的風險。
說明:
String str = "a,b,c,,"; String[] ary = str.split(","); //預期大於 3,結果是 3 System.out.println(ary.length);
白話:
編程要留心眼,任何不肯定的地方都要判斷、處理,不然掉到坑裏了本身爬出來很費勁。
【推薦】當一個類有多個構造方法,或者多個同名方法,這些方法應該按順序放置在一塊兒, 便於閱讀。
白話:
【推薦】 類內方法定義順序依次是: 公有方法或保護方法 > 私有方法 > getter/setter
方法。
說明: 公有方法是類的調用者和維護者最關心的方法,首屏展現最好; 保護方法雖然只是子類 關心,也多是「模板設計模式」下的核心方法; 而私有方法外部通常不須要特別關心,是一個黑盒實現; 由於方法信息價值較低,全部 Service 和 DAO 的 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是線程安全的,過重。
【推薦】下列狀況,聲明成 final 會更有提示性:
1) 不須要從新賦值的變量,包括類屬性、局部變量。
2) 對象參數前加final,表示不容許修改引用的指向。
3) 類方法肯定不容許被重寫。
白話:
【推薦】慎用 Object 的 clone 方法來拷貝對象。
說明: 對象的 clone 方法默認是淺拷貝,若想實現深拷貝須要重寫 clone 方法實現屬性對象的拷貝。
白話:
【推薦】類成員與方法訪問控制從嚴:
1) 若是不容許外部直接經過new來建立對象,那麼構造方法必須是private。
2) 工具類不容許有public或default構造方法。
3) 類非static成員變量而且與子類共享,必須是protected。
4) 類非static成員變量而且僅在本類使用,必須是private。
5) 類static成員變量若是僅在本類使用,必須是private。
6) 如果static成員變量,必須考慮是否爲final。
7) 類成員方法只供類內部調用,必須是private。
8) 類成員方法只對繼承類公開,那麼限制爲protected。
說明: 任何類、方法、參數、變量,嚴控訪問範圍。過寬泛的訪問範圍,不利於模塊解耦。
思考: 若是是一個 private 的方法,想刪除就刪除,但是一個 public 的 Service 方法,或者一個 public 的成員變量,刪除一下,不得手心冒點汗嗎?變量像本身的小孩,儘可能在本身的視 線內,變量做用域太大,若是無限制的處處跑,那麼你會擔憂的。
白話:
【強制】關於 hashCode 和 equals 的處理,遵循以下規則:
1) 只要重寫equals,就必須重寫hashCode。
2) 由於Set存儲的是不重複的對象,依據hashCode和equals進行判斷,因此Set存儲的對象必須重寫這兩個方法。
3) 若是自定義對象作爲Map的鍵,那麼必須重寫hashCode和equals。
說明: String 重寫了 hashCode 和 equals 方法,因此咱們能夠很是愉快地使用 String 對象做爲 key 來使用。
白話:
【強制】ArrayList的subList結果不可強轉成ArrayList,不然會拋出ClassCastException
異常: java.util.RandomAccessSubList cannot be cast to java.util.ArrayList ;
說明: subList 返回的是 ArrayList 的內部類 SubList,並非 ArrayList ,而是 ArrayList 的一個視圖,對於SubList子列表的全部操做最終會反映到原列表上。
白話:
【強制】 在 subList 場景中,高度注意對原集合元素個數的修改,會致使子列表的遍歷、增 加、刪除均產生ConcurrentModificationException 異常。
白話:
public ArrayList(Collection<? extends E> c)
。【強制】使用集合轉數組的方法,必須使用集合的toArray(T[] array),傳入的是類型徹底 同樣的數組,大小就是 list.size()。
說明: 使用 toArray 帶參方法,入參分配的數組空間不夠大時,toArray 方法內部將從新分配內存空間,並返回新數組地址; 若是數組元素大於實際所需,下標爲[ list.size() ]的數組元素將被置爲 null,其它數組元素保持原值,所以最好將方法入參數組大小定義與集合元素個數一致。
正例:
List<String> list = new ArrayList<String>(2); list.add("guan"); list.add("bao"); String[] array = new String[list.size()]; array = list.toArray(array);
反例: 直接使用 toArray 無參方法存在問題,此方法返回值只能是 Object[]類,若強轉其它類型數組將出現 ClassCastException 錯誤。
白話:
【強制】使用工具類 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)也會隨之修改。
白話:
public ArrayList(Collection<? extends E> c)
構造器。【強制】泛型通配符<? extends T>來接收返回的數據,此寫法的泛型集合不能使用add方 法,而<? super T>不能使用get方法,作爲接口調用賦值時易出錯。
說明: 擴展說一下PECS(Producer Extends Consumer Super)原則: 1)頻繁往外讀取內容的,適合用上界 Extends。 2)常常往裏插入的,適合用下界 Super。
白話:
<? extends T>, ? 必須是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類型的數據。
<? super T>, ? 必須是T或T的父類
集合寫(add): 能夠add T或T的子類。
集合讀(get): 不能肯定從集合裏讀出的是哪一個類型(多是T也多是T的父類,或者Object),因此沒有辦法使用get。例如:List<? super Integer> foo3 = new ArrayList<Integer/Number/Object>();
只能保證get出來是Object。
下面是示例,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"; } }
【強制】不要在 foreach 循環裏進行元素的 remove/add 操做。remove 元素請使用 Iterator 方式,若是併發操做,須要對 Iterator 對象加鎖。
反例:
List<String> a = new ArrayList<String>(); a.add("1"); a.add("2"); for (String temp : a) { if ("1".equals(temp)) { a.remove(temp); } }
說明: 以上代碼的執行結果確定會出乎你們的意料,那麼試一下把「1」換成「2」,會是一樣的
結果嗎?
正例:
Iterator<String> it = a.iterator(); while (it.hasNext()) { String temp = it.next(); if (刪除元素的條件) { it.remove(); } }
白話:
【強制】 在 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<Student>() { @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 異常。
白話:
【參考】合理利用好集合的有序性(sort)和穩定性(order),避免集合的無序性(unsort)和 不穩定性(unorder)帶來的負面影響。
說明: 有序性是指遍歷的結果是按某種比較規則依次排列的。穩定性指集合每次遍歷的元素次 序是必定的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort。
白話:
數值:
HashMap<Integer, Integer> map = new HashMap<Integer, Integer>(); map.put(3, 3); map.put(1, 1); map.put(2, 2); map.put(4, 4); for (Entry<Integer, Integer> entry : map.entrySet()) { System.out.println(entry.getKey()); }
事實證實,每次輸出也是一、二、三、4,有序而且穩定的。
字符串值:
HashMap<String, String> map = new HashMap<String, String>(); map.put("3000", "3"); map.put("1000", "1"); map.put("2000", "2"); map.put("4000", "4"); for (Entry<Integer, Integer> entry : map.entrySet()) { System.out.println(entry.getKey()); }
事實證實,每次輸出也是4000、1000、2000、3000,無序可是穩定的。
與阿里專家諮詢,這裏HashMap不穩定性是指rehash後輸出順序則會變化。
【參考】利用 Set 元素惟一的特性,能夠快速對一個集合進行去重操做,避免使用 List 的 contains 方法進行遍歷、對比、去重操做。
白話:
【強制】獲取單例對象須要保證線程安全,其中的方法也要保證線程安全。
說明: 資源驅動類、工具類、單例工廠類都須要注意。
白話:
【強制】建立線程或線程池時請指定有意義的線程名稱,方便出錯時回溯。
正例:
public class TimerTaskThread extends Thread { public TimerTaskThread() { super.setName("TimerTaskThread"); ... } }
白話:
【強制】線程資源必須經過線程池提供,不容許在應用中自行顯式建立線程。
說明: 使用線程池的好處是減小在建立和銷燬線程上所花的時間以及系統資源的開銷,解決資 源不足的問題。若是不使用線程池,有可能形成系統建立大量同類線程而致使消耗完內存或者 「過分切換」的問題。
白話:
【強制】線程池不容許使用 Executors 去建立,而是經過 ThreadPoolExecutor 的方式,這樣的處理方式讓寫的同窗更加明確線程池的運行規則,規避資源耗盡的風險。
說明: Executors 返回的線程池對象的弊端以下:
1)FixedThreadPool 和 SingleThreadPool: 容許的請求隊列長度爲 Integer.MAX_VALUE,可能會堆積大量的請求,從而致使 OOM。
2)CachedThreadPool 和 ScheduledThreadPool: 容許的建立線程數量爲 Integer.MAX_VALUE,可能會建立大量的線程,從而致使 OOM。
白話:
線程池若是沒有限制最大數量,線程池撐開的時候,因爲內存不夠或者系統配置的最大線程數超出,都會產生oom: unalbe to create native thread。
正例: :注意線程安全,使用 DateUtils。亦推薦以下處理::
private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() { @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 則沒有這個問題。
白話:
【推薦】使用 CountDownLatch 進行異步轉同步操做,每一個線程退出前必須調用 countDown 方法,線程執行代碼注意 catch 異常,確保 countDown 方法能夠執行,避免主線程沒法執行至 await 方法,直到超時才返回結果。
說明: 注意,子線程拋出異常堆棧,不能在主線程 try-catch 到。
白話:
【推薦】避免 Random 實例被多線程使用,雖然共享該實例是線程安全的,但會因競爭同一 seed 致使的性能降低。
說明: Random 實例包括 java.util.Random 的實例或者 Math.random()實例。
正例: 在 JDK7 以後,能夠直接使用 API ThreadLocalRandom,在 JDK7 以前,能夠作到每一個線程一個實例。
白話:
【推薦】在併發場景下,經過雙重檢查鎖(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... }
白話:
【參考】volatile 解決多線程內存不可見問題。對於一寫多讀,是能夠解決變量同步問題, 可是若是多寫,一樣沒法解決線程安全問題。若是是 count++操做,使用以下類實現: AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 若是是 JDK8,推薦使用 LongAdder 對象,比 AtomicLong 性能更好(減小樂觀鎖的重試次數)。
白話:
【參考】 HashMap 在容量不夠進行 resize 時因爲高併發可能出現死鏈,致使 CPU 飆升,在開發過程當中注意規避此風險。
白話:
開發程序的時候要預估使用量,根據使用量來設置初始值。
【參考】ThreadLocal 沒法解決共享對象的更新問題,ThreadLocal 對象建議使用 static 修飾。這個變量是針對一個線程內全部操做共有的,因此設置爲靜態變量,全部此類實例共享此靜態變量 ,也就是說在類第一次被使用時裝載,只分配一塊存儲空間,全部此類的對象(只 要是這個線程內定義的)均可以操控這個變量。
白話:
ThreadLocal其實是一個從線程ID到變量的Map,每次取得ThreadLocal變量,其實是先取得當前線程ID,再用當前線程ID取得關聯的變量。
【強制】在一個 switch 塊內,每一個 case 要麼經過 break/return 等來終止,要麼註釋說明程序將繼續執行到哪個 case 爲止;在一個 switch 塊內,都必須包含一個 default 語句而且放在最後,即便它什麼代碼也沒有。
白話:
【強制】在 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只會被本身代碼所調用的方法,若是可以肯定調用方法的代碼傳入參數已經作過檢查或者確定不會有問題,此時能夠不校驗參數。
白話:
【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範,使用/*內容/格式,不得使用 //xxx 方式。
說明:在 IDE 編輯窗口中,Javadoc 方式會提示相關注釋,生成 Javadoc 能夠正確輸出相應注 釋; 在 IDE 中,工程調用方法時,不進入方法便可懸浮提示方法、參數、返回值的意義,提升閱讀效率。
白話:
【強制】全部的抽象方法(包括接口中的方法)必需要用 Javadoc 註釋、除了返回值、參數、 異常說明外,還必須指出該方法作什麼事情,實現什麼功能。
說明: 對子類的實現要求,或者調用注意事項,請一併說明。
白話:
【強制】全部的類都必須添加建立者信息。
白話:
【強制】方法內部單行註釋,在被註釋語句上方另起一行,使用//註釋。方法內部多行註釋
使用/ /註釋,注意與代碼對齊。
白話:
【強制】全部的枚舉類型字段必需要有註釋,說明每一個數據項的用途。
白話:
【推薦】與其「半吊子」英文來註釋,不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文便可。
反例:「TCP 鏈接超時」解釋成「傳輸控制協議鏈接超時」,理解反而費腦筋。
白話:
【推薦】代碼修改的同時,註釋也要進行相應的修改,尤爲是參數、返回值、異常、核心邏輯 等的修改。
說明: 代碼與註釋更新不一樣步,就像路網與導航軟件更新不一樣步同樣,若是導航軟件嚴重滯後, 就失去了導航的意義。
白話:
【參考】註釋掉的代碼儘可能要配合說明,而不是簡單的註釋掉。
說明: 代碼被註釋掉有兩種可能性:1)後續會恢復此段代碼邏輯。2)永久不用。前者若是沒 有備註信息,難以知曉註釋動機。後者建議直接刪掉(代碼倉庫保存了歷史代碼)。
白話:
【參考】對於註釋的要求: 第1、可以準確反應設計思想和代碼邏輯;第2、可以描述業務含義,使別的程序員可以迅速瞭解到代碼背後的信息。徹底沒有註釋的大段代碼對於閱讀者形同天書,註釋是給本身看的,即便隔很長時間,也能清晰理解當時的思路;註釋也是給繼任者看的,使其可以快速接替本身的工做。
白話:
【參考】好的命名、代碼結構是自解釋的,註釋力求精簡準確、表達到位。避免出現註釋的
一個極端: 過多過濫的註釋,代碼的邏輯一旦修改,修改註釋是至關大的負擔。
反例:
// put elephant into fridge put(elephant, fridge);
方法名put,加上兩個有意義的變量名 elephant 和 fridge,已經說明了這是在幹什麼,語
義清晰的代碼不須要額外的註釋。
白話:
【參考】特殊註釋標記,請註明標記人與標記時間。注意及時處理這些標記,經過標記掃描, 常常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。
1) 待辦事宜(TODO):( 標記人,標記時間,[預計處理時間]) 表示須要實現,但目前還未實現的功能。這其實是一個 Javadoc 的標籤,目前的 Javadoc
尚未實現,但已經被普遍使用。只能應用於類,接口和方法(由於它是一個 Javadoc 標籤)。
2) 錯誤,不能工做(FIXME):(標記人,標記時間,[預計處理時間])
在註釋中用 FIXME 標記某代碼是錯誤的,並且不能工做,須要及時糾正的狀況。
白話:
【強制】在使用正則表達式時,利用好其預編譯功能,能夠有效加快正則匹配速度。
說明: 不要在方法體內定義:Pattern pattern = Pattern.compile(規則);
白話:
【強制】velocity 調用 POJO 類的屬性時,建議直接使用屬性名取值便可,模板引擎會自動按規範調用 POJO 的 getXxx(),若是是 boolean 基本數據類型變量(boolean 命名不須要加 is 前綴),會自動調用 isXxx()方法。
說明: 注意若是是 Boolean 包裝類對象,優先調用 getXxx()的方法。
白話:
【強制】後臺輸送給頁面的變量必須加$!{var}——中間的感嘆號。 說明:若是 var=null 或者不存在,那麼${var}會直接顯示在頁面上。
白話:
【強制】注意 Math.random() 這個方法返回是 double 類型,注意取值的範圍 0≤x小於1(可以取到零值,注意除零異常),若是想獲取整數類型的隨機數,不要將 x 放大 10 的若干倍而後 取整,直接使用 Random 對象的 nextInt 或者 nextLong 方法。
白話:
【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime();
說明: 若是想獲取更加精確的納秒級時間值,用 System.nanoTime()。在 JDK8 中,針對統計時間等場景,推薦使用 Instant 類。
白話:
【推薦】儘可能不要在 velocity 模板中加入變量聲明、邏輯運算符,更不要在模板中加入任何複雜的邏輯。
白話:
【推薦】任何數據結構的構造或初始化,都應指定大小,避免數據結構無限增加吃光內存。
白話:
【推薦】對於「明確中止使用的代碼和配置」,如方法、變量、類、配置文件、動態配置屬性
等要堅定從程序中清理出去,避免形成過多垃圾。
白話:
在總結的過程當中,又對阿里的每一條規範進行了深刻的思考,並與阿里人員以及業內Java專家進行了討論,對難於理解的條目進行了說明,並進行了適當的信息補充,用白話的形式表達出來,可以感受到阿里開發規範的每一條都是線上大規模服務化系統中的踩坑指南,這和筆者正在作的事情同樣,線上出了問題會覆盤,覆盤後找到問題的緣由,總結概括,並在研發流程規範中體現解決方案和避免措施,而後推廣給開發人員,讓你們在從此的開發中垂手可得的避免犯一樣的錯誤,從而避免發生一樣的生產事故,關於生產事故,向你們推薦電影《深海浩劫》。
本文爲五篇系列文章的第一篇-編程規約,後續會陸續發佈其他的文章,內容包括:異常日誌、MySQL規約、工程規約、安全規約等。
本文歡迎轉載,轉載請註明原文連接,並附做者我的信息李豔鵬