【強制】 程式碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
反例: _name / __name / $Object / name_ / name$ / Object$
【強制】 程式碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。 說明:正確的英文拼寫和語法可以讓閱讀者易於理解，避免歧義。注意，即使純拼音命名方式 也要避免採用。
反例: DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變數 = 3 正例: alibaba / taobao / youku / hangzhou 等國際通用的名稱，可視同英文。
【強制】類名使用 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[]的方式來定義。
【強制】POJO 類中布爾型別的變數，都不要加 is，否則部分框架解析會引起序列化錯誤。 反例:定義爲基本數據型別boolean isSuccess;的屬性，它的方法也是isSuccess()，RPC 框架在反向解析的時候，「以爲」對應的屬性名稱是 success，導致屬性獲取不到，進而拋出異 常。
【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語意的英語單詞。包名統一使用 單數形式，但是類名如果有複數含義，類名可以使用複數形式。
正例: 應用工具類包名爲com.alibaba.open.util、類名爲MessageUtils(此規則參考 spring 的框架結構)
【強制】杜絕完全不規範的縮寫，避免望文不知義。
反例: AbstractClass「縮寫」命名成 AbsClass;condition「縮寫」命名成 condi，此類 隨意縮寫嚴重降低了程式碼的可閱讀性。
【推薦】如果使用到了設計模式，建議在類名中體現出具體模式。 說明:將設計模式體現在名字中，有利於閱讀者快速理解架構設計思想。 正例: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 的後綴與介面區別。 正例:CacheService((add))Impl 實現 CacheService 介面。
2)【推薦】 如果是形容能力的介面名稱，取對應的形容詞做介面名(通常是–able 的形式)。 正例:AbstractTranslator 實現 Translatable。
【參考】列舉類名建議帶上 Enum 後綴，列舉元名稱需要全大寫，單詞間
用下劃線隔開。 說明:列舉其實就是特殊的常數類，且構造方法被預設強制是私有。 正例:列舉名字:DealStatusEnum，成員名稱:SUCCESS / UNKOWN_REASON。
【參考】各層命名規約:
A) Service/DAO層方法命名規約
1) 獲取單個物件的方法用get做字首。
2) 獲取多個物件的方法用list做字首。
3) 獲取統計值的方法用count做字首。
4) 插入的方法用save做字首。
5) 刪除的方法用remove做字首。
6) 修改的方法用update做字首。
B) 領域模型命名規約
1) 數據物件:xxxDO，xxx即爲數據表名。
2) 數據傳輸物件:xxxDTO，xxx爲業務領域相關的名稱。
3) 展示物件:xxxVO，xxx一般爲網頁名稱。
4) POJO是DO/DTO/BO/VO的統稱，禁止命名成xxxPOJO。
(二)常數定義
1. 【強制】不允許出現任何魔法值(即未經定義的常數)直接出現在程式碼中。 反例: String key="Id#taobao_"+tradeId;
cache.put(key, value);
2. 【強制】long 或者 Long 初始賦值時，必須使用大寫的 L，不能是小寫的 l，小寫容易跟數位 1 混淆，造成誤解。
說明:Long a = 2l; 寫的是數位的 21，還是 Long 型的 2?
3. 【推薦】不要使用一個常數類維護所有常數，應該按常數功能進行歸類，分開維護。如:快取 相關的常數放在類:CacheConsts 下;系統設定相關的常數放在類:ConfigConsts 下。
說明:大而全的常數類，非得使用查詢功能才能 纔能定位到修改的常數，不利於理解和維護
4. 【推薦】常數的複用層次有五層:跨應用共用常數、應用內共用常數、子工程內共用常數、包 內共用常數、類內共用常數。
1) 跨應用共用常數:放置在二方庫中，通常是client.jar中的constant目錄下。
反例:易懂變數也要統一定義成應用內共用常數，兩位攻城師在兩個類中分別定義 了 表示「是」的變數:
類 A 中:public static final String YES = "yes";
類 B 中:public static final String YES = "y"; A.YES.equals(B.YES)，預期是 true，但實際返回爲 false，導致產生線上問題。
2) 應用內共用常數:放置在一方庫的modules中的constant目錄下。
3) 子工程內部共用常數:即在當前子工程的constant目錄下。
4) 包內共用常數:即在當前包下單獨的constant目錄下。
5) 類內共用常數:直接在類內部private static final定義。
5. 【推薦】如果變數值僅在一個範圍內變化用 Enum 類。如果還帶有名稱之外的延伸屬性，必須使用 Enum 類，下面 下麪正例中的數位就是延伸資訊，表示星期幾。
正例:public Enum{ MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}
1.【強制】大括號的使用約定。如果是大括號內爲空，則簡潔地寫成{}即可，不需要換行;如果 是非空程式碼塊則:
1) 左大括號前不換行。
2) 左大括號後換行。
3) 右大括號前換行。
4) 右大括號後還有else等程式碼則不換行;表示終止右大括號後必須換行。
2.【強制】 左括號和後一個字元之間不出現空格;同樣，右括號和前一個字元之間也不出現空 格。詳見第 5 條下方正例 示。
3.【強制】if/for/while/switch/do 等保留字與左右括號之間都必須加空格。
4.【強制】任何運算子左右必須加一個空格。
說明:運算子包括賦值運算子=、邏輯運算子&&、加減乘除符號、三目執行符等。
5.【強制】縮排採用 4 個空格，禁止使用 tab 字元。
說明:如果使用 tab 縮排，必須設定 1 個 tab 爲 4 個空格。IDEA 設定 tab 爲 4 個空格時， 請勿勾選 Use tab character
6. 【強制】單行字元數限制不超過 120 個，超出需要換行，換行時遵循如下原則:
1) 第二行相對第一行縮排 4 個空格，從第三行開始，不再繼續縮排，參考範例。
2) 運算子與下文一起換行。
3) 方法呼叫的點符號與下文一起換行。
4) 在多個參數超長，逗號後進行換行。
5) 在括號前不要換行，見反例。
7. 【強制】方法參數在定義和傳入時，多個參數逗號後邊必須加空格。
正例:下例中實參的"a",後邊必須要有一個空格。 method("a", "b", "c");
8.【強制】IDE的text file encoding設定爲UTF-8; IDE中檔案的換行符使用Unix格式， 不要使用 windows 格式。
9. 【推薦】沒有必要增加若幹空格來使某一行的字元與上一行的相應字元對齊。 正例:
int a=3;
long b=4L;
float c = 5F;
StringBuffer sb = new StringBuffer();
說明:增加 sb 這個變數，如果需要對齊，則給 a、b、c 都要增加幾個空格，在變數比較多的 情況下，是一種累贅的事情。
10. 【推薦】方法體內的執行語句組、變數的定義語句組、不同的業務邏輯之間或者不同的語意之間插入一個空行。相同業務邏輯和語意之間不需要插入空行。
說明:沒有必要插入多行空格進行隔開。
1.【強制】避免通過一個類的物件參照存取此類的靜態變數或靜態方法，無謂增加編譯器解析成 本，直接用類名來存取即可。
2.【強制】所有的覆寫方法，必須加@Override 註解。
反例:getObject()與 get0bject()的問題。一個是字母的 O，一個是數位的 0，加@Override 可以準確判斷是否覆蓋成功。另外，如果在抽象類中對方法簽名進行修改，其實現類會馬上編譯報錯。
3.【強制】相同參數型別，相同業務含義，纔可以使用 Java 的可變參數，避免使用 Object。 說明:可變參數必須放置在參數列表的最後。( 倡同學們儘量不用可變參數程式設計)
正例:public User getUsers(String type, Integer... ids)
4.【強制】對外暴露的介面簽名，原則上不允許修改方法簽名，避免對介面呼叫方產生影響。介面過時必須加@Deprecated 註解，並清晰地說明採用的新介面或者新服務是什麼。
5.【強制】不能使用過時的類或方法。
說明:java.net.URLDecoder 中的方法decode(StringencodeStr) 這個方法已經過時，應 該使用雙參數decode(String source, String encode)。介面 供方既然明確是過時介面， 那麼有義務同時 供新的介面;作爲呼叫方來說，有義務去考證過時方法的新實現是什麼。
6.【強制】Object 的 equals 方法容易拋空指針異常，應使用常數或確定有值的物件來呼叫 equals。
正例: "test".equals(object);
反例: object.equals("test"); 說明:推薦使用java.util.Objects#equals (JDK7引入的工具類)
7.【強制】所有的相同類型的包裝類物件之間值的比較，全部使用 equals 方法比較。
說明:對於Integer var=?在-128至127之間的賦值，Integer物件是在 IntegerCache.cache產生，會複用已有物件，這個區間內的Integer值可以直接使用==進行 判斷，但是這個區間之外的所有數據，都會在堆上產生，並不會複用已有物件，這是一個大坑， 推薦使用 equals 方法進行判斷。
8. 【強制】關於基本數據型別與包裝數據型別的使用標準如下:
1) 所有的POJO類屬性必須使用包裝數據型別。
2) RPC方法的返回值和參數必須使用包裝數據型別。
3) 所有的區域性變數【推薦】使用基本數據型別。
說明:POJO 類屬性沒有初值是提醒使用者在需要使用時，必須自己顯式地進行賦值，任何NPE 問題，或者入庫檢查，都由使用者來保證。
正例:數據庫的查詢結果可能是 null，因爲自動拆箱，用基本數據型別接收有 NPE 風險。
反例:比如顯示成交總額漲跌情況，即正負 x%，x 爲基本數據型別，呼叫的 RPC 服務，呼叫不成功時，返回的是預設值，頁面顯示:0%，這是不合理的，應該顯示成中劃線-。所以包裝 數據型別的 null 值，能夠表示額外的資訊，如:遠端呼叫失敗，異常退出。
9. 【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性預設值。
反例:POJO類的gmtCreate預設值爲new Date();但是這個屬性在數據取時並沒有置入具體值，在更新其它欄位時又附帶更新了此欄位，導致建立時間被修改成當前時間。
10. 【強制】序列化類新增屬性時，請不要修改 serialVersionUID 欄位，避免反序列失敗;如 果完全不相容升級，避免反序列化混亂，那麼請修改 serialVersionUID 值。
說明:注意 serialVersionUID 不一致會拋出序列化執行時異常。
11. 【強制】構造方法裏面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
12. 【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具:source> generate toString 時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。
說明:在方法執行拋出異常時，可以直接呼叫 POJO 的 toString()方法列印其屬性值，便於排查問題。
13. 【推薦】使用索引存取用 String 的 split 方法得到的陣列時，需做最後一個分隔符後有無內容的檢查，否則會有拋 IndexOutOfBoundsException 的風險。
說明:String str = "a,b,c,,"; String[] ary = str.split(","); //預期大於 3，結果是 3 System.out.println(ary.length);
14. 【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一起，便於閱讀。
15.【推薦】 類內方法定義順序依次是:公有方法或保護方法 > 私有方法 > getter/setter方法。
說明:公有方法是類的呼叫者和維護者最關心的方法，首屏展示最好;保護方法雖然只是子類 關心，也可能是「模板設計模式」下的核心方法;而私有方法外部一般不需要特別關心，是一個 黑盒實現;因爲方法資訊價值較低，所有 Service 和 DAO 的 getter/setter 方法放在類體最 後。
16. 【推薦】setter 方法中，參數名稱與類成員變數名稱一致，this.成員名=參數名。在getter/setter 方法中，儘量不要增加業務邏輯，增加排查問題的難度。
17. 【推薦】回圈體內，字串的聯接方式，使用 StringBuilder 的 append 方法進行擴充套件。
說明:反編譯出的位元組碼檔案顯示每次回圈都會 new 出一個 StringBuilder 物件，然後進行 append 操作，最後通過 toString 方法返回 String 物件，造成記憶體資源浪費。
18. 【推薦】final 可提高程式響應效率，宣告成 final 的情況:
1) 不需要重新賦值的變數，包括類屬性、區域性變數。
2) 物件參數前加final，表示不允許修改參照的指向。
3) 類方法確定不允許被重寫。
19. 【推薦】慎用 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 的成員變數，刪除一下，不得手心冒點汗嗎?變數像自己的小孩，儘量在自己的視 線內，變數作用域太大，如果無限制的到處跑，那麼你會擔心的。
1.【強制】關於 hashCode 和 equals 的處理，遵循如下規則:
1) 只要重寫equals，就必須重寫hashCode。
2) 因爲Set儲存的是不重複的物件，依據hashCode和equals進行判斷，所以Set儲存的 物件必須重寫這兩個方法。
3) 如果自定義物件做爲Map的鍵，那麼必須重寫hashCode和equals。
正例:String 重寫了 hashCode 和 equals 方法，所以我們可以非常愉快地使用 String 物件 作爲 key 來使用。
2.【強制】ArrayList的subList結果不可強轉成ArrayList，否則會拋出ClassCastException 異常:java.util.RandomAccessSubList cannot be cast to java.util.ArrayList ; 說明:subList 返回的是 ArrayList 的內部類 SubList，並不是 ArrayList ，而是 ArrayList 的一個檢視，對於SubList子列表的所有操作最終會反映到原列表上。
3.【強制】 在 subList 場景中，高度注意對原集合元素個數的修改，會導致子列表的遍歷、增 加、刪除均產生ConcurrentModificationException 異常。
4.【強制】使用集合轉陣列的方法，必須使用集合的 toArray(T[] array)，傳入的是型別完全 一樣的陣列，大小就是 list.size()。
反例:直接使用 toArray 無參方法存在問題，此方法返回值只能是 Object[]類，若強轉其它 型別陣列將出現 ClassCastException 錯誤。
正例:
List<String> list = new ArrayList<String>(2); list.add("guan");
list.add("bao");
String[] array = new String[list.size()]; array = list.toArray(array);
說明:使用 toArray 帶參方法，入參分配的陣列空間不夠大時，toArray 方法內部將重新分配 記憶體空間，並返回新陣列地址;如果陣列元素大於實際所需，下標爲[ list.size() ]的陣列 元素將被置爲 null，其它陣列元素保持原值，因此最好將方法入參數組大小定義與集合元素 個數一致。
5.【強制】使用工具類 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)也會隨之修改。
6.【強制】泛型萬用字元<? extends T>來接收返回的數據，此寫法的泛型集合不能使用 add 方法。
說明:蘋果裝箱後返回一個<? extends Fruits>物件，此物件就不能往裏加任何水果，包括 蘋果。
7.【強制】不要在 foreach 回圈裡進行元素的 remove/add 操作。remove 元素請使用 Iterator方式，如果併發操作，需要對 Iterator 物件加鎖。
8. 【強制】在 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;
}
}
9.【推薦】集合初始化時，儘量指定集合初始值大小。
說明:ArrayList儘量使用ArrayList(int initialCapacity) 初始化。
10. 【推薦】使用 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 值組合集合。
11. 【推薦】高度注意 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 異常。
12. 【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和 不穩定性(unorder)帶來的負面影響。 說明:穩定性指集合每次遍歷的元素次序是一定的。有序性是指遍歷的結果是按某種比較規則 依次排列的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort。
13. 【參考】利用 Set 元素唯一的特性，可以快速對一個集合進行去重操作，避免使用 List 的 contains 方法進行遍歷、對比、去重操作。
(六)併發處理
1. 【強制】獲取單例物件需要保證執行緒安全，其中的方法也要保證執行緒安全。
說明:資源驅動類、工具類、單例工廠類都需要注意。
2. 【強制】建立執行緒或執行緒池時請指定有意義的執行緒名稱，方便出錯時回溯。
正例:
public class TimerTaskThread extends Thread { public TimerTaskThread(){
super.setName("TimerTaskThread"); ... }
3.【強制】執行緒資源必須通過執行緒池 供，不允許在應用中自行顯式建立執行緒。
說明:使用執行緒池的好處是減少在建立和銷燬執行緒上所花的時間以及系統資源的開銷，解決資 源不足的問題。如果不使用執行緒池，有可能造成系統建立大量同類執行緒而導致消耗完記憶體或者 「過度切換」的問題。
5.【強制】執行緒池不允許使用 Executors 去建立，而是通過 ThreadPoolExecutor 的方式，這樣 的處理方式讓寫的同學更加明確執行緒池的執行規則，規避資源耗盡的風險。 說明:Executors 返回的執行緒池物件的弊端如下:
1)FixedThreadPool 和 SingleThreadPool:
允許的請求佇列長度爲 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。
2)CachedThreadPool 和 ScheduledThreadPool:
允許的建立執行緒數量爲 Integer.MAX_VALUE，可能會建立大量的執行緒，從而導致 OOM。
5.【強制】SimpleDateFormat 是執行緒不安全的類，一般不要定義爲static變數，如果定義爲
static，必須加鎖，或者使用 DateUtils 工具類。
正例:注意執行緒安全，使用 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。
6.【強制】高併發時，同步呼叫應該去考量鎖的效能損耗。能用無鎖數據結構，就不要用鎖;能 鎖區塊，就不要鎖整個方法體;能用物件鎖，就不要用類鎖。
7.【強制】對多個資源、數據庫表、物件同時加鎖時，需要保持一致的加鎖順序，否則可能會造 成死鎖。
說明:執行緒一需要對錶 A、B、C 依次全部加鎖後纔可以進行更新操作，那麼執行緒二的加鎖順序 也必須是 A、B、C，否則可能出現死鎖。
8.【強制】併發修改同一記錄時，避免更新丟失，要麼在應用層加鎖，要麼在快取加鎖，要麼在 數據庫層使用樂觀鎖，使用 version 作爲更新依據。
說明:如果每次存取衝突概率小於 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次 數不得小於 3 次。
9.【強制】多執行緒並行處理定時任務時，Timer 執行多個 TimeTask 時，只要其中之一沒有捕獲 拋出的異常，其它任務便會自動終止執行，使用 ScheduledExecutorService 則沒有這個問題。
10. 【推薦】使用 CountDownLatch 進行非同步轉同步操作，每個執行緒退出前必須呼叫 countDown方法，執行緒執行程式碼注意 catch 異常，確保 countDown 方法可以執行，避免主執行緒無法執行 至 countDown 方法，直到超時才返回結果。 說明:注意，子執行緒拋出異常堆疊，不能在主執行緒 try-catch 到。
11. 【推薦】避免 Random 範例被多執行緒使用，雖然共用該範例是執行緒安全的，但會因競爭同一 seed 導致的效能下降。
說明:Random 範例包括 java.util.Random 的範例或者 Math.random()範例。
正例:在 JDK7 之後，可以直接使用 API ThreadLocalRandom，在 JDK7 之前，可以做到每個 執行緒一個範例。
12.【推薦】通過雙重檢查鎖(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...
}
13. 【參考】volatile 解決多執行緒記憶體不可見問題。對於一寫多讀，是可以解決變數同步問題， 但是如果多寫，同樣無法解決執行緒安全問題。如果是 count++操作，使用如下類實現: AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推 薦使用 LongAdder 物件，比 AtomicLong 效能更好(減少樂觀鎖的重試次數)。
14. 【參考】 HashMap 在容量不夠進行 resize 時由於高併發可能出現死鏈，導致 CPU 飆升，在 開發過程中注意規避此風險。
15. 【參考】ThreadLocal 無法解決共用物件的更新問題，ThreadLocal 物件建議使用 static 修飾。這個變數是針對一個執行緒內所有操作共有的，所以設定爲靜態變數，所有此類範例共用 此靜態變數 ，也就是說在類第一次被使用時裝載，只分配一塊儲存空間，所有此類的物件(只 要是這個執行緒內定義的)都可以操控這個變數。
【強制】在一個 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 程式碼可以使用衛語句，或者狀態模式來實現。
【推薦】除常用方法(如 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) 敏感許可權入口。
8. 【參考】方法中不需要參數校驗的場景:
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，已經說明了這是在幹什麼，語意清晰的程式碼不需要額外的註釋。
11.【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，通過標記掃 ， 經常清理此類標記。線上故障有時候就是來源於這些標記處的程式碼。
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 類。
【推薦】儘量不要在 vm 中加入變數宣告、邏輯運算子，更不要在 vm 模板中加入任何複雜的邏 輯。
【推薦】任何數據結構的構造或初始化，都應指定大小，避免數據結構無限增長吃光記憶體。
【推薦】對於「明確停止使用的程式碼和設定」，如方法、變數、類、組態檔、動態設定屬性等要堅決從程式中清理出去，避免造成過多垃圾。
【強制】不要捕獲 Java 類庫中定義的繼承自 RuntimeException 的執行時異常類，如: IndexOutOfBoundsException / NullPointerException，這類異常由程式設計師預檢查 來規避，保證程式健壯性。
正例:if(obj != null) {...}
反例:try { obj.method() } catch(NullPointerException e){...}
【強制】異常不要用來做流程控制，條件控制，因爲異常的處理效率比條件分支低。
【強制】對大段程式碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定程式碼和非穩 定程式碼，穩定程式碼指的是無論如何不會出錯的程式碼。對於非穩定程式碼的catch儘可能進行區分 異常型別，再做對應的例外處理。
【強制】捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請 將該異常拋給它的呼叫者。最外層的業務使用者，必須處理異常，將其轉化爲使用者可以理解的 內容。
【強制】有 try 塊放到了事務程式碼中，catch 異常後，如果需要回滾事務，一定要注意手動回 滾事務。
【強制】finally 塊必須對資源物件、流物件進行關閉，有異常也要做 try-catch。 說明:如果 JDK7，可以使用 try-with-resources 方式。
【強制】不能在 finally 塊中使用 return，finally 塊中的 return 返回後方法結束執行，不 會再執行 try 塊中的 return 語句。
【強制】捕獲異常與拋異常，必須是完全匹配，或者捕獲異常是拋異常的父類別。 說明:如果預期對方拋的是繡球，實際接到的是鉛球，就會產生意外情況。
【推薦】方法的返回值可以爲 null，不強制返回空集合，或者空物件等，必須新增註 加注釋充分 說明什麼情況下會返回 null 值。呼叫方需要進行 null 判斷防止 NPE 問題。 說明:本規約明確防止 NPE 是呼叫者的責任。即使被呼叫方法返回空集合或者空物件，對呼叫 者來說，也並非高枕無憂，必須考慮到遠端呼叫失敗，執行時異常等場景返回 null 的情況。
10. 【推薦】防止 NPE，是程式設計師的基本修養，注意 NPE 產生的場景:
1) 返回型別爲包裝數據型別，有可能是null，返回int值時注意判空。
反例:public int f(){ return Integer 物件}; 如果爲 null，自動解箱拋 NPE。
2) 數據庫的查詢結果可能爲null。
3) 集合裡的元素即使isNotEmpty，取出的數據元素也可能爲null。
4) 遠端呼叫返回物件，一律要求進行NPE判斷。
5) 對於Session中獲取的數據，建議NPE檢查，避免空指針。
6) 級聯呼叫obj.getA().getB().getC();一連串呼叫，易產生NPE。
11. 【推薦】在程式碼中使用「拋異常」還是「返回錯誤碼」，對於公司外的 http/api 開放介面必須 使用「錯誤碼」;而應用內部推薦異常拋出;跨應用間 RPC 呼叫優先考慮使用 Result 方式，封 裝 isSuccess、「錯誤碼」、「錯誤簡簡訊息」。
說明:關於 RPC 方法返回方式使用 Result 方式的理由:
1)使用拋異常返回方式，呼叫方如果沒有捕獲到就會產生執行時錯誤。
2)如果不加棧資訊，只是new自定義異常，加入自己的理解的error message，對於呼叫 端解決問題的幫助不會太多。如果加了棧資訊，在頻繁呼叫出錯的情況下，數據序列化和傳輸 的效能損耗也是問題。
12.【推薦】定義時區分unchecked/checked 異常，避免直接使用RuntimeException拋出， 更不允許拋出 Exception 或者 Throwable，應使用有業務含義的自定義異常。推薦業界已定義 過的自定義異常，如:DAOException / ServiceException 等。
13.【參考】避免出現重複的程式碼(Don’t Repeat Yourself)，即DRY原則。 說明:隨意複製和貼上程式碼，必然會導致程式碼的重複，在以後需要修改時，需要修改所有的副 本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是共用模組。 正例:一個類中有多個 public 方法，都需要進行數行相同的參數校驗操作，這個時候請抽取:
private boolean checkParam(DTO dto){...}
1. 【強制】應用中不可直接使用日誌系統(Log4j、Logback)中的 API，而應依賴使用日誌框架
2. 【強制】日誌檔案推薦至少儲存 15 天，因爲有些異常具備以「周」爲頻次發生的特點。
3. 【強制】應用中的擴充套件日誌(如打點、臨時監控、存取日誌等)命名方式: appName_logType_logName.log。logType:日誌型別，推薦分類有 stats/desc/monitor/visit 等;logName:日誌 述。這種命名的好處:通過檔名就可知 道日誌檔案屬於什麼應用，什麼型別，什麼目的，也有利於歸類查詢。
正例:mppserver 應用中單獨監控時區轉換異常，如: mppserver_monitor_timeZoneConvert.log 說明:推薦對日誌進行分類，錯誤日誌和業務日誌儘量分開存放，便於開發人員檢視，也便於 通過日誌對系統進行及時監控。
4.【強制】對 trace/debug/info 級別的日誌輸出，必須使用條件輸出形式或者使用佔位符的方式。
說明:logger.debug("Processing trade with id: " + id + " symbol: " + symbol); 如果日誌級別是 warn，上述日誌不會列印，但是會執行字串拼接操作，如果 symbol 是物件， 會執行 toString()方法，浪費了系統資源，執行了上述操作，最終日誌卻沒有列印。 正例:(條件)
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
}
正例:(佔位符)
logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);
5.【強制】避免重複列印日誌，浪費磁碟空間，務必在 log4j.xml 中設定 additivity=false。 正例:<logger name="com.taobao.dubbo.config" additivity="false">
6.【強制】異常資訊應該包括兩類資訊:案發現場資訊和異常堆疊資訊。如果不處理，那麼往上 拋。
正例:logger.error(各類參數或者物件 toString + "_" + e.getMessage(), e);
7.【推薦】可以使用 warn 日誌級別來記錄使用者輸入參數錯誤的情況，避免使用者投訴時，無所適 從。注意日誌輸出的級別，error 級別只記錄系統邏輯出錯、異常等重要的錯誤資訊。如非必 要，請不要在此場景打出 error 級別。
8.【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌;有選擇地輸出 info 日誌;如果使 用 warn 來記錄剛上線時的業務行爲資訊，一定要注意日誌輸出量的問題，避免把伺服器磁碟 撐爆，並記得及時刪除這些觀察日誌。
說明:大量地輸出無效日誌，不利於系統效能 升，也不利於快速定位錯誤點。記錄日誌時請 思考:這些日誌真的有人看嗎?看到這條日誌你能做什麼?能不能給問題排查帶來好處?
1.【推薦】圖中預設上層依賴於下層，箭頭關係表示可直接依賴，如:開放介面層可以依賴於Web 層，也可以直接依賴於 Service 層，依此類推:
開放介面層:可直接封裝 Service 介面暴露成 RPC 介面;通過 Web 封裝成 http 介面;閘道器控 制層等。
終端顯示層:各個端的模板渲染並執行顯示層。當前主要是 velocity 渲染，JS 渲染，JSP 渲 染，行動端展示層等。
Web 層:主要是對存取控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
Service 層:相對具體的業務邏輯服務層。
Manager 層:通用業務處理層，它有如下特徵:
1) 對第三方平臺封裝的層，預處理返回結果及轉化異常資訊;
2) 對Service層通用能力的下沉，如快取方案、中介軟體通用處理; 3) 與DAO層互動，對DAO的業務通用能力的封裝。
DAO 層:數據存取層，與底層 MySQL、Oracle、Hbase 進行數據互動。
外部介面或第三方平臺:包括其它部門 RPC 開放介面，基礎平臺，其它公司的 HTTP 介面。
2. 【參考】 (分層例外處理規約)在 DAO 層，產生的異常型別有很多，無法用細粒度異常進行 catch，使用 catch(Exception e)方式，並 throw new DAOException(e)，不需要列印日誌， 因爲日誌在 Manager/Service 層一定需要捕獲並打到日誌檔案中去，如果同台伺服器再打日 志，浪費效能和儲存。在 Service 層出現異常時，必須記錄日誌資訊到磁碟，儘可能帶上參數 資訊，相當於保護案發現場。如果 Manager 層與 Service 同機部署，日誌方式與 DAO 層處理 一致，如果是單獨部署，則採用與 Service 一致的處理方式。Web 層絕不應該繼續往上拋異常， 因爲已經處於頂層，無繼續處理異常的方式，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，儘量加上友好的錯誤 示資訊。開放介面層要將異常處 理成錯誤碼和錯誤資訊方式返回。
3. 【參考】分層領域模型規約
【強制】定義 GAV 遵從以下規則:
1) GroupID格式:com.{公司/BU }.業務線.[子業務線]，最多4級。
說明:{公司/BU} 例如:alibaba/taobao/tmall/aliexpress 等 BU 一級;子業務線可選。
正例:com.taobao.jstorm 或 com.alibaba.dubbo.register
2) ArtifactID格式:產品線名-模組名。語意不重複不遺漏，先到倉庫中心去查證一下。
正例:dubbo-client / fastjson-api / jstorm-tool 3) Version:詳細規定參考下方。
【強制】二方庫版本號命名方式:主版本號.次版本號.修訂號
1) 主版本號:當做了不相容的API 修改，或者增加了能改變產品方向的新功能。 2) 次版本號:當做了向下相容的功能性新增(新增類、介面等)。
3) 修訂號:修復 bug，沒有修改方法簽名的功能加強，保持 API 相容性。
說明:起始版本號必須爲:1.0.0，而不是 0.0.1
【強制】線上應用不要依賴 SNAPSHOT 版本(安全包除外);正式發佈的類庫必須使用 RELEASE 版本號升級+1 的方式，且版本號不允許覆蓋升級，必須去中央倉庫進行查證。
說明:不依賴 SNAPSHOT 版本是保證應用發佈的冪等性。另外，也可以加快編譯時的打包構建。
【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變， 必須明確評估和驗證，建議進行 dependency:resolve 前後資訊比對，如果仲裁結果完全不一 致，那麼通過 dependency:tree 命令，找出差異點，進行<excludes>排除 jar 包。
【強制】二方庫裡可以定義列舉型別，參數可以使用列舉型別，但是介面返回值不允許使用枚 舉型別或者包含列舉型別的 POJO 物件。
6. 【強制】依賴於一個二方庫羣時，必須定義一個統一版本變數，避免版本號不一致。
說明:依賴 springframework-core,-context,-beans，它們都是同一個版本，可以定義一 個變數來儲存版本:${spring.version}，定義依賴的時候，參照該版本。
7. 【強制】禁止在子專案的 pom 依賴中出現相同的 GroupId，相同的 ArtifactId，但是不同的 Version。
說明:在本地偵錯時會使用各子專案指定的版本號，但是合併成一個 war，只能有一個版本號 出現在最後的 lib 目錄中。曾經出現過線下偵錯是正確的，發佈到線上出故障的先例。
8. 【推薦】所有 pom 檔案中的依賴宣告放在<dependencies>語句塊中，所有版本仲裁放在 <dependencyManagement>語句塊中。 說明:<dependencyManagement>裡只是宣告版本，並不實現引入，因此子專案需要顯式的聲 明依賴，version 和 scope 都讀取自父 pom。而<dependencies>所有宣告在主 pom 的 <dependencies>裡的依賴都會自動引入，並預設被所有的子專案繼承。
9. 【推薦】二方庫儘量不要有設定項，最低限度不要再增加設定項。
10. 【參考】爲避免應用二方庫的依賴衝突問題，二方庫發佈者應當遵循以下原則: 1)精簡可控原則。移除一切不必要的 API 和依賴，只包含 Service API、必要的領域模型對 象、Utils 類、常數、列舉等。如果依賴其它二方庫，儘量是 provided 引入，讓二方庫使用 者去依賴具體版本號;無 log 具體實現，只依賴日誌框架。 2)穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，原始碼在哪裏，都需要能 方便查到。除非使用者主動升級版本，否則公共二方庫的行爲不應該發生變化。
1. 【推薦】高併發伺服器建議調小 TCP 協定的 time_wait 超時時間。
說明:操作系統預設 240 秒後，纔會關閉處於 time_wait 狀態的連線，在高併發存取下，服 務器端會因爲處於 time_wait 的連線數太多，可能無法建立新的連線，所以需要在伺服器上 調小此等待值。
正例:在 linux 伺服器上請通過變更/etc/sysctl.conf 檔案去修改該預設值(秒):
net.ipv4.tcp_fin_timeout = 30
2.【推薦】調大伺服器所支援的最大檔案控制代碼數(File Descriptor，簡寫爲fd)。 說明:主流操作系統的設計是將 TCP/UDP 連線採用與檔案一樣的方式去管理，即一個連線對 應於一個 fd。主流的 linux 伺服器預設所支援最大 fd 數量爲 1024，當併發連線數很大時很 容易因爲 fd 不足而出現「open too many files」錯誤，導致新的連線無法建立。 建議將 linux 伺服器所支援的最大控制代碼數調高數倍(與伺服器的記憶體數量相關)。
3.【推薦】給 JVM 設定-XX:+HeapDumpOnOutOfMemoryError 參數，讓 JVM 碰到 OOM 場景時輸出 dump 資訊。
說明:OOM 的發生是有概率的，甚至有規律地相隔數月纔出現一例，出現時的現場資訊對查錯 非常有價值。
4.【參考】伺服器內部重定向使用 forward;外部重定向地址使用 URL 拼裝工具類來生成，否則 會帶來 URL 維護不一致的問題和潛在的安全風險。