近，阿里巴巴發布了《阿里巴巴Java開發手冊》，總結了阿里人多年一線實戰中積累的研發流程規范，這些流程規范在一定程度上能夠保證終的項目交付質量，通過限制開發人員的編程風格、實現方式來避免研發人員在實踐中容易犯的錯誤，同樣的問題大家使用同樣的模式解決，便于后期維護和擴展，確保終在大規模協作的項目中達成既定目標。
無獨有偶，筆者去年在公司里負責升級和制定研發流程、設計模板、設計標準、代碼標準等規范，并在實際工作中進行了應用和推廣，收效頗豐，也總結了適合支付平臺的技術規范，由于阿里巴巴Java開發手冊本身定位為規約和規范，語言簡單、精煉，沒有太多的解讀和示例，有些條款對于一般開發人員理解起來比較困難，本文借著阿里巴巴發布的Java開發手冊，詳細解讀Java平臺下開發規范和標準的制定和實施，強調那些在開發過程中需要重點關注的技術點，特別是解決某類已識別問題的模式和反模式。
《阿里巴巴Java開發手冊》分為編程規約、異常日志、MySQL規約、工程規約、安全規約五大部分，本系列文章以這五部分主題為主線，分為五篇文章發布，本文為系列文章的篇-編程規約，后續會盡快發布其余的文章。
【強制】 代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
反例: _name / __name /
白話：
【強制】 代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。
說明: 正確的英文拼寫和語法可以讓閱讀者易于理解，避免歧義。注意，即使純拼音命名方式 也要避免采用。
反例: 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，導致屬性獲取不到，進而拋出異常。
白話：
【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用 單數形式，但是類名如果有復數含義，類名可以使用復數形式。
正例: 應用工具類包名為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)
白話：
用處不大，可以用重載方法或者數組參數代替。
一般應用在日志的 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 方法進行判斷。
白話：
關于基本數據類型與包裝數據類型的使用標準如下:
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); 白話：
編程要留心眼，任何不確定的地方都要判斷、處理，否則掉到坑里了自己爬出來很費勁。
Java編程判空的思想要實施縈繞在每個開發人員的腦海里。
【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一起， 便于閱讀。
白話：
【推薦】 類內方法定義順序依次是: 公有方法或保護方法 > 私有方法 > 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是線程安全的，太重。
我就一直想不明白Java編譯器為什么不做個優化呢？
【推薦】下列情況，聲明成 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)構造器。
【強制】泛型通配符
【強制】獲取單例對象需要保證線程安全，其中的方法也要保證線程安全。
說明: 資源驅動類、工具類、單例工廠類都需要注意。
白話：
【強制】創建線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。
正例:
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。
一個組件的核心參數好要顯式的傳入，不要默認，就像你交給屬下一個任務，任務的目標、原則、時間點、邊界都要明確，不能模糊處理一樣，免得扯皮。
【強制】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。
白話：
【強制】高并發時，同步調用應該去考量鎖的性能損耗。能用無鎖數據結構，就不要用鎖; 能鎖區塊，就不要鎖整個方法體; 能用對象鎖，就不要用類鎖。
白話：
【強制】對多個資源、數據庫表、對象同時加鎖時，需要保持一致的加鎖順序，否則可能會造 成死鎖。
說明: 線程一需要對表 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 飆升，在開發過程中注意規避此風險。
白話：
開發程序的時候要預估使用量，根據使用量來設置初始值。
resize需要重建hash表，嚴重影響性能，會讓程序產生長尾的響應時間。
【參考】ThreadLocal 無法解決共享對象的更新問題，ThreadLocal 對象建議使用 static 修飾。這個變量是針對一個線程內所有操作共有的，所以設置為靜態變量，所有此類實例共享此靜態變量 ，也就是說在類次被使用時裝載，只分配一塊存儲空間，所有此類的對象(只 要是這個線程內定義的)都可以操控這個變量。
白話：
ThreadLocal實際上是一個從線程ID到變量的Map，每次取得ThreadLocal變量，實際上是先取得當前線程ID，再用當前線程ID取得關聯的變量。
ThreadLocal使用了WeakHashMap，在key被回收的時候，value也被回收了，不用擔心內存泄露。
【強制】在一個 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)永久不用。前者如果沒 有備注信息，難以知曉注釋動機。后者建議直接刪掉(代碼倉庫保存了歷史代碼)。
白話：
【參考】對于注釋的要求: 、能夠準確反應設計思想和代碼邏輯;第二、能夠描述業務含義，使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路;注釋也是給繼任者看的，使其能夠快速接替自己的工作。
白話：
【參考】好的命名、代碼結構是自解釋的，注釋力求精簡準確、表達到位。避免出現注釋的
一個極端: 過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔。
反例:
// 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()的方法。
白話：
【強制】后臺輸送給頁面的變量必須加
白話：
【強制】注意 Math.random() 這個方法返回是 double 類型，注意取值的范圍 0≤x<1(能夠取到零值，注意除零異常)，如果想獲取整數類型的隨機數，不要將 x 放大 10 的若干倍然后 取整，直接使用 Random 對象的 nextInt 或者 nextLong 方法。
白話：
【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime();
說明: 如果想獲取更加精確的納秒級時間值，用 System.nanoTime()。在 JDK8 中，針對統計時間等場景，推薦使用 Instant 類。
白話：
【推薦】盡量不要在 velocity 模板中加入變量聲明、邏輯運算符，更不要在模板中加入任何復雜的邏輯。
白話：
【推薦】任何數據結構的構造或初始化，都應指定大小，避免數據結構無限增長吃光內存。
白話：
【推薦】對于“明確停止使用的代碼和配置”，如方法、變量、類、配置文件、動態配置屬性
等要堅決從程序中清理出去，避免造成過多垃圾。
白話：
在總結的過程中，又對阿里的每一條規范進行了深入的思考，并與阿里人員以及業內Java專家進行了討論，對難于理解的條目進行了說明，并進行了適當的信息補充，用白話的形式表達出來，能夠感覺到阿里開發規范的每一條都是線上大規模服務化系統中的踩坑指南，這和筆者正在做的事情一樣，線上出了問題會復盤，復盤后找到問題的原因，總結歸納，并在研發流程規范中體現解決方案和避免措施，然后推廣給開發人員，讓大家在今后的開發中輕而易舉的避免犯同樣的錯誤，從而避免發生同樣的生產事故，關于生產事故，向大家推薦電影《深海浩劫》。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
