pdf文件鏈接: https://pan.baidu.com/s/15Q_qCyqLTG0wBFyHVM3zog
提取碼: in6y
目錄
一、 編程規約
(一) 命名風格
1. 【強制】代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
反例：_name / __name / $name / name_ / name$ / name__
2. 【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。
說明：正確的英文拼寫和語法可以讓閱讀者易於理解，避免歧義。注意，純拼音命名方式更要避免採用。
正例：renminbi / alibaba / taobao / youku / hangzhou 等國際通用的名稱，可視同英文。
反例：DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變量 = 3
3. 【強制】類名使用 UpperCamelCase 風格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
正例：JavaServerlessPlatform / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：javaserverlessplatform / UserDo / XMLService / TCPUDPDeal / TAPromotion
4. 【強制】方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須遵從駝峯形式。
正例： localValue / getHttpMessage() / inputUserId
5. 【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
正例：MAX_STOCK_COUNT / CACHE_EXPIRED_TIME
反例：MAX_COUNT / EXPIRED_TIME
6. 【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以 Test 結尾。
7. 【強制】類型與中括號緊挨相連來表示數組。
正例：定義整形數組 int[] arrayDemo;
反例：在 main 參數中，使用 String args[]來定義。
8. 【強制】POJO 類中布爾類型變量都不要加 is 前綴，否則部分框架解析會引起序列化錯誤。
說明：在本文 MySQL 規約中的建表約定第一條，表達是與否的值採用 is_xxx 的命名方式，所以，需要在<resultMap>設置從 is_xxx 到 xxx 的映射關係。
反例：定義爲基本數據類型 Boolean isDeleted 的屬性，它的方法也是 isDeleted()，RPC 框架在反向解析的時候，“誤以爲”對應的屬性名稱是 deleted，導致屬性獲取不到，進而拋出異常。
9. 【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用單數形式，但是類名如果有複數含義，類名可以使用複數形式。
正例：應用工具類包名爲 com.alibaba.ai.util、類名爲 MessageUtils（此規則參考 spring 的框架結構）
10.【強制】避免在子父類的成員變量之間、或者不同代碼塊的局部變量之間採用完全相同的命名，使可讀性降低。
說明：子類、父類成員變量名相同，即使是 public 類型的變量也是能夠通過編譯，而局部變量在同一方法
內的不同代碼塊中同名也是合法的，但是要避免使用。對於非 setter/getter 的參數名稱也要避免與成員變量名稱相同。
public class ConfusingName {
public int age;
// 非 setter/getter 的參數名稱，不允許與本類成員變量同名
public void getData(String alibaba) {
if (true) {
final int money = 531;
// ...
}
for (int i = 0; i < 10; i++) {
// 在同一方法體中，不允許與其它代碼塊中的 taobao 命名相同
final int money = 615;
// ...
}
}
}
class Son extends ConfusingName {
// 不允許與父類的成員變量名稱相同
public int age;
}
11.【強制】杜絕完全不規範的縮寫，避免望文不知義。
反例：AbstractClass“縮寫”命名成 AbsClass；condition“縮寫”命名成 condi，此類隨意縮寫嚴重降低了代碼的可閱讀性。
12.【推薦】爲了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡量完整的單詞組合來表達其意。
正例：在 JDK 中，表達原子更新的類名爲：AtomicReferenceFieldUpdater。
反例：int a 的隨意命名方式。
13.【推薦】在常量與變量的命名時，表示類型的名詞放在詞尾，以提升辨識度。
正例：startTime / workQueue / nameList / TERMINATED_THREAD_COUNT
反例：startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD
14.【推薦】如果模塊、接口、類、方法使用了設計模式，在命名時需體現出具體模式。
說明：將設計模式體現在名字中，有利於閱讀者快速理解架構設計理念。
正例： public class OrderFactory;
public class LoginProxy;
public class ResourceObserver;
15.【推薦】接口類中的方法和屬性不要加任何修飾符號（public 也不要加），保持代碼的簡潔性，並加上有效的 Javadoc 註釋。儘量不要在接口裏定義變量，如果一定要定義變量，肯定是與接口方法相關，並且是整個應用的基礎常量。
正例：接口方法簽名 void commit();
接口基礎常量 String COMPANY = "alibaba";
反例：接口方法定義 public abstract void f();
說明：JDK8 中接口允許有默認實現，那麼這個 default 方法，是對所有實現類都有價值的默認實現。
16.接口和實現類的命名有兩套規則：
1）【強制】對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務一定是接口，內部的實現類用Impl 的後綴與接口區別。
正例：CacheServiceImpl 實現 CacheService 接口。
2） 【推薦】如果是形容能力的接口名稱，取對應的形容詞爲接口名（通常是–able 的形容詞）。
正例：AbstractTranslator 實現 Translatable 接口。
17.【參考】枚舉類名帶上 Enum 後綴，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。
說明：枚舉其實就是特殊的類，域成員均爲常量，且構造方法被默認強制是私有。
正例：枚舉名字爲 ProcessStatusEnum 的成員名稱：SUCCESS / UNKNOWN_REASON。
18.【參考】各層命名規約：
A) Service/DAO 層方法命名規約
- 1） 獲取單個對象的方法用 get 做前綴。
- 2） 獲取多個對象的方法用 list 做前綴，複數形式結尾如：listObjects。
- 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。
(二) 常量定義
1. 【強制】不允許任何魔法值（即未經預先定義的常量）直接出現在代碼中。
反例：String key = "Id#taobao_" + tradeId;
cache.put(key, value);
// 緩存 get 時，由於在代碼複製時，漏掉下劃線，導致緩存擊穿而出現問題
2. 【強制】在 long 或者 Long 賦值時，數值後使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，造成誤解。
說明：Long a = 2l; 寫的是數字的 21，還是 Long 型的 2。
3. 【推薦】不要使用一個常量類維護所有常量，要按常量功能進行歸類，分開維護。
說明：大而全的常量類，雜亂無章，使用查找功能才能定位到修改的常量，不利於理解和維護。
正例：緩存相關常量放在類 CacheConsts 下；系統配置相關常量放在類 ConfigConsts 下。
4. 【推薦】常量的複用層次有五層：跨應用共享常量、應用內共享常量、子工程內共享常量、 包內共享常量、類內共享常量。
- 1） 跨應用共享常量：放置在二方庫中，通常是 client.jar 中的 constant 目錄下。
- 2） 應用內共享常量：放置在一方庫中，通常是子模塊中的 constant 目錄下。
反例：易懂變量也要統一定義成應用內共享常量，兩位工程師在兩個類中分別定義了“YES”的變量：
類 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 定義。
5. 【推薦】如果變量值僅在一個固定範圍內變化用 enum 類型來定義。
說明：如果存在名稱之外的延伸屬性應使用 enum 類型，下面正例中的數字就是延伸信息，表示一年中的第幾個季節。
正例：
public enum SeasonEnum {
SPRING(1), SUMMER(2), AUTUMN(3), WINTER(4);
private int seq;
SeasonEnum(int seq) {
this.seq = seq;
}
public int getSeq() {
return seq;
}
}
(三) 代碼格式
1. 【強制】如果是大括號內爲空，則簡潔地寫成{}即可，大括號中間無需換行和空格；如果是非空代碼塊則：
- 1） 左大括號前不換行。
- 2） 左大括號後換行。
- 3） 右大括號前換行。
- 4） 右大括號後還有 else 等代碼則不換行；表示終止的右大括號後必須換行。
2. 【強制】左小括號和字符之間不出現空格；同樣，右小括號和字符之間也不出現空格；而左大括號前需要空格。詳見第 5 條下方正例提示。
反例：if (空格 a == b 空格)
3. 【強制】if/for/while/switch/do 等保留字與括號之間都必須加空格。
4. 【強制】任何二目、三目運算符的左右兩邊都需要加一個空格。
說明：運算符包括賦值運算符=、邏輯運算符&&、加減乘除符號等。
5. 【強制】採用 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");
// 在右大括號後直接結束，則必須換行
}
}
6. 【強制】註釋的雙斜線與註釋內容之間有且僅有一個空格。
正例：
// 這是示例註釋，請注意在雙斜線之後有一個空格
String param = new String();
7. 【強制】在進行類型強制轉換時，右括號與強制轉換值之間不需要任何空格隔開。
正例：
long first = 1000000000000L;
int second = (int)first + 2;
8. 【強制】單行字符數限制不超過 120 個，超出需要換行，換行時遵循如下原則：
- 1）第二行相對第一行縮進 4 個空格，從第三行開始，不再繼續縮進，參考示例。
- 2）運算符與下文一起換行。
- 3）方法調用的點符號與下文一起換行。
- 4）方法調用中的多個參數需要換行時，在逗號後進行。
- 5）在括號前不要換行，見反例。
正例：
StringBuilder sb = new StringBuilder();
// 超過 120 個字符的情況下，換行縮進 4 個空格，點號和方法名稱一起換行
sb.append("Jack").append("Ma")...
.append("alibaba")...
.append("alibaba")...
.append("alibaba");
反例：
StringBuilder sb=new StringBuilder();
// 超過 120 個字符的情況下，不要在括號前換行
sb.append("Jack").append("Ma")...append
("alibaba");
// 參數很多的方法調用可能超過 120 個字符，不要在逗號前換行
method(args1,args2,args3,...
,argsX);
9. 【強制】方法參數在定義和傳入時，多個參數逗號後邊必須加空格。
正例：下例中實參的 args1，後邊必須要有一個空格。
method(args1, args2, args3);
10.【強制】IDE 的 text file encoding 設置爲 UTF-8; IDE 中文件的換行符使用 Unix 格式，不要使用 Windows 格式。
11.【推薦】單個方法的總行數不超過 80 行。
說明：除註釋之外的方法簽名、左右大括號、方法內代碼、空行、回車及任何不可見字符的總行數不超過80 行。
正例：代碼邏輯分清紅花和綠葉，個性和共性，綠葉邏輯單獨出來成爲額外方法，使主幹代碼更加清晰；共性邏輯抽取成爲共性方法，便於複用和維護。
12.【推薦】沒有必要增加若干空格來使變量的賦值等號與上一行對應位置的等號對齊。
說明：增加 sb 這個變量，如果需要對齊，則給 one、two、three 都要增加幾個空格，在變量比較多的情況下，是非常累贅的事情。
13.【推薦】不同邏輯、不同語義、不同業務的代碼之間插入一個空行分隔開來以提升可讀性。
說明：任何情形，沒有必要插入多個空行進行隔開。
(四) OOP 規約
1. 【強制】避免通過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增加編譯器解析成本，直接用類名來訪問即可。
2. 【強制】所有的覆寫方法，必須加@Override 註解。
說明：getObject()與 get0bject()的問題。一個是字母的 O，一個是數字的 0，加@Override 可以準確判斷是否覆蓋成功。另外，如果在抽象類中對方法簽名進行修改，其實現類會馬上編譯報錯。
3. 【強制】相同參數類型，相同業務含義，纔可以使用 Java 的可變參數，避免使用 Object。
說明：可變參數必須放置在參數列表的最後。（提倡同學們儘量不用可變參數編程）
正例：public List<User> listUsers(String type, Long... ids) {...}
4. 【強制】外部正在調用或者二方庫依賴的接口，不允許修改方法簽名，避免對接口調用方產生影響。接口過時必須加@Deprecated 註解，並清晰地說明採用的新接口或者新服務是什麼。
5. 【強制】不能使用過時的類或方法。
說明：java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已經過時，應該使用雙參數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. 【強制】浮點數之間的等值判斷，基本數據類型不能用==來比較，包裝數據類型不能用equals 來判斷。
說明：浮點數採用“尾數+階碼”的編碼方式，類似於科學計數法的“有效數字+指數”的表示方式。二進制無法精確表示大部分的十進制小數，具體原理參考《碼出高效》。
反例：
正例：
(1) 指定一個誤差範圍，兩個浮點數的差值在此範圍之內，則認爲是相等的。
(2) 使用 BigDecimal 來定義值，再進行浮點數的運算操作。
9. 【強制】定義數據對象 DO 類時，屬性類型要與數據庫字段類型相匹配。
正例：數據庫字段的 bigint 必須與類屬性的 Long 類型相對應。
反例：某個案例的數據庫表 id 字段定義類型 bigint unsigned，實際類對象屬性爲 Integer，隨着 id 越來越大，超過 Integer 的表示範圍而溢出成爲負數。
10.【強制】爲了防止精度損失，禁止使用構造方法 BigDecimal(double)的方式把 double 值轉化爲 BigDecimal 對象。
說明：BigDecimal(double)存在精度損失風險，在精確計算或值比較的場景中可能會導致業務邏輯異常。如：BigDecimal g = new BigDecimal(0.1f); 實際的存儲值爲：0.10000000149
正例：優先推薦入參爲 String 的構造方法，或使用 BigDecimal 的 valueOf 方法，此方法內部其實執行了Double 的 toString，而 Double 的 toString 按 double 的實際能表達的精度對尾數進行了截斷。
BigDecimal recommend1 = new BigDecimal("0.1");
BigDecimal recommend2 = BigDecimal.valueOf(0.1);
11.關於基本數據類型與包裝數據類型的使用標準如下：
- 1） 【強制】所有的 POJO 類屬性必須使用包裝數據類型。
- 2） 【強制】RPC 方法的返回值和參數必須使用包裝數據類型。
- 3） 【推薦】所有的局部變量使用基本數據類型。
說明：POJO 類屬性沒有初值是提醒使用者在需要使用時，必須自己顯式地進行賦值，任何 NPE 問題，或者入庫檢查，都由使用者來保證。
正例：數據庫的查詢結果可能是 null，因爲自動拆箱，用基本數據類型接收有 NPE 風險。
反例：比如顯示成交總額漲跌情況，即正負 x%，x 爲基本數據類型，調用的 RPC 服務，調用不成功時，返回的是默認值，頁面顯示爲 0%，這是不合理的，應該顯示成中劃線。所以包裝數據類型的 null 值，能夠表示額外的信息，如：遠程調用失敗，異常退出。
12.【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性默認值。
反例：POJO 類的 createTime 默認值爲 new Date()，但是這個屬性在數據提取時並沒有置入具體值，在更新其它字段時又附帶更新了此字段，導致創建時間被修改成當前時間。
13.【強制】序列化類新增屬性時，請不要修改 serialVersionUID 字段，避免反序列失敗；如果完全不兼容升級，避免反序列化混亂，那麼請修改 serialVersionUID 值。
說明：注意 serialVersionUID 不一致會拋出序列化運行時異常。
14.【強制】構造方法裏面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
15.【強制】POJO 類必須寫 toString 方法。使用 IDE 中的工具：source> generate toString時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。
說明：在方法執行拋出異常時，可以直接調用 POJO 的 toString()方法打印其屬性值，便於排查問題。
16.【強制】禁止在 POJO 類中，同時存在對應屬性 xxx 的 isXxx()和 getXxx()方法。
說明：框架在調用屬性 xxx 的提取方法時，並不能確定哪個方法一定是被優先調用到。
17.【推薦】使用索引訪問用 String 的 split 方法得到的數組時，需做最後一個分隔符後有無內
容的檢查，否則會有拋 IndexOutOfBoundsException 的風險。
18.【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一起，便於閱讀，此條規則優先於下一條。
19.【推薦】 類內方法定義的順序依次是：公有方法或保護方法 > 私有方法 > getter / setter方法。
說明：公有方法是類的調用者和維護者最關心的方法，首屏展示最好；保護方法雖然只是子類關心，也可能是“模板設計模式”下的核心方法；而私有方法外部一般不需要特別關心，是一個黑盒實現；因爲承載的信息價值較低，所有 Service 和 DAO 的 getter/setter 方法放在類體最後。
20.【推薦】setter 方法中，參數名稱與類成員變量名稱一致，this.成員名 = 參數名。在getter/setter 方法中，不要增加業務邏輯，增加排查問題的難度。
21.【推薦】循環體內，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。
說明：下例中，反編譯出的字節碼文件顯示每次循環都會 new 出一個 StringBuilder 對象，然後進行append 操作，最後通過 toString 方法返回 String 對象，造成內存資源浪費。
22.【推薦】final 可以聲明類、成員變量、方法、以及本地變量，下列情況使用 final 關鍵字：
- 1） 不允許被繼承的類，如：String 類。
- 2） 不允許修改引用的域對象。
- 3） 不允許被覆寫的方法，如：POJO 類的 setter 方法。
- 4） 不允許運行過程中重新賦值的局部變量。
- 5） 避免上下文重複使用一個變量，使用 final 可以強制重新定義一個變量，方便更好地進行重構。
23.【推薦】慎用 Object 的 clone 方法來拷貝對象。
說明：對象 clone 方法默認是淺拷貝，若想實現深拷貝需覆寫 clone 方法實現域對象的深度遍歷式拷貝。
24.【推薦】類成員與方法訪問控制從嚴：
- 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 成員方法或成員變量，刪除一下，不得手心冒點汗嗎？變量像自己的小孩，儘量在自己的視線內，變量作用域太大，無限制的到處跑，那麼你會擔心的。
(五) 集合處理
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. 【強制】使用 Map 的方法 keySet()/values()/entrySet()返回集合對象時，不可以對其進行添加元素操作，否則會拋出 UnsupportedOperationException 異常。
4. 【強制】Collections 類返回的對象，如：emptyList()/singletonList()等都是 immutable list，不可對其進行添加或者刪除元素的操作。
反例：如果查詢無結果，返回 Collections.emptyList()空集合對象，調用方一旦進行了添加元素的操作，就會觸發UnsupportedOperationException 異常。
5. 【強制】在 subList 場景中，高度注意對原集合元素的增加或刪除，均會導致子列表的遍歷、增加、刪除產生 ConcurrentModificationException 異常。
6. 【強制】使用集合轉數組的方法，必須使用集合的 toArray(T[] array)，傳入的是類型完全一致、長度爲 0 的空數組。
反例：直接使用 toArray 無參方法存在問題，此方法返回值只能是 Object[]類，若強轉其它類型數組將出現 ClassCastException 錯誤。
正例：
List<String> list = new ArrayList<>(2);
list.add("guan");
list.add("bao");
String[] array = list.toArray(new String[0]);
說明：使用 toArray 帶參方法，數組空間大小的 length：
- 1） 等於 0，動態創建與 size 相同的數組，性能最好。
- 2） 大於 0 但小於 size，重新創建大小等於 size 的數組，增加 GC 負擔。
- 3） 等於 size，在高併發情況下，數組創建完成之後，size 正在變大的情況下，負面影響與上相同。
- 4） 大於 size，空間浪費，且在 size 處插入 null 值，存在 NPE 隱患。
7. 【強制】在使用 Collection 接口任何實現類的 addAll()方法時，都要對輸入的集合參數進行NPE 判斷。
說明：在 ArrayList#addAll 方法的第一行代碼即 Object[] a = c.toArray(); 其中 c 爲輸入集合參數，如果爲 null，則直接拋出異常。
8. 【強制】使用工具類 Arrays.asList()把數組轉換成集合時，不能使用其修改集合相關的方法，它的 add/remove/clear 方法會拋出 UnsupportedOperationException 異常。
說明：asList 的返回對象是一個 Arrays 內部類，並沒有實現集合的修改方法。Arrays.asList 體現的是適配器模式，只是轉換接口，後臺的數據仍是數組。
String[] str = new String[] { "yang", "hao" };
List list = Arrays.asList(str);
第一種情況：list.add("yangguanbao"); 運行時異常。
第二種情況：str[0] = "changed"; 也會隨之修改，反之亦然。
9. 【強制】泛型通配符<? extends T>來接收返回的數據，此寫法的泛型集合不能使用 add 方法，而<? super T>不能使用 get 方法，作爲接口調用賦值時易出錯。
說明：擴展說一下 PECS(Producer Extends Consumer Super)原則：第一、頻繁往外讀取內容的，適合用<? extends T>。第二、經常往裏插入的，適合用<? super T>
10.【強制】在無泛型限制定義的集合賦值給泛型限制的集合時，在使用集合元素時，需要進行instanceof 判斷，避免拋出 ClassCastException 異常。
說明：畢竟泛型是在 JDK5 後纔出現，考慮到向前兼容，編譯器是允許非泛型集合與泛型集合互相賦值。
11.【強制】不要在 foreach 循環裏進行元素的 remove/add 操作。remove 元素請使用Iterator 方式，如果併發操作，需要對 Iterator 對象加鎖。
說明：以上代碼的執行結果肯定會出乎大家的意料，那麼試一下把“1”換成“2”，會是同樣的結果嗎？
12.【強制】在 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 比較結果相同。
13.【推薦】集合泛型定義時，在 JDK7 及以上，使用 diamond 語法或全省略。
說明：菱形泛型，即 diamond，直接使用<>來指代前邊已經指定的類型。
14.【推薦】集合初始化時，指定集合初始值大小。
說明：HashMap 使用 HashMap(int initialCapacity) 初始化。
正例：initialCapacity = (需要存儲的元素個數 / 負載因子) + 1。注意負載因子（即 loader factor）默認爲 0.75，如果暫時無法確定初始值大小，請設置爲 16（即默認值）。
反例：HashMap 需要放置 1024 個元素，由於沒有設置容量初始大小，隨着元素不斷增加，容量 7 次被迫擴大，resize 需要重建 hash 表，嚴重影響性能。
15.【推薦】使用 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 值組合集合。
16.【推薦】高度注意 Map 類集合 K/V 能不能存儲 null 值的情況，如下表格：
反例：由於 HashMap 的干擾，很多人認爲 ConcurrentHashMap 是可以置入 null 值，而事實上，存儲null 值時會拋出 NPE 異常。
17.【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和不穩定性(unorder)帶來的負面影響。
說明：有序性是指遍歷的結果是按某種比較規則依次排列的。穩定性指集合每次遍歷的元素次序是一定的。如：ArrayList 是 order/unsort；HashMap 是 unorder/unsort；TreeSet 是 order/sort。
18.【參考】利用 Set 元素唯一的特性，可以快速對一個集合進行去重操作，避免使用 List 的contains 方法進行遍歷、對比、去重操作。
(六) 併發處理
1. 【強制】獲取單例對象需要保證線程安全，其中的方法也要保證線程安全。
說明：資源驅動類、工具類、單例工廠類都需要注意。
2. 【強制】創建線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。
正例：自定義線程工廠，並且根據外部特徵進行分組，比如機房信息。
public class UserThreadFactory implements ThreadFactory {
private final String namePrefix;
private final AtomicInteger nextId = new AtomicInteger(1);
// 定義線程組名稱，在 jstack 問題排查時，非常有幫助
UserThreadFactory(String whatFeaturOfGroup) {
namePrefix = "From UserThreadFactory's " + whatFeaturOfGroup + "-Worker-";
}
@Override
public Thread newThread(Runnable task) {
String name = namePrefix + nextId.getAndIncrement();
Thread thread = new Thread(null, task, name, 0, false);
System.out.println(thread.getName());
return thread;
}
}
3. 【強制】線程資源必須通過線程池提供，不允許在應用中自行顯式創建線程。
說明：線程池的好處是減少在創建和銷燬線程上所消耗的時間以及系統資源的開銷，解決資源不足的問題。如果不使用線程池，有可能造成系統創建大量同類線程而導致消耗完內存或者“過度切換”的問題。
4. 【強制】線程池不允許使用 Executors 去創建，而是通過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同學更加明確線程池的運行規則，規避資源耗盡的風險。
說明：Executors 返回的線程池對象的弊端如下：
- 1） FixedThreadPool 和 SingleThreadPool：允許的請求隊列長度爲 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。
- 2） CachedThreadPool：允許的創建線程數量爲 Integer.MAX_VALUE，可能會創建大量的線程，從而導致 OOM。
5. 【強制】SimpleDateFormat 是線程不安全的類，一般不要定義爲 static 變量，如果定義爲static，必須加鎖，或者使用 DateUtils 工具類。
說明：如果是 JDK8 的應用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替SimpleDateFormat，官方給出的解釋：simple beautiful strong immutable thread-safe。
6. 【強制】必須回收自定義的 ThreadLocal 變量，尤其在線程池場景下，線程經常會被複用，如果不清理自定義的 ThreadLocal 變量，可能會影響後續業務邏輯和造成內存泄露等問題。儘量在代理中使用 try-finally 塊進行回收。
7. 【強制】高併發時，同步調用應該去考量鎖的性能損耗。能用無鎖數據結構，就不要用鎖；能鎖區塊，就不要鎖整個方法體；能用對象鎖，就不要用類鎖。
說明：儘可能使加鎖的代碼塊工作量儘可能的小，避免在鎖代碼塊中調用 RPC 方法。
8. 【強制】對多個資源、數據庫表、對象同時加鎖時，需要保持一致的加鎖順序，否則可能會造成死鎖。
說明：線程一需要對錶 A、B、C 依次全部加鎖後纔可以進行更新操作，那麼線程二的加鎖順序也必須是A、B、C，否則可能出現死鎖。
9. 【強制】在使用阻塞等待獲取鎖的方式中，必須在 try 代碼塊之外，並且在加鎖方法與 try 代碼塊之間沒有任何可能拋出異常的方法調用，避免加鎖成功後，在 finally 中無法解鎖。
說明一：如果在 lock 方法與 try 代碼塊之間的方法調用拋出異常，那麼無法解鎖，造成其它線程無法成功獲取鎖。
說明二：如果 lock 方法在 try 代碼塊之內，可能由於其它方法拋出異常，導致在 finally 代碼塊中，unlock 對未加鎖的對象解鎖，它會調用 AQS 的 tryRelease 方法（取決於具體實現類），拋出IllegalMonitorStateException 異常。
說明三：在 Lock 對象的 lock 方法實現中可能拋出 unchecked 異常，產生的後果與說明二相同。
10. 【強制】在使用嘗試機制來獲取鎖的方式中，進入業務代碼塊之前，必須先判斷當前線程是否持有鎖。鎖的釋放規則與鎖的阻塞等待方式相同。
說明：Lock 對象的 unlock 方法在執行時，它會調用 AQS 的 tryRelease 方法（取決於具體實現類），如果當前線程不持有鎖，則拋出 IllegalMonitorStateException 異常。
正例：
Lock lock = new XxxLock();
// ...
boolean isLocked = lock.tryLock();
if(isLocked){
try{
doSomething();
doOthers();
}finally{
lock.unlock();
}}
11.【強制】併發修改同一記錄時，避免更新丟失，需要加鎖。要麼在應用層加鎖，要麼在緩存加鎖，要麼在數據庫層使用樂觀鎖，使用 version 作爲更新依據。
說明：如果每次訪問衝突概率小於 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數不得小於3 次。
12.【強制】多線程並行處理定時任務時，Timer 運行多個 TimeTask 時，只要其中之一沒有捕獲拋出的異常，其它任務便會自動終止運行，如果在處理定時任務時使用ScheduledExecutorService 則沒有這個問題。
13.【推薦】資金相關的金融敏感信息，使用悲觀鎖策略。
說明：樂觀鎖在獲得鎖的同時已經完成了更新操作，校驗邏輯容易出現漏洞，另外，樂觀鎖對沖突的解決策略有較複雜的要求，處理不當容易造成系統壓力或數據異常，所以資金相關的金融敏感信息不建議使用樂觀鎖更新。
14.【推薦】使用 CountDownLatch 進行異步轉同步操作，每個線程退出前必須調用 countDown方法，線程執行代碼注意 catch 異常，確保 countDown 方法被執行到，避免主線程無法執行至 await 方法，直到超時才返回結果。
說明：注意，子線程拋出異常堆棧，不能在主線程 try-catch 到。
15.【推薦】避免 Random 實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一seed 導致的性能下降。
說明：Random 實例包括 java.util.Random 的實例或者 Math.random()的方式。
正例：在 JDK7 之後，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要編碼保證每個線程持有一個實例。
16.【推薦】在併發場景下，通過雙重檢查鎖（double-checked locking）實現延遲初始化的優化問題隱患(可參考 The "Double-Checked Locking is Broken" Declaration)，推薦解決方案中較爲簡單一種（適用於 JDK5 及以上版本），將目標屬性聲明爲 volatile 型。
反例：
public class LazyInitDemo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null) synchronized (this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other methods and fields...
}
17.【參考】volatile 解決多線程內存不可見問題。對於一寫多讀，是可以解決變量同步問題，但是如果多寫，同樣無法解決線程安全問題。
說明：如果是 count++操作，使用如下類實現：AtomicInteger count = new AtomicInteger();count.addAndGet(1); 如果是 JDK8，推薦使用 LongAdder 對象，比 AtomicLong 性能更好（減少樂觀鎖的重試次數）。
18.【參考】HashMap 在容量不夠進行 resize 時由於高併發可能出現死鏈，導致 CPU 飆升，在開發過程中可以使用其它數據結構或加鎖來規避此風險。
19.【參考】ThreadLocal 對象使用 static 修飾，ThreadLocal 無法解決共享對象的更新問題。
說明：這個變量是針對一個線程內所有操作共享的，所以設置爲靜態變量，所有此類實例共享此靜態變量，也就是說在類第一次被使用時裝載，只分配一塊存儲空間，所有此類的對象(只要是這個線程內定義的)都可以操控這個變量。
(七) 控制語句
1. 【強制】在一個 switch 塊內，每個 case 要麼通過 continue/break/return 等來終止，要麼註釋說明程序將繼續執行到哪一個 case 爲止；在一個 switch 塊內，都必須包含一個default 語句並且放在最後，即使它什麼代碼也沒有。
說明：注意 break 是退出 switch 語句塊，而 return 是退出方法體。
2. 【強制】當 switch 括號內的變量類型爲 String 並且此變量爲外部參數時，必須先進行 null判斷。
反例：猜猜下面的代碼輸出是什麼？
public class SwitchString {
public static void main(String[] args) {
method(null);
}
public static void method(String param) {
switch (param) {
// 肯定不是進入這裏
case "sth":
System.out.println("it's sth");
break;
// 也不是進入這裏
case "null":
System.out.println("it's null");
break;
// 也不是進入這裏
default:
System.out.println("default");
}
}
}
3. 【強制】在 if/else/for/while/do 語句中必須使用大括號。
說明：即使只有一行代碼，避免採用單行的編碼方式：if (condition) statements;
4. 【強制】在高併發場景中，避免使用”等於”判斷作爲中斷或退出的條件。
說明：如果併發控制沒有處理好，容易產生等值判斷被“擊穿”的情況，使用大於或小於的區間判斷條件來代替。
反例：判斷剩餘獎品數量等於 0 時，終止發放獎品，但因爲併發處理錯誤導致獎品數量瞬間變成了負數，這樣的話，活動無法終止。
5. 【推薦】表達異常的分支時，少用 if-else 方式，這種方式可以改寫成：
if (condition) {
...
return obj;
}
// 接着寫 else 的業務邏輯代碼;
說明：如果非使用 if()...else if()...else...方式表達邏輯，避免後續代碼維護困難，【強制】請勿超過 3 層。
正例：超過 3 層的 if-else 的邏輯判斷代碼可以使用衛語句、策略模式、狀態模式等來實現，其中衛語句即代碼邏輯先考慮失敗、異常、中斷、退出等直接返回的情況，以方法多個出口的方式，解決代碼中判斷分支嵌套的問題，這是逆向思維的體現。
示例如下：
public void findBoyfriend(Man man) {
if (man.isUgly()) {
System.out.println("本姑娘是外貌協會的資深會員");
return;
}
if (man.isPool()) {
System.out.println("貧賤夫妻百事哀");
return;
}
if (man.isBadTemper()) {
System.out.println("銀河有多遠，你就給我滾多遠");
return;
}
System.out.println("可以先交往一段時間看看");
}
6. 【推薦】除常用方法（如 getXxx/isXxx）等外，不要在條件判斷中執行其它複雜的語句，將複雜邏輯判斷的結果賦值給一個有意義的布爾變量名，以提高可讀性。
說明：很多 if 語句內的邏輯表達式相當複雜，與、或、取反混合運算，甚至各種方法縱深調用，理解成本非常高。如果賦值一個非常好理解的布爾變量名字，則是件令人爽心悅目的事情。
正例：
// 僞代碼如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
反例：
public final void acquire(long arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
selfInterrupt();
}
}
7. 【推薦】不要在其它表達式（尤其是條件表達式）中，插入賦值語句。
說明：賦值點類似於人體的穴位，對於代碼的理解至關重要，所以賦值語句需要清晰地單獨成爲一行。
8. 【推薦】循環體中的語句要考量性能，以下操作儘量移至循環體外處理，如定義對象、變量、獲取數據庫連接，進行不必要的 try-catch 操作（這個 try-catch 是否可以移至循環體外）。
9. 【推薦】避免採用取反邏輯運算符。
說明：取反邏輯不利於快速理解，並且取反邏輯寫法必然存在對應的正向邏輯寫法。
正例：使用 if (x < 628) 來表達 x 小於 628。
反例：使用 if (!(x >= 628)) 來表達 x 小於 628。
10.【推薦】接口入參保護，這種場景常見的是用作批量操作的接口。
11.【參考】下列情形，需要進行參數校驗：
- 1） 調用頻次低的方法。
- 2） 執行時間開銷很大的方法。此情形中，參數校驗時間幾乎可以忽略不計，但如果因爲參數錯誤導致中間執行回退，或者錯誤，那得不償失。
- 3） 需要極高穩定性和可用性的方法。
- 4） 對外提供的開放接口，不管是 RPC/API/HTTP 接口。
- 5） 敏感權限入口。
12.【參考】下列情形，不需要進行參數校驗：
- 1） 極有可能被循環調用的方法。但在方法說明裏必須註明外部參數檢查要求。
- 2） 底層調用頻度比較高的方法。畢竟是像純淨水過濾的最後一道，參數錯誤不太可能到底層纔會暴露問題。一般 DAO 層與 Service 層都在同一個應用中，部署在同一臺服務器中，所以 DAO 的參數校驗，可以省略。
- 3） 被聲明成 private 只會被自己代碼所調用的方法，如果能夠確定調用方法的代碼傳入參數已經做過檢 查或者肯定不會有問題，此時可以不校驗參數。
(八) 註釋規約
1. 【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/**內容*/格式，不得使用// xxx 方式。
說明：在 IDE 編輯窗口中，Javadoc 方式會提示相關注釋，生成 Javadoc 可以正確輸出相應註釋；在 IDE中，工程調用方法時，不進入方法即可懸浮提示方法、參數、返回值的意義，提高閱讀效率。
2. 【強制】所有的抽象方法（包括接口中的方法）必須要用 Javadoc 註釋、除了返回值、參數、異常說明外，還必須指出該方法做什麼事情，實現什麼功能。
說明：對子類的實現要求，或者調用注意事項，請一併說明。
3. 【強制】所有的類都必須添加創建者和創建日期。
4. 【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋使用/* */註釋，注意與代碼對齊。
5. 【強制】所有的枚舉類型字段必須要有註釋，說明每個數據項的用途。
6. 【推薦】與其“半吊子”英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文即可。
反例：“TCP 連接超時”解釋成“傳輸控制協議連接超時”，理解反而費腦筋。
7. 【推薦】代碼修改的同時，註釋也要進行相應的修改，尤其是參數、返回值、異常、核心邏輯等的修改。
說明：代碼與註釋更新不同步，就像路網與導航軟件更新不同步一樣，如果導航軟件嚴重滯後，就失去了導航的意義。
8. 【參考】謹慎註釋掉代碼。在上方詳細說明，而不是簡單地註釋掉。如果無用，則刪除。
說明：代碼被註釋掉有兩種可能性：1）後續會恢復此段代碼邏輯。2）永久不用。前者如果沒有備註信息，難以知曉註釋動機。後者建議直接刪掉（代碼倉庫已然保存了歷史代碼）。
9. 【參考】對於註釋的要求：第一、能夠準確反映設計思想和代碼邏輯；第二、能夠描述業務含義，使別的程序員能夠迅速瞭解到代碼背後的信息。完全沒有註釋的大段代碼對於閱讀者形同天書，註釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；註釋也是給繼 任者看的，使其能夠快速接替自己的工作。
10.【參考】好的命名、代碼結構是自解釋的，註釋力求精簡準確、表達到位。避免出現註釋的一個極端：過多過濫的註釋，代碼的邏輯一旦修改，修改註釋是相當大的負擔。
反例：
// put elephant into fridge
put(elephant, fridge);
方法名 put，加上兩個有意義的變量名 elephant 和 fridge，已經說明了這是在幹什麼，語義清晰的代碼不需要額外的註釋。
11.【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，通過標記掃描，經常清理此類標記。線上故障有時候就是來源於這些標記處的代碼。
- 1） 待辦事宜（TODO）:（標記人，標記時間，[預計處理時間]）表示需要實現，但目前還未實現的功能。這實際上是一個 Javadoc 的標籤，目前的 Javadoc 還沒有實現，但已經被廣泛使用。只能應用於類，接口和方法（因爲它是一個 Javadoc 標籤）。
- 2） 錯誤，不能工作（FIXME）:（標記人，標記時間，[預計處理時間]）在註釋中用 FIXME 標記某代碼是錯誤的，而且不能工作，需要及時糾正的情況。
(九) 其它
1. 【強制】在使用正則表達式時，利用好其預編譯功能，可以有效加快正則匹配速度。
說明：不要在方法體內定義：Pattern pattern = Pattern.compile(“規則”);
2. 【強制】velocity 調用 POJO 類的屬性時，直接使用屬性名取值即可，模板引擎會自動按規範調用 POJO 的 getXxx()，如果是 boolean 基本數據類型變量（boolean 命名不需要加 is 前綴），會自動調用 isXxx()方法。
說明：注意如果是 Boolean 包裝類對象，優先調用 getXxx()的方法。
3. 【強制】後臺輸送給頁面的變量必須加$!{var}——中間的感嘆號。
說明：如果 var 等於 null 或者不存在，那麼${var}會直接顯示在頁面上。
4. 【強制】注意 Math.random() 這個方法返回是 double 類型，注意取值的範圍 0≤x<1（能夠取到零值，注意除零異常），如果想獲取整數類型的隨機數，不要將 x 放大 10 的若干倍然後取整，直接使用 Random 對象的 nextInt 或者 nextLong 方法。
5. 【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime();
說明：如果想獲取更加精確的納秒級時間值，使用 System.nanoTime()的方式。在 JDK8 中，針對統計時間等場景，推薦使用 Instant 類。
6. 【強制】日期格式化時，傳入 pattern 中表示年份統一使用小寫的 y。
說明：日期格式化時，yyyy 表示當天所在的年，而大寫的 YYYY 代表是 week in which year（JDK7 之後引入的概念），意思是當天所在的周屬於的年份，一週從週日開始，週六結束，只要本週跨年，返回的 YYYY 就是下一年。另外需要注意：
- 表示月份是大寫的 M
- 表示分鐘則是小寫的 m
- 24 小時制的是大寫的 H
- 12 小時制的則是小寫的 h
正例：表示日期和時間的格式如下所示：
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
7. 【推薦】不要在視圖模板中加入任何複雜的邏輯。
說明：根據 MVC 理論，視圖的職責是展示，不要搶模型和控制器的活。
8. 【推薦】任何數據結構的構造或初始化，都應指定大小，避免數據結構無限增長喫光內存。
9. 【推薦】及時清理不再使用的代碼段或配置信息。
說明：對於垃圾代碼或過時配置，堅決清理乾淨，避免程序過度臃腫，代碼冗餘。
正例：對於暫時被註釋掉，後續可能恢復使用的代碼片斷，在註釋代碼上方，統一規定使用三個斜槓(///)來說明註釋掉代碼的理由。
二、異常日誌
(一) 異常處理
1. 【強制】Java 類庫中定義的可以通過預檢查方式規避的 RuntimeException 異常不應該通過 catch 的方式來處理，比如：NullPointerException，IndexOutOfBoundsException 等等。
說明：無法通過預檢查的異常除外，比如，在解析字符串形式的數字時，可能存在數字格式錯誤，不得不通過 catch NumberFormatException 來實現。
正例：if (obj != null) {...}
反例：try { obj.method(); } catch (NullPointerException e) {…}
2. 【強制】異常不要用來做流程控制，條件控制。
說明：異常設計的初衷是解決程序運行中的各種意外情況，且異常的處理效率比條件判斷方式要低很多。
3. 【強制】catch 時請分清穩定代碼和非穩定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分異常類型，再做對應的異常處理。
說明：對大段代碼進行 try-catch，使程序無法根據不同的異常做出正確的應激反應，也不利於定位問題，這是一種不負責任的表現。
正例：用戶註冊的場景中，如果用戶輸入非法字符，或用戶名稱已存在，或用戶輸入密碼過於簡單，在程序上作出分門別類的判斷，並提示給用戶。
4. 【強制】捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請將該異常拋給它的調用者。最外層的業務使用者，必須處理異常，將其轉化爲用戶可以理解的內容。
5. 【強制】有 try 塊放到了事務代碼中，catch 異常後，如果需要回滾事務，一定要注意手動回滾事務。
6. 【強制】finally 塊必須對資源對象、流對象進行關閉，有異常也要做 try-catch。
說明：如果 JDK7 及以上，可以使用 try-with-resources 方式。
7. 【強制】不要在 finally 塊中使用 return。
說明：try 塊中的 return 語句執行成功後，並不馬上返回，而是繼續執行 finally 塊中的語句，如果此處存在 return 語句，則在此直接返回，無情丟棄掉 try 塊中的返回點。
8. 【強制】捕獲異常與拋異常，必須是完全匹配，或者捕獲異常是拋異常的父類。
說明：如果預期對方拋的是繡球，實際接到的是鉛球，就會產生意外情況。
9. 【強制】在調用 RPC、二方包、或動態生成類的相關方法時，捕捉異常必須使用 Throwable類來進行攔截。
說明：通過反射機制來調用方法，如果找不到方法，拋出 NoSuchMethodException。什麼情況會拋出NoSuchMethodError 呢？二方包在類衝突時，仲裁機制可能導致引入非預期的版本使類的方法簽名不匹配，或者在字節碼修改框架（比如：ASM）動態創建或修改類時，修改了相應的方法簽名。這些情況，即使代碼編譯期是正確的，但在代碼運行期時，會拋出NoSuchMethodError。
10.【推薦】方法的返回值可以爲 null，不強制返回空集合，或者空對象等，必須添加註釋充分說明什麼情況下會返回 null 值。
說明：本手冊明確防止 NPE 是調用者的責任。即使被調用方法返回空集合或者空對象，對調用者來說，也並非高枕無憂，必須考慮到遠程調用失敗、序列化失敗、運行時異常等場景返回 null 的情況。
11.【推薦】防止 NPE，是程序員的基本修養，注意 NPE 產生的場景：
- 1） 返回類型爲基本數據類型，return 包裝數據類型的對象時，自動拆箱有可能產生 NPE。
反例：public int f() { return Integer 對象}， 如果爲 null，自動解箱拋 NPE。
- 2） 數據庫的查詢結果可能爲 null。
- 3） 集合裏的元素即使 isNotEmpty，取出的數據元素也可能爲 null。
- 4） 遠程調用返回對象時，一律要求進行空指針判斷，防止 NPE。
- 5） 對於 Session 中獲取的數據，建議進行 NPE 檢查，避免空指針。
- 6） 級聯調用 obj.getA().getB().getC()；一連串調用，易產生 NPE。
正例：使用 JDK8 的 Optional 類來防止 NPE 問題。
12.【推薦】定義時區分 unchecked / checked 異常，避免直接拋出 new RuntimeException()，更不允許拋出 Exception 或者 Throwable，應使用有業務含義的自定義異常。推薦業界已定義過的自定義異常，如：DAOException / ServiceException 等。
13.【參考】對於公司外的 http/api 開放接口必須使用“錯誤碼”；而應用內部推薦異常拋出；跨應用間 RPC 調用優先考慮使用 Result 方式，封裝 isSuccess()方法、“錯誤碼”、“錯誤簡短信息”。
說明：關於 RPC 方法返回方式使用 Result 方式的理由：
- 1）使用拋異常返回方式，調用方如果沒有捕獲到就會產生運行時錯誤。
- 2）如果不加棧信息，只是 new 自定義異常，加入自己的理解的 error message，對於調用端解決問題的幫助不會太多。如果加了棧信息，在頻繁調用出錯的情況下，數據序列化和傳輸的性能損耗也是問題。
14.【參考】避免出現重複的代碼（Don't Repeat Yourself），即 DRY 原則。
說明：隨意複製和粘貼代碼，必然會導致代碼的重複，在以後需要修改時，需要修改所有的副本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是組件化。
正例：一個類中有多個 public 方法，都需要進行數行相同的參數校驗操作，這個時候請抽取：
private boolean checkParam(DTO dto) {...}
(二) 日誌規約
1. 【強制】應用中不可直接使用日誌系統（Log4j、Logback）中的 API，而應依賴使用日誌框架
SLF4J 中的 API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
2. 【強制】所有日誌文件至少保存 15 天，因爲有些異常具備以“周”爲頻次發生的特點。網絡運行狀態、安全相關信息、系統監測、管理後臺操作、用戶敏感操作需要留存相關的網絡日誌不少於 6 個月。
3. 【強制】應用中的擴展日誌（如打點、臨時監控、訪問日誌等）命名方式：
appName_logType_logName.log。logType:日誌類型，如 stats/monitor/access 等；logName:日誌描述。這種命名的好處：通過文件名就可知道日誌文件屬於什麼應用，什麼類型，什麼目的，也有利於歸類查找。
說明：推薦對日誌進行分類，如將錯誤日誌和業務日誌分開存放，便於開發人員查看，也便於通過日誌對系統進行及時監控。
正例：force-web 應用中單獨監控時區轉換異常，如：force_web_timeZoneConvert.log
4. 【強制】在日誌輸出時，字符串變量之間的拼接使用佔位符的方式。
說明：因爲 String 字符串的拼接會使用 StringBuilder 的 append()方式，有一定的性能損耗。使用佔位符僅是替換動作，可以有效提升性能。
正例：logger.debug("Processing trade with id: {} and symbol: {}", id, symbol);
5. 【強制】對於 trace/debug/info 級別的日誌輸出，必須進行日誌級別的開關判斷。
說明：雖然在 debug(參數)的方法體內第一行代碼 isDisabled(Level.DEBUG_INT)爲真時（Slf4j 的常見實現 Log4j 和 Logback），就直接 return，但是參數可能會進行字符串拼接運算。此外，如果debug(getName())這種參數內有 getName()方法調用，無謂浪費方法調用的開銷。
6. 【強制】避免重複打印日誌，浪費磁盤空間，務必在 log4j.xml 中設置 additivity=false。
正例：<logger name="com.taobao.dubbo.config" additivity="false">
7. 【強制】異常信息應該包括兩類信息：案發現場信息和異常堆棧信息。如果不處理，那麼通過關鍵字 throws 往上拋出。
正例：logger.error(各類參數或者對象 toString() + "_" + e.getMessage(), e);
8. 【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌；有選擇地輸出 info 日誌；如果使用 warn 來記錄剛上線時的業務行爲信息，一定要注意日誌輸出量的問題，避免把服務器磁盤撐爆，並記得及時刪除這些觀察日誌。
說明：大量地輸出無效日誌，不利於系統性能提升，也不利於快速定位錯誤點。記錄日誌時請思考：這些日誌真的有人看嗎？看到這條日誌你能做什麼？能不能給問題排查帶來好處？
9. 【推薦】可以使用 warn 日誌級別來記錄用戶輸入參數錯誤的情況，避免用戶投訴時，無所適從。如非必要，請不要在此場景打出 error 級別，避免頻繁報警。
說明：注意日誌輸出的級別，error 級別只記錄系統邏輯出錯、異常或者重要的錯誤信息。
10.【推薦】儘量用英文來描述日誌錯誤信息，如果日誌中的錯誤信息用英文描述不清楚的話使用中文描述即可，否則容易產生歧義。【強制】國際化團隊或海外部署的服務器由於字符集問題，使用全英文來註釋和描述日誌錯誤信息。
三、單元測試
1. 【強制】好的單元測試必須遵守 AIR 原則。
說明：單元測試在線上運行時，感覺像空氣（AIR）一樣並不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。
- A：Automatic（自動化）
- I：Independent（獨立性）
- R：Repeatable（可重複）
2. 【強制】單元測試應該是全自動執行的，並且非交互式的。測試用例通常是被定期執行的，執行過程必須完全自動化纔有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。
3. 【強制】保持單元測試的獨立性。爲了保證單元測試穩定可靠且便於維護，單元測試用例之間決不能互相調用，也不能依賴執行的先後次序。
反例：method2 需要依賴 method1 的執行，將執行結果作爲 method2 的輸入。
4. 【強制】單元測試是可以重複執行的，不能受到外界環境的影響。
說明：單元測試通常會被放到持續集成中，每次有代碼 check in 時單元測試都會被執行。如果單測對外部環境（網絡、服務、中間件等）有依賴，容易導致持續集成機制的不可用。
正例：爲了不受外界環境影響，要求設計代碼時就把 SUT 的依賴改成注入，在測試時用 spring 這樣的 DI框架注入一個本地（內存）實現或者 Mock 實現。
5. 【強制】對於單元測試，要保證測試粒度足夠小，有助於精確定位問題。單測粒度至多是類級別，一般是方法級別。
說明：只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。
6. 【強制】核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。
說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。
7. 【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。
說明：源碼編譯時會跳過此目錄，而單元測試框架默認是掃描此目錄。
8. 【推薦】單元測試的基本目標：語句覆蓋率達到 70%；核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%
說明：在工程規約的應用分層中提到的 DAO 層，Manager 層，可重用度高的 Service，都應該進行單元測試。
9. 【推薦】編寫單元測試代碼遵守 BCDE 原則，以保證被測試模塊的交付質量。
- B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。
- C：Correct，正確的輸入，並得到預期的結果。
- D：Design，與設計文檔相結合，來編寫單元測試。
- E：Error，強制錯誤信息輸入（如：非法數據、異常流程、業務允許外等），並得到預期的結果。
10.【推薦】對於數據庫相關的查詢，更新，刪除等操作，不能假設數據庫裏的數據是存在的，或者直接操作數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。
反例：刪除某一行數據的單元測試，在數據庫中，先直接手動增加一行作爲刪除目標，但是這一行新增數據並不符合業務插入規則，導致測試結果異常。
11.【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成髒數據。或者對單元測試產生的數據有明確的前後綴標識。
正例：在企業智能事業部的內部單元測試中，使用 ENTERPRISE_INTELLIGENCE _UNIT_TEST_的前綴來標識單元測試相關代碼。
12.【推薦】對於不可測的代碼在適當的時機做必要的重構，使代碼變得可測，避免爲了達到測試要求而書寫不規範測試代碼。
13.【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試範圍，單元測試最好覆蓋所有測試用例。
14.【推薦】單元測試作爲一種質量保障手段，在項目提測前完成單元測試，不建議項目發佈後補充單元測試用例。
15.【參考】爲了更方便地進行單元測試，業務代碼應避免以下情況：
⚫ 構造方法中做的事情過多。
⚫ 存在過多的全局變量和靜態方法。
⚫ 存在過多的外部依賴。
⚫ 存在過多的條件語句。
說明：多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。
16.【參考】不要對單元測試存在如下誤解：
⚫ 那是測試同學乾的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
⚫ 單元測試代碼是多餘的。系統的整體功能與各單元部件的測試正常與否是強相關的。
⚫ 單元測試代碼不需要維護。一年半載後，那麼單元測試幾乎處於廢棄狀態。
⚫ 單元測試與線上故障沒有辯證關係。好的單元測試能夠最大限度地規避線上故障。
四、安全規約
1. 【強制】隸屬於用戶個人的頁面或者功能必須進行權限控制校驗。
說明：防止沒有做水平權限校驗就可隨意訪問、修改、刪除別人的數據，比如查看他人的私信內容、修改他人的訂單。
2. 【強制】用戶敏感數據禁止直接展示，必須對展示數據進行脫敏。
說明：中國大陸個人手機號碼顯示爲:137****0969，隱藏中間 4 位，防止隱私泄露。
3. 【強制】用戶輸入的 SQL 參數嚴格使用參數綁定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 訪問數據庫。
4. 【強制】用戶請求傳入的任何參數必須做有效性驗證。
說明：忽略參數校驗可能導致：
⚫ page size 過大導致內存溢出
⚫ 惡意 order by 導致數據庫慢查詢
⚫ 任意重定向
⚫ SQL 注入
⚫ 反序列化注入
⚫ 正則輸入源串拒絕服務 ReDoS
說明：Java 代碼用正則來驗證客戶端的輸入，有些正則寫法驗證普通用戶輸入沒有問題，但是如果攻擊人員使用的是特殊構造的字符串來驗證，有可能導致死循環的結果。
5. 【強制】禁止向 HTML 頁面輸出未經安全過濾或未正確轉義的用戶數據。
6. 【強制】表單、AJAX 提交必須執行 CSRF 安全驗證。
說明：CSRF(Cross-site request forgery)跨站請求僞造是一類常見編程漏洞。對於存在 CSRF 漏洞的應用/網站，攻擊者可以事先構造好 URL，只要受害者用戶一訪問，後臺便在用戶不知情的情況下對數據庫中用戶參數進行相應修改。
7. 【強制】在使用平臺資源，譬如短信、郵件、電話、下單、支付，必須實現正確的防重放的機制，如數量限制、疲勞度控制、驗證碼校驗，避免被濫刷而導致資損。
說明：如註冊時發送驗證碼到手機，如果沒有限制次數和頻率，那麼可以利用此功能騷擾到其它用戶，並造成短信平臺資源浪費。
8. 【推薦】發貼、評論、發送即時消息等用戶生成內容的場景必須實現防刷、文本內容違禁詞過濾等風控策略。
五、MySQL 數據庫
(一) 建表規約
1. 【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint（1 表示是，0 表示否）。
說明：任何字段如果爲非負數，必須是 unsigned。
注意：POJO 類中的任何布爾類型的變量，都不要加 is 前綴，所以，需要在<resultMap>設置從 is_xxx到 Xxx 的映射關係。數據庫表示是與否的值，使用 tinyint 類型，堅持 is_xxx 的命名方式是爲了明確其取值含義與取值範圍。
正例：表達邏輯刪除的字段名 is_deleted，1 表示刪除，0 表示未刪除。
2. 【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，因爲無法進行預發佈，所以字段名稱需要慎重考慮。
說明：MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。因此，數據庫名、表名、字段名，都不允許出現任何大寫字母，避免節外生枝。
正例：aliyun_admin，rdc_config，level3_name
反例：AliyunAdmin，rdcConfig，level_3_name
3. 【強制】表名不使用複數名詞。
說明：表名應該僅僅表示表裏面的實體內容，不應該表示實體數量，對應於 DO 類名也是單數形式，符合表達習慣。
4. 【強制】禁用保留字，如 desc、range、match、delayed 等，請參考 MySQL 官方保留字。
5. 【強制】主鍵索引名爲 pk_字段名；唯一索引名爲 uk_字段名；普通索引名則爲 idx_字段名。
說明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的簡稱。
6. 【強制】小數類型爲 decimal，禁止使用 float 和 double。
說明：在存儲的時候，float 和 double 都存在精度損失的問題，很可能在比較值的時候，得到不正確的結果。如果存儲的數據範圍超過 decimal 的範圍，建議將數據拆成整數和小數並分開存儲。
7. 【強制】如果存儲的字符串長度幾乎相等，使用 char 定長字符串類型。
8. 【強制】varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，如果存儲長度大於此值，定義字段類型爲 text，獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率。
9. 【強制】表必備三字段：id, create_time, update_time。
說明：其中 id 必爲主鍵，類型爲 bigint unsigned、單表時自增、步長爲 1。create_time, update_time的類型均爲 datetime 類型。
10.【推薦】表的命名最好是遵循“業務名稱_表的作用”。
正例：alipay_task / force_project / trade_config
11.【推薦】庫名與應用名稱儘量一致。
12.【推薦】如果修改字段含義或對字段表示的狀態追加時，需要及時更新字段註釋。
13.【推薦】字段允許適當冗餘，以提高查詢性能，但必須考慮數據一致。冗餘字段應遵循：
- 1） 不是頻繁修改的字段。
- 2） 不是 varchar 超長字段，更不能是 text 字段。
- 3） 不是唯一索引的字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一不變，可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。
14.【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
說明：如果預計三年後的數據量根本達不到這個級別，請不要在創建表時就分庫分表。
15.【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提升檢索速度。
正例：如下表，其中無符號值可以避免誤存負數，且擴大了表示範圍。
(二) 索引規約
1. 【強制】業務上具有唯一特性的字段，即使是多個字段的組合，也必須建成唯一索引。
說明：不要以爲唯一索引影響了 insert 速度，這個速度損耗可以忽略，但提高查找速度是明顯的；另外，即使在應用層做了非常完善的校驗控制，只要沒有唯一索引，根據墨菲定律，必然有髒數據產生。
2. 【強制】超過三個表禁止 join。需要 join 的字段，數據類型必須絕對一致；多表關聯查詢時，保證被關聯的字段需要有索引。
說明：即使雙表 join 也要注意表索引、SQL 性能。
3. 【強制】在 varchar 字段上建立索引時，必須指定索引長度，沒必要對全字段建立索引，根據實際文本區分度決定索引長度即可。
說明：索引的長度與區分度是一對矛盾體，一般對字符串類型數據，長度爲 20 的索引，區分度會高達90%以上，可以使用 count(distinct left(列名, 索引長度))/count(*)的區分度來確定。
4. 【強制】頁面搜索嚴禁左模糊或者全模糊，如果需要請走搜索引擎來解決。
說明：索引文件具有 B-Tree 的最左前綴匹配特性，如果左邊的值未確定，那麼無法使用此索引。
5. 【推薦】如果有 order by 的場景，請注意利用索引的有序性。order by 最後的字段是組合索引的一部分，並且放在索引組合順序的最後，避免出現 file_sort 的情況，影響查詢性能。
正例：where a=? and b=? order by c; 索引：a_b_c
反例：索引如果存在範圍查詢，那麼索引有序性無法利用，如：WHERE a>10 ORDER BY b; 索引 a_b 無法排序。
6. 【推薦】利用覆蓋索引來進行查詢操作，避免回表。
說明：如果一本書需要知道第 11 章是什麼標題，會翻開第 11 章對應的那一頁嗎？目錄瀏覽一下就好，這個目錄就是起到覆蓋索引的作用。
正例：能夠建立索引的種類分爲主鍵索引、唯一索引、普通索引三種，而覆蓋索引只是一種查詢的一種效果，用 explain 的結果，extra 列會出現：using index。
7. 【推薦】利用延遲關聯或者子查詢優化超多分頁場景。
說明：MySQL 並不是跳過 offset 行，而是取 offset+N 行，然後返回放棄前 offset 行，返回 N 行，那當offset 特別大的時候，效率就非常的低下，要麼控制返回的總頁數，要麼對超過特定閾值的頁數進行 SQL改寫。
正例：先快速定位需要獲取的 id 段，然後再關聯：
SELECT a.* FROM 表 1 a, (select id from 表 1 where 條件 LIMIT 100000,20 ) b where a.id=b.id
8. 【推薦】SQL 性能優化的目標：至少要達到 range 級別，要求是 ref 級別，如果可以是consts 最好。
說明：
- 1） consts 單表中最多隻有一個匹配行（主鍵或者唯一索引），在優化階段即可讀取到數據。
- 2） ref 指的是使用普通的索引（normal index）。
- 3） range 對索引進行範圍檢索。
反例：explain 表的結果，type=index，索引物理文件全掃描，速度非常慢，這個 index 級別比較 range還低，與全表掃描是小巫見大巫。
9. 【推薦】建組合索引的時候，區分度最高的在最左邊。
正例：如果 where a=? and b=? ，如果 a 列的幾乎接近於唯一值，那麼只需要單建 idx_a 索引即可。
說明：存在非等號和等號混合時，在建索引時，請把等號條件的列前置。如：where c>? and d=? 那麼即使 c 的區分度更高，也必須把 d 放在索引的最前列，即索引 idx_d_c。
10.【推薦】防止因字段類型不同造成的隱式轉換，導致索引失效。
11.【參考】創建索引時避免有如下極端誤解：
- 1） 寧濫勿缺。認爲一個查詢就需要建一個索引。
- 2） 寧缺勿濫。認爲索引會消耗空間、嚴重拖慢記錄的更新以及行的新增速度。
- 3） 抵制惟一索引。認爲業務的惟一性一律需要在應用層通過“先查後插”方式解決。
(三) SQL 語句
1. 【強制】不要使用 count(列名)或 count(常量)來替代 count(*)，count(*)是 SQL92 定義的標準統計行數的語法，跟數據庫無關，跟 NULL 和非 NULL 無關。
說明：count(*)會統計值爲 NULL 的行，而 count(列名)不會統計此列爲 NULL 值的行。
2. 【強制】count(distinct col) 計算該列除 NULL 之外的不重複行數，注意 count(distinct col1, col2) 如果其中一列全爲 NULL，那麼即使另一列有不同的值，也返回爲 0。
3. 【強制】當某一列的值全是 NULL 時，count(col)的返回結果爲 0，但 sum(col)的返回結果爲 NULL，因此使用 sum()時需注意 NPE 問題。
正例：使用如下方式來避免 sum 的 NPE 問題：SELECT IFNULL(SUM(column), 0) FROM table;
4. 【強制】使用 ISNULL()來判斷是否爲 NULL 值。
說明：NULL 與任何值的直接比較都爲 NULL。
- 1） NULL<>NULL 的返回結果是 NULL，而不是 false。
- 2） NULL=NULL 的返回結果是 NULL，而不是 true。
- 3） NULL<>1 的返回結果是 NULL，而不是 true。
5. 【強制】代碼中寫分頁查詢邏輯時，若 count 爲 0 應直接返回，避免執行後面的分頁語句。
6. 【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。
說明：以學生和成績的關係爲例，學生表中的 student_id 是主鍵，那麼成績表中的 student_id 則爲外鍵。如果更新學生表中的 student_id，同時觸發成績表中的 student_id 更新，即爲級聯更新。外鍵與級聯更新適用於單機低併發，不適合分佈式、高併發集羣；級聯更新是強阻塞，存在數據庫更新風暴的風險；外鍵影響數據庫的插入速度。
7. 【強制】禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。
8. 【強制】數據訂正（特別是刪除、修改記錄操作）時，要先 select，避免出現誤刪除，確認無誤才能執行更新語句。
9. 【推薦】in 操作能避免則避免，若實在避免不了，需要仔細評估 in 後邊的集合元素數量，控制在 1000 個之內。
10.【參考】如果有國際化需要，所有的字符存儲與表示，均以 utf-8 編碼，注意字符統計函數的區別。
說明：
SELECT LENGTH("輕鬆工作")； 返回爲 12
SELECT CHARACTER_LENGTH("輕鬆工作")； 返回爲 4
如果需要存儲表情，那麼選擇 utf8mb4 來進行存儲，注意它與 utf-8 編碼的區別。
11.【參考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少，但TRUNCATE 無事務且不觸發 trigger，有可能造成事故，故不建議在開發代碼中使用此語句。
說明：TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。
(四) ORM 映射
1. 【強制】在表查詢中，一律不要使用 * 作爲查詢的字段列表，需要哪些字段必須明確寫明。
說明：1）增加查詢分析器解析成本。2）增減字段容易與 resultMap 配置不一致。3）無用字段增加網絡消耗，尤其是 text 類型的字段。
2. 【強制】POJO 類的布爾屬性不能加 is，而數據庫字段必須加 is_，要求在 resultMap 中進行字段與屬性之間的映射。
說明：參見定義 POJO 類以及數據庫字段定義規定，在<resultMap>中增加映射，是必須的。在MyBatis Generator 生成的代碼中，需要進行對應的修改。
3. 【強制】不要用 resultClass 當返回參數，即使所有類屬性名與數據庫字段一一對應，也需要定義；反過來，每一個表也必然有一個 POJO 類與之對應。
說明：配置映射關係，使字段與 DO 類解耦，方便維護。
4. 【強制】sql.xml 配置參數使用：#{}，#param# 不要使用${} 此種方式容易出現 SQL 注入。
5. 【強制】iBATIS 自帶的 queryForList(String statementName,int start,int size)不推薦使用。
說明：其實現方式是在數據庫取到 statementName 對應的 SQL 語句的所有記錄，再通過 subList 取start,size 的子集合。
正例：Map<String, Object> map = new HashMap<>();
map.put("start", start);
map.put("size", size);
6. 【強制】不允許直接拿 HashMap 與 Hashtable 作爲查詢結果集的輸出。
說明：resultClass=”Hashtable”，會置入字段名和屬性值，但是值的類型不可控。
7. 【強制】更新數據表記錄時，必須同時更新記錄對應的 gmt_modified 字段值爲當前時間。
8. 【推薦】不要寫一個大而全的數據更新接口。傳入爲 POJO 類，不管是不是自己的目標更新字段，都進行 update table set c1=value1,c2=value2,c3=value3; 這是不對的。執行 SQL時，不要更新無改動的字段，一是易出錯；二是效率低；三是增加 binlog 存儲。
9. 【參考】@Transactional 事務不要濫用。事務會影響數據庫的 QPS，另外使用事務的地方需要考慮各方面的回滾方案，包括緩存回滾、搜索引擎回滾、消息補償、統計修正等。
10.【參考】<isEqual>中的 compareValue 是與屬性值對比的常量，一般是數字，表示相等時帶上此條件；<isNotEmpty>表示不爲空且不爲 null 時執行；<isNotNull>表示不爲 null 值時執行。
六、工程結構
(一) 應用分層
1. 【推薦】圖中默認上層依賴於下層，箭頭關係表示可直接依賴，如：開放接口層可以依賴於Web 層，也可以直接依賴於 Service 層，依此類推：
- 開放接口層：可直接封裝 Service 方法暴露成 RPC 接口；通過 Web 封裝成 http 接口；進行網關安全控制、流量控制等。
- 終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染，JSP 渲染，移動端展示等。
- Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
- Service 層：相對具體的業務邏輯服務層。
- Manager 層：通用業務處理層，它有如下特徵：
- 對第三方平臺封裝的層，預處理返回結果及轉化異常信息。
- 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。
- 與 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. 【參考】分層領域模型規約：
- DO（Data Object）：此對象與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。
- DTO（Data Transfer Object）：數據傳輸對象，Service 或 Manager 向外傳輸的對象。
- BO（Business Object）：業務對象，由 Service 層輸出的封裝業務邏輯的對象。
- AO（Application Object）：應用對象，在 Web 層與 Service 層之間抽象的複用對象模型，極爲貼近展示層，複用度不高。
- VO（View Object）：顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。
- Query：數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。
(二) 二方庫依賴
1. 【強制】定義 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：詳細規定參考下方。
2. 【強制】二方庫版本號命名方式：主版本號.次版本號.修訂號
1）主版本號：產品方向改變，或者大規模 API 不兼容，或者架構不兼容升級。
2） 次版本號：保持相對兼容性，增加主要功能特性，影響範圍極小的 API 不兼容修改。
3） 修訂號：保持完全兼容性，修復 BUG、新增次要功能特性等。
說明：注意起始版本號必須爲：1.0.0，而不是 0.0.1，正式發佈的類庫必須先去中央倉庫進行查證，使版本號有延續性，正式版本號不允許覆蓋升級。如當前版本：1.3.3，那麼下一個合理的版本號：1.3.4 或1.4.0 或 2.0.0
3. 【強制】線上應用不要依賴 SNAPSHOT 版本（安全包除外）。
說明：不依賴 SNAPSHOT 版本是保證應用發佈的冪等性。另外，也可以加快編譯時的打包構建。
4. 【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變，必須明確評估和驗證。
說明：在升級時，進行 dependency:resolve 前後信息比對，如果仲裁結果完全不一致，那麼通過dependency:tree 命令，找出差異點，進行<exclude>排除 jar 包。
5. 【強制】二方庫裏可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。
6. 【強制】依賴於一個二方庫羣時，必須定義一個統一的版本變量，避免版本號不一致。
說明：依賴 springframework-core,-context,-beans，它們都是同一個版本，可以定義一個變量來保存版本：${spring.version}，定義依賴的時候，引用該版本。
7. 【強制】禁止在子項目的 pom 依賴中出現相同的 GroupId，相同的 ArtifactId，但是不同的Version。
說明：在本地調試時會使用各子項目指定的版本號，但是合併成一個 war，只能有一個版本號出現在最後的 lib 目錄中。可能出現線下調試是正確的，發佈到線上卻出故障的問題。
8. 【推薦】底層基礎技術框架、核心數據管理平臺、或近硬件端系統謹慎引入第三方實現。
9. 【推薦】所有 pom 文件中的依賴聲明放在<dependencies>語句塊中，所有版本仲裁放在<dependencyManagement>語句塊中。
說明：<dependencyManagement>裏只是聲明版本，並不實現引入，因此子項目需要顯式的聲明依賴，version 和 scope 都讀取自父 pom。而<dependencies>所有聲明在主 pom 的<dependencies>裏的依賴都會自動引入，並默認被所有的子項目繼承。
10.【推薦】二方庫不要有配置項，最低限度不要再增加配置項。
11.【參考】爲避免應用二方庫的依賴衝突問題，二方庫發佈者應當遵循以下原則：
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. 【推薦】在線上生產環境，JVM 的 Xms 和 Xmx 設置一樣大小的內存容量，避免在 GC 後調整堆大小帶來的壓力。
5. 【參考】服務器內部重定向使用 forward；外部重定向地址使用 URL 拼裝工具類來生成，否則會帶來 URL 維護不一致的問題和潛在的安全風險。
七、設計規約
1. 【強制】存儲方案和底層數據結構的設計獲得評審一致通過，並沉澱成爲文檔。
說明：有缺陷的底層數據結構容易導致系統風險上升，可擴展性下降，重構成本也會因歷史數據遷移和系統平滑過渡而陡然增加，所以，存儲方案和數據結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。
正例：評審內容包括存儲介質選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或字段之間的辯證關係、字段名稱、字段類型、索引等；數據結構變更（如在原有表中新增字段）也需要進行評審通過後上線。
2. 【強制】在需求分析階段，如果與系統交互的 User 超過一類並且相關的 User Case 超過 5 個，使用用例圖來表達更加清晰的結構化需求。
3. 【強制】如果某個業務對象的狀態超過 3 個，使用狀態圖來表達並且明確狀態變化的各個觸發條件。
說明：狀態圖的核心是對象狀態，首先明確對象有多少種狀態，然後明確兩兩狀態之間是否存在直接轉換關係，再明確觸發狀態轉換的條件是什麼。
正例：淘寶訂單狀態有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀態之間是不可能有直接轉換關係的。
4. 【強制】如果系統中某個功能的調用鏈路上的涉及對象超過 3 個，使用時序圖來表達並且明確各調用環節的輸入與輸出。
說明：時序圖反映了一系列對象間的交互與協作關係，清晰立體地反映系統的調用縱深鏈路。
5. 【強制】如果系統中模型類超過 5 個，並且存在複雜的依賴關係，使用類圖來表達並且明確類之間的關係。
說明：類圖像建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 Z 空間大樓，肯定需要詳細的施工圖。
6. 【強制】如果系統中超過 2 個對象之間存在協作關係，並且需要表示複雜的處理流程，使用活動圖來表示。
說明：活動圖是流程圖的擴展，增加了能夠體現協作關係的對象泳道，支持表示併發等。
7. 【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。
反例：用戶在淘寶付款過程中，銀行扣款成功，發送給用戶扣款成功短信，但是支付寶入款時由於斷網演練產生異常，淘寶訂單頁面依然顯示未付款，導致用戶投訴。
8. 【推薦】類在設計與實現時要符合單一原則。
說明：單一原則最易理解卻是最難實現的一條規則，隨着系統演進，很多時候，忘記了類設計的初衷。
9. 【推薦】謹慎使用繼承的方式來進行擴展，優先使用聚合/組合的方式來實現。
說明：不得已使用繼承的話，必須符合里氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現，比如，“把錢交出來”，錢的子類美元、歐元、人民幣等都可以出現。
10.【推薦】系統設計時，根據依賴倒置原則，儘量依賴抽象類與接口，有利於擴展與維護。
說明：低層次模塊依賴於高層次模塊的抽象，方便系統間的解耦。
11.【推薦】系統設計時，注意對擴展開放，對修改閉合。
說明：極端情況下，交付線上生產環境的代碼都是不可修改的，同一業務域內的需求變化，通過模塊或類的擴展來實現。
12.【推薦】系統設計階段，共性業務或公共行爲抽取出來公共模塊、公共配置、公共類、公共方法等，避免出現重複代碼或重複配置的情況。
說明：隨着代碼的重複次數不斷增加，維護成本指數級上升。
13.【推薦】避免如下誤解：敏捷開發 = 講故事 + 編碼 + 發佈。
說明：敏捷開發是快速交付迭代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文檔沉澱是需要的。
反例：某團隊爲了業務快速發展，敏捷成了產品經理催進度的藉口，系統中均是勉強能運行但像麪條一樣的代碼，可維護性和可擴展性極差，一年之後，不得不進行大規模重構，得不償失。
14.【參考】系統設計主要目的是明確需求、理順邏輯、後期維護，次要目的用於指導編碼。
說明：避免爲了設計而設計，系統設計文檔有助於後期的系統維護和重構，所以設計結果需要進行分類歸檔保存。
15.【參考】設計的本質就是識別和表達系統難點，找到系統的變化點，並隔離變化點。
說明：世間衆多設計模式目的是相同的，即隔離系統變化點。
16.【參考】系統架構設計的目的：
⚫ 確定系統邊界。確定系統在技術層面上的做與不做。
⚫ 確定系統內模塊之間的關係。確定模塊之間的依賴關係及模塊的宏觀輸入與輸出。
⚫ 確定指導後續設計與演化的原則。使後續的子系統或模塊設計在規定的框架內繼續演化。
⚫ 確定非功能性需求。非功能性需求是指安全性、可用性、可擴展性等。
17.【參考】在做無障礙產品設計時，需要考慮到：
⚫ 所有可交互的控件元素必須能被 tab 鍵聚焦，並且焦點順序需符合自然操作邏輯。
⚫ 用於登陸校驗和請求攔截的驗證碼均需提供圖形驗證以外的其它方式。
⚫ 自定義的控件類型需明確交互方式。
附 ：專有名詞解釋
1. POJO（Plain Ordinary Java Object）: 在本手冊中，POJO 專指只有 setter / getter /toString 的簡單類，包括 DO/DTO/BO/VO 等。
2. GAV（GroupId、ArtifactctId、Version）: Maven 座標，是用來唯一標識 jar 包。
3. OOP（Object Oriented Programming）: 本手冊泛指類、對象的編程處理方式。
4. ORM（Object Relation Mapping）: 對象關係映射，對象領域模型與底層數據之間的轉換，本文泛指 iBATIS, mybatis 等框架。
5. NPE（java.lang.NullPointerException）: 空指針異常。
6. SOA（Service-Oriented Architecture）: 面向服務架構，它可以根據需求通過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用，有利於提升組件可重用性，可維護性。
7. IDE（Integrated Development Environment）: 用於提供程序開發環境的應用程序，一般包括代碼編輯器、編譯器、調試器和圖形用戶界面等工具，本《手冊》泛指 IntelliJ IDEA 和eclipse。
8. OOM（Out Of Memory）: 源於 java.lang.OutOfMemoryError，當 JVM 沒有足夠的內存來爲對象分配空間並且垃圾回收器也無法回收空間時，系統出現的嚴重狀況。
9. 一方庫：本工程內部子項目模塊依賴的庫（jar 包）。
10.二方庫：公司內部發布到中央倉庫，可供公司內部其它應用依賴的庫（jar 包）。
11.三方庫：公司之外的開源庫（jar 包）。
更新：《Java開發手冊》泰山版
會當凌絕頂，一覽衆山小。經過一年的修煉，《Java開發手冊》泰山版於4.22正式發佈。此次泰山版發佈，將帶來三大亮點：「新增5條日期時間規約」；「新增2條表別名sql規約」；「新增統一錯誤碼規約」：
接下來，讓筆者阿飛帶你一起解讀最新泰山版本新增的3項規約。
日期時間規約
如下圖所示，新增的日期時間規約歸屬於第一部分：「編程規約」：
這一段總計此次新增了7個規約條例，前五條全部是「強制」類型的：
-
日期格式化時，傳入pattern中表示年份統一使用小寫的y。「解讀」：yyyy表示當天所在的年，而大寫的YYYY代表是 week in which year。意思是當天所在的周所屬的年份，一週從週日開始，週六結束，只要本週跨年，返回的YYYY就是下一年。
-
在日期格式中分清楚大寫的 M 和小寫的 m，大寫的 H 和小寫的 h 分別指代的意義。「解讀」：大寫M表示月份，小寫m表示分鐘。大寫H表示24小時制，小寫h表示12小時制。
-
獲取當前毫秒數：System.currentTimeMillis(); 而不是 new Date().getTime()。 「解讀」：System.currentTimeMillis()是一個native方法，依賴操作系統，性能更好。而後者事實上是調用了前者獲取時間然後封裝一個Date對象！
-
不允許在程序任何地方中使用：1）java.sql.Date 2）java.sql.Time 3）java.sql.Timestamp。「解讀」：第1個不記錄時間，getHours()拋出異常；第2個不記錄日期，getYear()拋出異常；第3個在構造方法 super((time/1000)*1000)，fastTime和nanos分開存儲秒和納秒信息。
-
不要在程序中寫死一年爲 365 天，避免在公曆閏年時出現日期轉換錯誤或程序邏輯錯誤。
後兩條是「推薦」類型的：
-
避免公曆閏年2月問題。閏年的2月份有29天，一年後的那一天不可能是2月 29日。「解讀」：打個比方，某個任務想一年運行一次，那麼cron表達式不要寫成：0 0 0 29 2 ?。而應該寫成：0 0 0 28 2 ?。前一個表達式實際上是4年才執行一次，後一個表達式纔是一年執行一次。
-
使用枚舉值來指代月份。如果使用數字，注意 Date，Calendar 等日期相關類的月份 month 取值在 0-11 之間。「解讀」：Calendar.JANUARY的值實際上就是0（Calendar中定義爲：public final static int JANUARY = 0）。
2條表別名sql規約
此次泰山版新增了兩條表別名sql規約。一條是強制的，一條是推薦的。
「強制」 對於數據庫中表記錄的查詢和變更，只要涉及多個表，都需要在列名前加表的別名（或表名）進行限定。說明：對多表進行查詢記錄、更新記錄、刪除記錄時，如果對操作列沒有限定表的別名（或表名），並且操作列在多個表中存在時，就會拋異常，相信大家都碰到過Column 'xxxx' in field list is ambiguous這個異常提示吧。正例：select t1.name from table_first as t1 , table_second as t2 where t1.id=t2.id;
「建議」 SQL語句中表的別名前加as，並且以 t1、t2、t3、...的順序依次命名。說明：1）別名可以是表的簡稱，或者是根據表出現的順序，以 t1、t2、t3 的方式命名。2）別名前加as使別名更容易識別。參考正例：select t1.name from table_first as t1, table_second as t2 where t1.id=t2.id。
統一錯誤碼規約
如下圖所示，新增的統一錯誤碼規約是一個全新的部分，即附3。錯誤碼定義對每一個系統的重要性不言而喻，可以說必不可少。良好的錯誤碼定義能讓API的結果變得更易懂，同時能大大提升排查問題效率，並且還可以針對每個異常碼出現的次數做實時監控：
如下圖所示，是截取的部分錯誤碼。完整版請下載最新的Java開發手冊泰山版，下載地址爲https://developer.aliyun.com/topic/java2020：
