【強制】方法參數(shù)在定義和傳入時，多個參數(shù)逗號后邊必須加空格。正例：下例中實參的"a",后邊必須要有一個空格。
method(“a”, “b”, “c”);

【強制】IDE 的 text file encoding 設(shè)置為 UTF-8; IDE 中文件的換行符使用 Unix 格式， 不要使用 Windows 格式。

【推薦】沒有必要增加若干空格來使某一行的字符與上一行對應(yīng)位置的字符對齊。正例：
int a = 3; long b = 4L; float c = 5F;
StringBuffer sb = new StringBuffer();
說明：增加 sb 這個變量，如果需要對齊，則給 a、b、c 都要增加幾個空格，在變量比較多的情況下，是一種累贅的事情。

【推薦】方法體內(nèi)的執(zhí)行語句組、變量的定義語句組、不同的業(yè)務(wù)邏輯之間或者不同的語義之間插入一個空行。相同業(yè)務(wù)邏輯和語義之間不需要插入空行。
說明：沒有必要插入多個空行進行隔開。

【強制】避免通過一個類的對象引用訪問此類的靜態(tài)變量或靜態(tài)方法，無謂增加編譯器解析成本，直接用類名來訪問即可。

【強制】所有的覆寫方法，必須加@Override 注解。
說明：getObject()與 get0bject()的問題。一個是字母的 O，一個是數(shù)字的 0，加@Override 可以準確判斷是否覆蓋成功。另外，如果在抽象類中對方法簽名進行修改，其實現(xiàn)類會馬上編譯報錯。

【強制】相同參數(shù)類型，相同業(yè)務(wù)含義，才可以使用 Java 的可變參數(shù)，避免使用 Object。說明：可變參數(shù)必須放置在參數(shù)列表的最后。（提倡同學們盡量不用可變參數(shù)編程）
正例：public User getUsers(String type, Integer… ids) {…}

【強制】外部正在調(diào)用或者二方庫依賴的接口，不允許修改方法簽名，避免對接口調(diào)用方產(chǎn)生影響。接口過時必須加@Deprecated 注解，并清晰地說明采用的新接口或者新服務(wù)是什么。

【強制】不能使用過時的類或方法。
說明：java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已經(jīng)過時，應(yīng)該使用雙參數(shù) decode(String source, String encode)。接口提供方既然明確是過時接口， 那么有義務(wù)同時提供新的接口；作為調(diào)用方來說，有義務(wù)去考證過時方法的新實現(xiàn)是什么。

【強制】Object 的 equals 方法容易拋空指針異常，應(yīng)使用常量或確定有值的對象來調(diào)用
equals。
正例：“test”.equals(object); 反例：object.equals(“test”);
說明：推薦使用 java.util.Objects#equals（JDK7 引入的工具類）

【強制】所有的相同類型的包裝類對象之間值的比較，全部使用 equals 方法比較。說明：對于 Integer var = ? 在-128 至 127 范圍內(nèi)的賦值，Integer 對象是在

【推薦】循環(huán)體內(nèi)，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。說明：反編譯出的字節(jié)碼文件顯示每次循環(huán)都會 new 出一個 StringBuilder 對象，然后進行append 操作，最后通過 toString 方法返回 String 對象，造成內(nèi)存資源浪費。
反例：
String str = “start”;
for (int i = 0; i < 100; i++) { str = str + “hello”;
}

【推薦】final 可以聲明類、成員變量、方法、以及本地變量，下列情況使用 final 關(guān)鍵字：
1） 不允許被繼承的類，如：String 類。
2） 不允許修改引用的域?qū)ο?#xff0c;如：POJO 類的域變量。
3） 不允許被重寫的方法，如：POJO 類的setter 方法。
4） 不允許運行過程中重新賦值的局部變量。
5） 避免上下文重復(fù)使用一個變量，使用 final 描述可以強制重新定義一個變量，方便更好地進行重構(gòu)。

【推薦】慎用 Object 的 clone 方法來拷貝對象。
說明：對象的 clone 方法默認是淺拷貝，若想實現(xiàn)深拷貝需要重寫 clone 方法實現(xiàn)屬性對象的拷貝。

【推薦】類成員與方法訪問控制從嚴：
1） 如果不允許外部直接通過 new 來創(chuàng)建對象，那么構(gòu)造方法必須是 private。
2） 工具類不允許有 public 或 default 構(gòu)造方法。
3） 類非 static 成員變量并且與子類共享，必須是 protected。4） 類非 static 成員變量并且僅在本類使用，必須是 private。5） 類 static 成員變量如果僅在本類使用，必須是 private。

【強制】獲取單例對象需要保證線程安全，其中的方法也要保證線程安全。說明：資源驅(qū)動類、工具類、單例工廠類都需要注意。

【強制】創(chuàng)建線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。正例：
public class TimerTaskThread extends Thread { public TimerTaskThread() {
super.setName(“TimerTaskThread”);
…
}

【強制】線程資源必須通過線程池提供，不允許在應(yīng)用中自行顯式創(chuàng)建線程。
說明：使用線程池的好處是減少在創(chuàng)建和銷毀線程上所花的時間以及系統(tǒng)資源的開銷，解決資源不足的問題。如果不使用線程池，有可能造成系統(tǒng)創(chuàng)建大量同類線程而導致消耗完內(nèi)存或者“過度切換”的問題。

【強制】線程池不允許使用 Executors 去創(chuàng)建，而是通過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同學更加明確線程池的運行規(guī)則，規(guī)避資源耗盡的風險。
說明：Executors 返回的線程池對象的弊端如下：
1） FixedThreadPool 和 SingleThreadPool:
允許的請求隊列長度為 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。
2） CachedThreadPool 和 ScheduledThreadPool:
允許的創(chuàng)建線程數(shù)量為 Integer.MAX_VALUE，可能會創(chuàng)建大量的線程，從而導致 OOM。

【強制】SimpleDateFormat 是線程不安全的類，一般不要定義為 static 變量，如果定義為
static，必須加鎖，或者使用 DateUtils 工具類。
正例：注意線程安全，使用 DateUtils。亦推薦如下處理：
private static final ThreadLocal df = new ThreadLocal() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat(“yyyy-MM-dd”);
}
};
說明：如果是 JDK8 的應(yīng)用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar， DateTimeFormatter 代替 SimpleDateFormat，官方給出的解釋：simple beautiful strong immutable thread-safe。

【強制】高并發(fā)時，同步調(diào)用應(yīng)該去考量鎖的性能損耗。能用無鎖數(shù)據(jù)結(jié)構(gòu)，就不要用鎖；能鎖區(qū)塊，就不要鎖整個方法體；能用對象鎖，就不要用類鎖。
說明：盡可能使加鎖的代碼塊工作量盡可能的小，避免在鎖代碼塊中調(diào)用 RPC 方法。

【強制】對多個資源、數(shù)據(jù)庫表、對象同時加鎖時，需要保持一致的加鎖順序，否則可能會造成死鎖。
說明：線程一需要對表 A、B、C 依次全部加鎖后才可以進行更新操作，那么線程二的加鎖順序也必須是 A、B、C，否則可能出現(xiàn)死鎖。

【強制】并發(fā)修改同一記錄時，避免更新丟失，需要加鎖。要么在應(yīng)用層加鎖，要么在緩存加鎖，要么在數(shù)據(jù)庫層使用樂觀鎖，使用 version 作為更新依據(jù)。
說明：如果每次訪問沖突概率小于 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數(shù)不得小于 3 次。

【強制】多線程并行處理定時任務(wù)時，Timer 運行多個 TimeTask 時，只要其中之一沒有捕獲拋出的異常，其它任務(wù)便會自動終止運行，使用 ScheduledExecutorService 則沒有這個問題。

【推薦】使用 CountDownLatch 進行異步轉(zhuǎn)同步操作，每個線程退出前必須調(diào)用 countDown 方法，線程執(zhí)行代碼注意 catch 異常，確保 countDown 方法被執(zhí)行到，避免主線程無法執(zhí)行至 await 方法，直到超時才返回結(jié)果。
說明：注意，子線程拋出異常堆棧，不能在主線程 try-catch 到。

【推薦】避免 Random 實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一
seed 導致的性能下降。
說明：Random 實例包括 java.util.Random 的實例或者 Math.random()的方式。
正例：在 JDK7 之后，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要編碼保證每個線程持有一個實例。

【推薦】在并發(fā)場景下，通過雙重檢查鎖（double-checked locking）實現(xiàn)延遲初始化的優(yōu)化問題隱患(可參考 The “Double-Checked Locking is Broken” Declaration)，推薦解決方案中較為簡單一種（適用于 JDK5 及以上版本），將目標屬性聲明為 volatile 型。
反例：
class Singleton {
private Helper helper = null; public Helper getHelper() {
if (helper == null) synchronized(this) { if (helper == null)
helper = new Helper();
}
return helper;
}
// other methods and fields…
}

【參考】volatile 解決多線程內(nèi)存不可見問題。對于一寫多讀，是可以解決變量同步問題， 但是如果多寫，同樣無法解決線程安全問題。如果是 count++操作，使用如下類實現(xiàn)： AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推薦使用 LongAdder 對象，比 AtomicLong 性能更好（減少樂觀鎖的重試次數(shù)）。

【參考】 HashMap 在容量不夠進行 resize 時由于高并發(fā)可能出現(xiàn)死鏈，導致 CPU 飆升，在開發(fā)過程中可以使用其它數(shù)據(jù)結(jié)構(gòu)或加鎖來規(guī)避此風險。

【參考】ThreadLocal 無法解決共享對象的更新問題，ThreadLocal 對象建議使用 static 修飾。這個變量是針對一個線程內(nèi)所有操作共享的，所以設(shè)置為靜態(tài)變量，所有此類實例共享此靜態(tài)變量 ，也就是說在類第一次被使用時裝載，只分配一塊存儲空間，所有此類的對象(只要是這個線程內(nèi)定義的)都可以操控這個變量。

【推薦】除常用方法（如 getXxx/isXxx）等外，不要在條件判斷中執(zhí)行其它復(fù)雜的語句，將復(fù)雜邏輯判斷的結(jié)果賦值給一個有意義的布爾變量名，以提高可讀性。
說明：很多 if 語句內(nèi)的邏輯相當復(fù)雜，閱讀者需要分析條件表達式的最終結(jié)果，才能明確什么樣的條件執(zhí)行什么樣的語句，那么，如果閱讀者分析邏輯表達式錯誤呢？
正例：
// 偽代碼如下
final boolean existed = (file.open(fileName, “w”) != null) && (…) || (…); if (existed) {
…
}
反例：
if ((file.open(fileName, “w”) != null) && (…) || (…)) {
…
}

【推薦】循環(huán)體中的語句要考量性能，以下操作盡量移至循環(huán)體外處理，如定義對象、變量、獲取數(shù)據(jù)庫連接，進行不必要的 try-catch 操作（這個 try-catch 是否可以移至循環(huán)體外）。

【推薦】接口入?yún)⒈Ｗo，這種場景常見的是用于做批量操作的接口。

【參考】下列情形，需要進行參數(shù)校驗：
1） 調(diào)用頻次低的方法。
2） 執(zhí)行時間開銷很大的方法。此情形中，參數(shù)校驗時間幾乎可以忽略不計，但如果因為參數(shù)錯誤導致中間執(zhí)行回退，或者錯誤，那得不償失。
3） 需要極高穩(wěn)定性和可用性的方法。
4） 對外提供的開放接口，不管是 RPC/API/HTTP 接口。
5） 敏感權(quán)限入口。

【參考】下列情形，不需要進行參數(shù)校驗：
1） 極有可能被循環(huán)調(diào)用的方法。但在方法說明里必須注明外部參數(shù)檢查要求。
2） 底層調(diào)用頻度比較高的方法。畢竟是像純凈水過濾的最后一道，參數(shù)錯誤不太可能到底層才會暴露問題。一般 DAO 層與 Service 層都在同一個應(yīng)用中，部署在同一臺服務(wù)器中，所以 DAO 的參數(shù)校驗，可以省略。
3） 被聲明成 private 只會被自己代碼所調(diào)用的方法，如果能夠確定調(diào)用方法的代碼傳入?yún)?shù)已經(jīng)做過檢查或者肯定不會有問題，此時可以不校驗參數(shù)。

【強制】類、類屬性、類方法的注釋必須使用 Javadoc 規(guī)范，使用/*內(nèi)容/格式，不得使用
// xxx 方式。
說明：在 IDE 編輯窗口中，Javadoc 方式會提示相關(guān)注釋，生成 Javadoc 可以正確輸出相應(yīng)注釋；在 IDE 中，工程調(diào)用方法時，不進入方法即可懸浮提示方法、參數(shù)、返回值的意義，提高閱讀效率。

【強制】所有的抽象方法（包括接口中的方法）必須要用 Javadoc 注釋、除了返回值、參數(shù)、異常說明外，還必須指出該方法做什么事情，實現(xiàn)什么功能。
說明：對子類的實現(xiàn)要求，或者調(diào)用注意事項，請一并說明。

【強制】所有的類都必須添加創(chuàng)建者和創(chuàng)建日期。

【強制】方法內(nèi)部單行注釋，在被注釋語句上方另起一行，使用//注釋。方法內(nèi)部多行注釋使用/* */注釋，注意與代碼對齊。

【強制】所有的枚舉類型字段必須要有注釋，說明每個數(shù)據(jù)項的用途。

【推薦】與其“半吊子”英文來注釋，不如用中文注釋把問題說清楚。專有名詞與關(guān)鍵字保持英文原文即可。
反例：“TCP 連接超時”解釋成“傳輸控制協(xié)議連接超時”，理解反而費腦筋。

【推薦】代碼修改的同時，注釋也要進行相應(yīng)的修改，尤其是參數(shù)、返回值、異常、核心邏輯等的修改。
說明：代碼與注釋更新不同步，就像路網(wǎng)與導航軟件更新不同步一樣，如果導航軟件嚴重滯后， 就失去了導航的意義。

【參考】謹慎注釋掉代碼。在上方詳細說明，而不是簡單地注釋掉。如果無用，則刪除。
說明：代碼被注釋掉有兩種可能性：1）后續(xù)會恢復(fù)此段代碼邏輯。2）永久不用。前者如果沒有備注信息，難以知曉注釋動機。后者建議直接刪掉（代碼倉庫保存了歷史代碼）。

【參考】對于注釋的要求：第一、能夠準確反應(yīng)設(shè)計思想和代碼邏輯；第二、能夠描述業(yè)務(wù)含義，使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；注釋也是給繼任者看的，使其能夠快速接替自己的工作。

【參考】好的命名、代碼結(jié)構(gòu)是自解釋的，注釋力求精簡準確、表達到位。避免出現(xiàn)注釋的一個極端：過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔。
反例：
// put elephant into fridge put(elephant, fridge);

【強制】在使用正則表達式時，利用好其預(yù)編譯功能，可以有效加快正則匹配速度。說明：不要在方法體內(nèi)定義：Pattern pattern = Pattern.compile(規(guī)則);

【強制】velocity 調(diào)用 POJO 類的屬性時，建議直接使用屬性名取值即可，模板引擎會自動按規(guī)范調(diào)用 POJO 的 getXxx()，如果是 boolean 基本數(shù)據(jù)類型變量（boolean 命名不需要加 is 前綴），會自動調(diào)用 isXxx()方法。
說明：注意如果是 Boolean 包裝類對象，優(yōu)先調(diào)用 getXxx()的方法。

【強制】后臺輸送給頁面的變量必須加{var}會直接顯示在頁面上。

【強制】注意 Math.random() 這個方法返回是 double 類型，注意取值的范圍 0≤x<1（能夠取到零值，注意除零異常），如果想獲取整數(shù)類型的隨機數(shù)，不要將 x 放大 10 的若干倍然后取整，直接使用 Random 對象的 nextInt 或者 nextLong 方法。

【強制】獲取當前毫秒數(shù) System.currentTimeMillis(); 而不是new Date().getTime(); 說明：如果想獲取更加精確的納秒級時間值，使用 System.nanoTime()的方式。在 JDK8 中， 針對統(tǒng)計時間等場景，推薦使用 Instant 類。

【推薦】不要在視圖模板中加入任何復(fù)雜的邏輯。
說明：根據(jù) MVC 理論，視圖的職責是展示，不要搶模型和控制器的活。

【推薦】任何數(shù)據(jù)結(jié)構(gòu)的構(gòu)造或初始化，都應(yīng)指定大小，避免數(shù)據(jù)結(jié)構(gòu)無限增長吃光內(nèi)存。

【推薦】及時清理不再使用的代碼段或配置信息。
說明：對于垃圾代碼或過時配置，堅決清理干凈，避免程序過度臃腫，代碼冗余。
正例：對于暫時被注釋掉，后續(xù)可能恢復(fù)使用的代碼片斷，在注釋代碼上方，統(tǒng)一規(guī)定使用三個斜杠(///)來說明注釋掉代碼的理由。

【強制】Java 類庫中定義的一類 RuntimeException 可以通過預(yù)先檢查進行規(guī)避，而不應(yīng)該通過 catch 來處理，比如：IndexOutOfBoundsException，NullPointerException 等等。說明：無法通過預(yù)檢查的異常除外，如在解析一個外部傳來的字符串形式數(shù)字時，通過 catch NumberFormatException 來實現(xiàn)。
正例：if (obj != null) {…}
反例：try { obj.method() } catch (NullPointerException e) {…}

【強制】異常不要用來做流程控制，條件控制，因為異常的處理效率比條件分支低。

【強制】對大段代碼進行 try-catch，這是不負責任的表現(xiàn)。catch 時請分清穩(wěn)定代碼和非穩(wěn)定代碼，穩(wěn)定代碼指的是無論如何不會出錯的代碼。對于非穩(wěn)定代碼的 catch 盡可能進行區(qū)分異常類型，再做對應(yīng)的異常處理。

【強制】捕獲異常是為了處理它，不要捕獲了卻什么都不處理而拋棄之，如果不想處理它，請將該異常拋給它的調(diào)用者。最外層的業(yè)務(wù)使用者，必須處理異常，將其轉(zhuǎn)化為用戶可以理解的內(nèi)容。

【強制】有 try 塊放到了事務(wù)代碼中，catch 異常后，如果需要回滾事務(wù)，一定要注意手動回滾事務(wù)。

【強制】finally 塊必須對資源對象、流對象進行關(guān)閉，有異常也要做 try-catch。說明：如果 JDK7 及以上，可以使用 try-with-resources 方式。

【強制】不能在 finally 塊中使用 return，finally 塊中的 return 返回后方法結(jié)束執(zhí)行，不會再執(zhí)行 try 塊中的 return 語句。

【強制】捕獲異常與拋異常，必須是完全匹配，或者捕獲異常是拋異常的父類。說明：如果預(yù)期對方拋的是繡球，實際接到的是鉛球，就會產(chǎn)生意外情況。

【推薦】方法的返回值可以為 null，不強制返回空集合，或者空對象等，必須添加注釋充分說明什么情況下會返回 null 值。調(diào)用方需要進行 null 判斷防止 NPE 問題。
說明：本手冊明確防止 NPE 是調(diào)用者的責任。即使被調(diào)用方法返回空集合或者空對象，對調(diào)用者來說，也并非高枕無憂，必須考慮到遠程調(diào)用失敗、序列化失敗、運行時異常等場景返回null 的情況。

【推薦】防止 NPE，是程序員的基本修養(yǎng)，注意 NPE 產(chǎn)生的場景：
1） 返回類型為基本數(shù)據(jù)類型，return 包裝數(shù)據(jù)類型的對象時，自動拆箱有可能產(chǎn)生 NPE。
反例：public int f() { return Integer 對象}， 如果為null，自動解箱拋 NPE。

【強制】應(yīng)用中不可直接使用日志系統(tǒng)（Log4j、Logback）中的 API，而應(yīng)依賴使用日志框架SLF4J 中的 API，使用門面模式的日志框架，有利于維護和各個類的日志處理方式統(tǒng)一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);

【強制】日志文件推薦至少保存 15 天，因為有些異常具備以“周”為頻次發(fā)生的特點。

【強制】應(yīng)用中的擴展日志（如打點、臨時監(jiān)控、訪問日志等）命名方式： appName_logType_logName.log。logType:日志類型，推薦分類有stats/desc/monitor/visit 等；logName:日志描述。這種命名的好處：通過文件名就可知道日志文件屬于什么應(yīng)用，什么類型，什么目的，也有利于歸類查找。

【強制】好的單元測試必須遵守 AIR 原則。
說明：單元測試在線上運行時，感覺像空氣（AIR）一樣并不存在，但在測試質(zhì)量的保障上， 卻是非常關(guān)鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重復(fù)執(zhí)行的特點。
? A：Automatic（自動化）
? I：Independent（獨立性）
? R：Repeatable（可重復(fù)）

【強制】單元測試應(yīng)該是全自動執(zhí)行的，并且非交互式的。測試框架通常是定期執(zhí)行的，執(zhí)行過程必須完全自動化才有意義。輸出結(jié)果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。

【強制】保持單元測試的獨立性。為了保證單元測試穩(wěn)定可靠且便于維護，單元測試用例之間決不能互相調(diào)用，也不能依賴執(zhí)行的先后次序。
反例：method2 需要依賴 method1 的執(zhí)行，將執(zhí)行結(jié)果做為 method2 的輸入。

【強制】單元測試是可以重復(fù)執(zhí)行的，不能受到外界環(huán)境的影響。
說明：單元測試通常會被放到持續(xù)集成中，每次有代碼 check in 時單元測試都會被執(zhí)行。如果單測對外部環(huán)境（網(wǎng)絡(luò)、服務(wù)、中間件等）有依賴，容易導致持續(xù)集成機制的不可用。
正例：為了不受外界環(huán)境影響，要求設(shè)計代碼時就把 SUT 的依賴改成注入，在測試時用 spring
這樣的 DI 框架注入一個本地（內(nèi)存）實現(xiàn)或者 Mock 實現(xiàn)。

【強制】對于單元測試，要保證測試粒度足夠小，有助于精確定位問題。單測粒度至多是類級別，一般是方法級別。
說明：只有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負責檢查跨類或者跨系統(tǒng)的交互邏輯，那是集成測試的領(lǐng)域。

【強制】核心業(yè)務(wù)、核心應(yīng)用、核心模塊的增量代碼確保單元測試通過。
說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。

【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業(yè)務(wù)代碼目錄下。說明：源碼構(gòu)建時會跳過此目錄，而單元測試框架默認是掃描此目錄。

【推薦】單元測試的基本目標：語句覆蓋率達到 70%；核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%
說明：在工程規(guī)約的應(yīng)用分層中提到的 DAO 層，Manager 層，可重用度高的 Service，都應(yīng)該進行單元測試。

【推薦】編寫單元測試代碼遵守 BCDE 原則，以保證被測試模塊的交付質(zhì)量。
? B：Border，邊界值測試，包括循環(huán)邊界、特殊取值、特殊時間點、數(shù)據(jù)順序等。
? C：Correct，正確的輸入，并得到預(yù)期的結(jié)果。
? D：Design，與設(shè)計文檔相結(jié)合，來編寫單元測試。
? E：Error，強制錯誤信息輸入（如：非法數(shù)據(jù)、異常流程、非業(yè)務(wù)允許輸入等），并得到預(yù)期的結(jié)果。

【推薦】對于數(shù)據(jù)庫相關(guān)的查詢，更新，刪除等操作，不能假設(shè)數(shù)據(jù)庫里的數(shù)據(jù)是存在的， 或者直接操作數(shù)據(jù)庫把數(shù)據(jù)插入進去，請使用程序插入或者導入數(shù)據(jù)的方式來準備數(shù)據(jù)。
反例：刪除某一行數(shù)據(jù)的單元測試，在數(shù)據(jù)庫中，先直接手動增加一行作為刪除目標，但是這一行新增數(shù)據(jù)并不符合業(yè)務(wù)插入規(guī)則，導致測試結(jié)果異常。

【推薦】和數(shù)據(jù)庫相關(guān)的單元測試，可以設(shè)定自動回滾機制，不給數(shù)據(jù)庫造成臟數(shù)據(jù)?；蛘邔卧獪y試產(chǎn)生的數(shù)據(jù)有明確的前后綴標識。
正例：在 RDC 內(nèi)部單元測試中，使用 RDC_UNIT_TEST_的前綴標識數(shù)據(jù)。

【推薦】對于不可測的代碼建議做必要的重構(gòu)，使代碼變得可測，避免為了達到測試要求而書寫不規(guī)范測試代碼。

【推薦】在設(shè)計評審階段，開發(fā)人員需要和測試人員一起確定單元測試范圍，單元測試最好覆蓋所有測試用例（UC）。

【推薦】單元測試作為一種質(zhì)量保障手段，不建議項目發(fā)布后補充單元測試用例，建議在項目提測前完成單元測試。

【參考】為了更方便地進行單元測試，業(yè)務(wù)代碼應(yīng)避免以下情況：
? 構(gòu)造方法中做的事情過多。
? 存在過多的全局變量和靜態(tài)方法。
? 存在過多的外部依賴。
? 存在過多的條件語句。
說明：多層條件語句建議使用衛(wèi)語句、策略模式、狀態(tài)模式等方式重構(gòu)。

【參考】不要對單元測試存在如下誤解：
? 那是測試同學干的事情。本文是開發(fā)手冊，凡是本文內(nèi)容都是與開發(fā)同學強相關(guān)的。
? 單元測試代碼是多余的。汽車的整體功能與各單元部件的測試正常與否是強相關(guān)的。
? 單元測試代碼不需要維護。一年半載后，那么單元測試幾乎處于廢棄狀態(tài)。
? 單元測試與線上故障沒有辯證關(guān)系。好的單元測試能夠最大限度地規(guī)避線上故障。

【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數(shù)據(jù)類型是 unsigned tinyint
（ 1 表示是，0 表示否）。
說明：任何字段如果為非負數(shù)，必須是 unsigned。
正例：表達邏輯刪除的字段名 is_deleted，1 表示刪除，0 表示未刪除。

【強制】表名、字段名必須使用小寫字母或數(shù)字，禁止出現(xiàn)數(shù)字開頭，禁止兩個下劃線中間只出現(xiàn)數(shù)字。數(shù)據(jù)庫字段名的修改代價很大，因為無法進行預(yù)發(fā)布，所以字段名稱需要慎重考慮。說明：MySQL 在Windows 下不區(qū)分大小寫，但在 Linux 下默認是區(qū)分大小寫。因此，數(shù)據(jù)庫名、表名、字段名，都不允許出現(xiàn)任何大寫字母，避免節(jié)外生枝。
正例：aliyun_admin，rdc_config，level3_name 反例：AliyunAdmin，rdcConfig，level_3_name

【強制】表名不使用復(fù)數(shù)名詞。
說明：表名應(yīng)該僅僅表示表里面的實體內(nèi)容，不應(yīng)該表示實體數(shù)量，對應(yīng)于 DO 類名也是單數(shù)形式，符合表達習慣。

【強制】禁用保留字，如 desc、range、match、delayed 等，請參考 MySQL 官方保留字。

【強制】主鍵索引名為 pk_字段名；唯一索引名為 uk_字段名；普通索引名則為 idx_字段名。說明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的簡稱。

【強制】小數(shù)類型為 decimal，禁止使用 float 和 double。
說明：float 和 double 在存儲的時候，存在精度損失的問題，很可能在值的比較時，得到不正確的結(jié)果。如果存儲的數(shù)據(jù)范圍超過 decimal 的范圍，建議將數(shù)據(jù)拆成整數(shù)和小數(shù)分開存儲。

【強制】如果存儲的字符串長度幾乎相等，使用 char 定長字符串類型。

【強制】varchar 是可變長字符串，不預(yù)先分配存儲空間，長度不要超過 5000，如果存儲長度大于此值，定義字段類型為 text，獨立出來一張表，用主鍵來對應(yīng)，避免影響其它字段索引效率。

【強制】表必備三字段：id, gmt_create, gmt_modified。
說明：其中 id 必為主鍵，類型為 unsigned bigint、單表時自增、步長為 1。gmt_create, gmt_modified 的類型均為 date_time 類型，前者現(xiàn)在時表示主動創(chuàng)建，后者過去分詞表示被動更新。

【推薦】表的命名最好是加上“業(yè)務(wù)名稱_表的作用”。 正例：alipay_task / force_project / trade_config

【推薦】庫名與應(yīng)用名稱盡量一致。

【推薦】如果修改字段含義或?qū)ψ侄伪硎镜臓顟B(tài)追加時，需要及時更新字段注釋。

【推薦】字段允許適當冗余，以提高查詢性能，但必須考慮數(shù)據(jù)一致。冗余字段應(yīng)遵循：
1） 不是頻繁修改的字段。
2） 不是 varchar 超長字段，更不能是 text 字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關(guān)聯(lián)的表中冗余存儲類目名稱，避免關(guān)聯(lián)查詢。

【推薦】單表行數(shù)超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
說明：如果預(yù)計三年后的數(shù)據(jù)量根本達不到這個級別，請不要在創(chuàng)建表時就分庫分表。

【參考】合適的字符存儲長度，不但節(jié)約數(shù)據(jù)庫表空間、節(jié)約索引存儲，更重要的是提升檢索速度。
正例：如下表，其中無符號值可以避免誤存負數(shù)，且擴大了表示范圍。

【推薦】SQL 性能優(yōu)化的目標：至少要達到 range 級別，要求是 ref 級別，如果可以是 consts
最好。說明：
1） consts 單表中最多只有一個匹配行（主鍵或者唯一索引），在優(yōu)化階段即可讀取到數(shù)據(jù)。
2） ref 指的是使用普通的索引（normal index）。
3） range 對索引進行范圍檢索。
反例：explain 表的結(jié)果，type=index，索引物理文件全掃描，速度非常慢，這個 index 級別比較 range 還低，與全表掃描是小巫見大巫。

【推薦】建組合索引的時候，區(qū)分度最高的在最左邊。
正例：如果 where a=? and b=? ，a 列的幾乎接近于唯一值，那么只需要單建 idx_a 索引即可。
說明：存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如：where a>? and b=? 那么即使a 的區(qū)分度更高，也必須把 b 放在索引的最前列。

【推薦】防止因字段類型不同造成的隱式轉(zhuǎn)換，導致索引失效。

【參考】創(chuàng)建索引時避免有如下極端誤解：
1） 寧濫勿缺。認為一個查詢就需要建一個索引。
2） 寧缺勿濫。認為索引會消耗空間、嚴重拖慢更新和新增速度。
3） 抵制惟一索引。認為業(yè)務(wù)的惟一性一律需要在應(yīng)用層通過“先查后插”方式解決。

【強制】不要使用 count(列名)或 count(常量)來替代 count()，count()是 SQL92 定義的標準統(tǒng)計行數(shù)的語法，跟數(shù)據(jù)庫無關(guān)，跟 NULL 和非 NULL 無關(guān)。
說明：count(*)會統(tǒng)計值為 NULL 的行，而 count(列名)不會統(tǒng)計此列為 NULL 值的行。

【強制】count(distinct col) 計算該列除 NULL 之外的不重復(fù)行數(shù)，注意 count(distinct col1, col2) 如果其中一列全為 NULL，那么即使另一列有不同的值，也返回為 0。

【強制】當某一列的值全是 NULL 時，count(col)的返回結(jié)果為 0，但 sum(col)的返回結(jié)果為NULL，因此使用 sum()時需注意 NPE 問題。
正例：可以使用如下方式來避免 sum 的 NPE 問題：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

【強制】使用 ISNULL()來判斷是否為 NULL 值。說明：NULL 與任何值的直接比較都為 NULL。
1） NULL<>NULL 的返回結(jié)果是 NULL，而不是 false。
2） NULL=NULL 的返回結(jié)果是 NULL，而不是 true。
3） NULL<>1 的返回結(jié)果是 NULL，而不是 true。

【強制】在代碼中寫分頁查詢邏輯時，若 count 為 0 應(yīng)直接返回，避免執(zhí)行后面的分頁語句。

【強制】不得使用外鍵與級聯(lián)，一切外鍵概念必須在應(yīng)用層解決。
說明：以學生和成績的關(guān)系為例，學生表中的 student_id 是主鍵，那么成績表中的 student_id 則為外鍵。如果更新學生表中的 student_id，同時觸發(fā)成績表中的 student_id 更新，即為級聯(lián)更新。外鍵與級聯(lián)更新適用于單機低并發(fā)，不適合分布式、高并發(fā)集群；級聯(lián)更新是強阻塞，存在數(shù)據(jù)庫更新風暴的風險；外鍵影響數(shù)據(jù)庫的插入速度。

【強制】禁止使用存儲過程，存儲過程難以調(diào)試和擴展，更沒有移植性。

【強制】數(shù)據(jù)訂正時，刪除和修改記錄時，要先 select，避免出現(xiàn)誤刪除，確認無誤才能執(zhí)行更新語句。

【推薦】in 操作能避免則避免，若實在避免不了，需要仔細評估 in 后邊的集合元素數(shù)量，控制在 1000 個之內(nèi)。

【參考】如果有全球化需要，所有的字符存儲與表示，均以 utf-8 編碼，注意字符統(tǒng)計函數(shù)的區(qū)別。
說明：
SELECT LENGTH(“輕松工作”)； 返回為 12
SELECT CHARACTER_LENGTH(“輕松工作”)； 返回為 4
如果需要存儲表情，那么選擇 utfmb4 來進行存儲，注意它與 utf-8 編碼的區(qū)別。

【參考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系統(tǒng)和事務(wù)日志資源少，但 TRUNCATE
無事務(wù)且不觸發(fā) trigger，有可能造成事故，故不建議在開發(fā)代碼中使用此語句。說明：TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。

【強制】在表查詢中，一律不要使用 * 作為查詢的字段列表，需要哪些字段必須明確寫明。說明：1）增加查詢分析器解析成本。2）增減字段容易與 resultMap 配置不一致。

【強制】POJO 類的布爾屬性不能加 is，而數(shù)據(jù)庫字段必須加 is_，要求在 resultMap 中進行字段與屬性之間的映射。
說明：參見定義 POJO 類以及數(shù)據(jù)庫字段定義規(guī)定，在中增加映射，是必須的。在 MyBatis Generator 生成的代碼中，需要進行對應(yīng)的修改。

【強制】不要用 resultClass 當返回參數(shù)，即使所有類屬性名與數(shù)據(jù)庫字段一一對應(yīng)，也需要定義；反過來，每一個表也必然有一個與之對應(yīng)。
說明：配置映射關(guān)系，使字段與 DO 類解耦，方便維護。

【強制】sql.xml 配置參數(shù)使用：#{}，#param# 不要使用${} 此種方式容易出現(xiàn) SQL 注入。

【強制】iBATIS 自帶的 queryForList(String statementName,int start,int size)不推薦使用。
說明：其實現(xiàn)方式是在數(shù)據(jù)庫取到statementName 對應(yīng)的SQL 語句的所有記錄，再通過subList
取 start,size 的子集合。
正例：Map<String, Object> map = new HashMap<String, Object>(); map.put(“start”, start);
map.put(“size”, size);

【強制】不允許直接拿 HashMap 與 Hashtable 作為查詢結(jié)果集的輸出。
說明：resultClass=”Hashtable”，會置入字段名和屬性值，但是值的類型不可控。

【強制】更新數(shù)據(jù)表記錄時，必須同時更新記錄對應(yīng)的 gmt_modified 字段值為當前時間。

【推薦】不要寫一個大而全的數(shù)據(jù)更新接口。傳入為 POJO 類，不管是不是自己的目標更新字段，都進行 update table set c1=value1,c2=value2,c3=value3; 這是不對的。執(zhí)行 SQL 時，不要更新無改動的字段，一是易出錯；二是效率低；三是增加 binlog 存儲。

【參考】@Transactional 事務(wù)不要濫用。事務(wù)會影響數(shù)據(jù)庫的 QPS，另外使用事務(wù)的地方需要考慮各方面的回滾方案，包括緩存回滾、搜索引擎回滾、消息補償、統(tǒng)計修正等。

【參考】中的 compareValue 是與屬性值對比的常量，一般是數(shù)字，表示相等時帶上此條件；表示不為空且不為 null 時執(zhí)行；表示不為 null 值時執(zhí)行。

【強制】定義 GAV 遵從以下規(guī)則：
1） GroupID 格式：com.{公司/BU }.業(yè)務(wù)線.[子業(yè)務(wù)線]，最多 4 級。
說明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一級；子業(yè)務(wù)線可選。正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
2） ArtifactID 格式：產(chǎn)品線名-模塊名。語義不重復(fù)不遺漏，先到中央倉庫去查證一下。正例：dubbo-client / fastjson-api / jstorm-tool
3） Version：詳細規(guī)定參考下方。

【強制】二方庫版本號命名方式：主版本號.次版本號.修訂號
1） 主版本號：產(chǎn)品方向改變，或者大規(guī)模 API 不兼容，或者架構(gòu)不兼容升級。
2） 次版本號：保持相對兼容性，增加主要功能特性，影響范圍極小的 API 不兼容修改。
3） 修訂號：保持完全兼容性，修復(fù) BUG、新增次要功能特性等。
說明：注意起始版本號必須為：1.0.0，而不是 0.0.1 正式發(fā)布的類庫必須先去中央倉庫進行查證，使版本號有延續(xù)性，正式版本號不允許覆蓋升級。如當前版本：1.3.3，那么下一個合理的版本號：1.3.4 或 1.4.0 或 2.0.0

【強制】線上應(yīng)用不要依賴 SNAPSHOT 版本（安全包除外）。
說明：不依賴 SNAPSHOT 版本是保證應(yīng)用發(fā)布的冪等性。另外，也可以加快編譯時的打包構(gòu)建。

【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結(jié)果不變。如果有改變， 必須明確評估和驗證，建議進行 dependency:resolve 前后信息比對，如果仲裁結(jié)果完全不一致，那么通過 dependency:tree 命令，找出差異點，進行排除 jar 包。

【強制】二方庫里可以定義枚舉類型，參數(shù)可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。

【強制】依賴于一個二方庫群時，必須定義一個統(tǒng)一的版本變量，避免版本號不一致。
說明：依賴 springframework-core,-context,-beans，它們都是同一個版本，可以定義一個變量來保存版本：${spring.version}，定義依賴的時候，引用該版本。

【強制】禁止在子項目的 pom 依賴中出現(xiàn)相同的 GroupId，相同的 ArtifactId，但是不同的Version。
說明：在本地調(diào)試時會使用各子項目指定的版本號，但是合并成一個 war，只能有一個版本號出現(xiàn)在最后的 lib 目錄中。可能出現(xiàn)線下調(diào)試是正確的，發(fā)布到線上卻出故障的問題。

【推薦】所有 pom 文件中的依賴聲明放在語句塊中，所有版本仲裁放在
語句塊中。
說明：里只是聲明版本，并不實現(xiàn)引入，因此子項目需要顯式的聲明依賴，version 和 scope 都讀取自父 pom。而所有聲明在主 pom 的
里的依賴都會自動引入，并默認被所有的子項目繼承。

【推薦】二方庫不要有配置項，最低限度不要再增加配置項。

【參考】為避免應(yīng)用二方庫的依賴沖突問題，二方庫發(fā)布者應(yīng)當遵循以下原則：
1） 精簡可控原則。移除一切不必要的 API 和依賴，只包含 Service API、必要的領(lǐng)域模型對象、Utils 類、常量、枚舉等。如果依賴其它二方庫，盡量是 provided 引入，讓二方庫使用
者去依賴具體版本號；無 log 具體實現(xiàn)，只依賴日志框架。
2） 穩(wěn)定可追溯原則。每個版本的變化應(yīng)該被記錄，二方庫由誰維護，源碼在哪里，都需要能方便查到。除非用戶主動升級版本，否則公共二方庫的行為不應(yīng)該發(fā)生變化。

【推薦】高并發(fā)服務(wù)器建議調(diào)小 TCP 協(xié)議的 time_wait 超時時間。
說明：操作系統(tǒng)默認 240 秒后，才會關(guān)閉處于 time_wait 狀態(tài)的連接，在高并發(fā)訪問下，服務(wù)器端會因為處于 time_wait 的連接數(shù)太多，可能無法建立新的連接，所以需要在服務(wù)器上調(diào)小此等待值。
正例：在 linux 服務(wù)器上請通過變更/etc/sysctl.conf 文件去修改該缺省值（秒）：
net.ipv4.tcp_fin_timeout = 30

【推薦】調(diào)大服務(wù)器所支持的最大文件句柄數(shù)（File Descriptor，簡寫為 fd）。
說明：主流操作系統(tǒng)的設(shè)計是將 TCP/UDP 連接采用與文件一樣的方式去管理，即一個連接對應(yīng)于一個 fd。主流的 linux 服務(wù)器默認所支持最大 fd 數(shù)量為 1024，當并發(fā)連接數(shù)很大時很容易因為 fd 不足而出現(xiàn)“open too many files”錯誤，導致新的連接無法建立。 建議將 linux 服務(wù)器所支持的最大句柄數(shù)調(diào)高數(shù)倍（與服務(wù)器的內(nèi)存數(shù)量相關(guān)）。

【推薦】給 JVM 設(shè)置-XX:+HeapDumpOnOutOfMemoryError 參數(shù)，讓 JVM 碰到 OOM 場景時輸出
dump 信息。
說明：OOM 的發(fā)生是有概率的，甚至有規(guī)律地相隔數(shù)月才出現(xiàn)一例，出現(xiàn)時的現(xiàn)場信息對查錯非常有價值。

【推薦】在線上生產(chǎn)環(huán)境，JVM 的 Xms 和 Xmx 設(shè)置一樣大小的內(nèi)存容量，避免在 GC 后調(diào)整堆大小帶來的壓力。

【參考】服務(wù)器內(nèi)部重定向使用 forward；外部重定向地址使用 URL 拼裝工具類來生成，否則會帶來 URL 維護不一致的問題和潛在的安全風險。