這兩天把《阿里巴巴java開發手冊》看了一遍，整個手冊頁數並不多，裡面的內容都挺好，下面這些是選的自己以前沒有注意的或者感覺很有用的點。

程式設計規範

命名風格

10.【強制】杜絕完全不規範的縮寫，避免望文不知義。
反例： AbstractClass“縮寫”命名成 AbsClass；condition“縮寫”命名成 condi，此類 隨意縮寫嚴重降低了程式碼的可閱讀性。
12.【推薦】介面類中的方法和屬性不要加任何修飾符號（public 也不要加），保持程式碼的簡潔 性，並加上有效的 Javadoc 註釋。儘量不要在接口裡定義變數，如果一定要定義變數，肯定是 與介面方法相關，並且是整個應用的基礎常量。
正例：介面方法簽名：void f(); 介面基礎常量表示：String COMPANY = “alibaba”;
反例：介面方法定義：public abstract void f();
說明：JDK8 中介面允許有預設實現，那麼這個 default 方法，是對所有實現類都有價值的默 認實現。
15. 【參考】各層命名規約：
A) Service/DAO 層方法命名規約
1） 獲取單個物件的方法用 get 做字首。
2） 獲取多個物件的方法用 list 做字首。
3） 獲取統計值的方法用 count 做字首。
4） 插入的方法用 save（推薦）或 insert 做字首。
5） 刪除的方法用 remove（推薦）或 delete 做字首。
6） 修改的方法用 update 做字首

命名風格

1.【強制】不允許任何魔法值（即未經定義的常量）直接出現在程式碼中。
反例：
String key = “Id#taobao_” + tradeId;
cache.put(key, value);
3.【推薦】不要使用一個常量類維護所有常量，應該按常量功能進行歸類，分開維護。如：快取 相關的常量放在類：CacheConsts 下；系統配置相關的常量放在類：ConfigConsts 下。
說明：大而全的常量類，非得使用查詢功能才能定位到修改的常量，不利於理解和維護。

4.【推薦】常量的複用層次有五層：跨應用共享常量、應用內共享常量、子工程內共享常量、包 內共享常量、類內共享常量。
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 定義。

OOP規範

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 值，能夠表示額外的資訊，如：遠端呼叫失敗，異常退出。
11.【強制】構造方法裡面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中
12.【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具：source> generate toString 時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。 說明：在方法執行丟擲異常時，可以直接呼叫 POJO 的 toString()方法列印其屬性值，便於排 查問題。
15.【推薦】 類內方法定義順序依次是：公有方法或保護方法 > 私有方法 > getter/setter 方法。 說明：公有方法是類的呼叫者和維護者最關心的方法，首屏展示最好；保護方法雖然只是子類 關心，也可能是“模板設計模式”下的核心方法；而私有方法外部一般不需要特別關心，是一個 黑盒實現；因為方法資訊價值較低，所有 Service 和 DAO 的 getter/setter 方法放在類體最 後。
16.【推薦】setter 方法中，引數名稱與類成員變數名稱一致，this.成員名 = 引數名。在 getter/setter 方法中，不要增加業務邏輯，增加排查問題的難度。

集合處理

1.【強制】關於 hashCode 和 equals 的處理，遵循如下規則： 1） 只要重寫 equals，就必須重寫 hashCode。 2） 因為 Set 儲存的是不重複的物件，依據 hashCode 和 equals 進行判斷，所以 Set 儲存的 物件必須重寫這兩個方法。 3） 如果自定義物件做為 Map 的鍵，那麼必須重寫 hashCode 和 equals。 說明：String 重寫了 hashCode 和 equals 方法，所以我們可以非常愉快地使用 String 物件 作為 key 來使用。
7.【強制】不要在 foreach 迴圈裡進行元素的 remove/add 操作。remove 元素請使用 Iterator 方式，如果併發操作，需要對 Iterator 物件加鎖。
正例：

Iterator<String> it = a.iterator();  
while (it.hasNext()) {              
    String temp = it.next();                       
    if (刪除元素的條件) {                               
        it.remove();                 
    }      
} 

反例：

List<String> a = new ArrayList<String>();       
a.add("1");       
a.add("2");       
for (String temp : a) {           
    if ("1".equals(temp)) {               
        a.remove(temp);           
    }       
} 

說明：以上程式碼的執行結果肯定會出乎大家的意料，那麼試一下把“1”換成“2”，會是同樣的 結果嗎？
9.【推薦】集合初始化時，指定集合初始值大小。
說明：HashMap 使用 HashMap(int initialCapacity) 初始化， 正例：initialCapacity = (需要儲存的元素個數 / 負載因子) + 1。注意負載因子（即loader factor）預設為 0.75，如果暫時無法確定初始值大小，請設定為 16。 反例：HashMap 需要放置 1024 個元素，由於沒有設定容量初始大小，隨著元素不斷增加，容 量 7 次被迫擴大，resize 需要重建 hash 表，嚴重影響效能。
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 值組合集合。

併發處理（其實這裡面的現在都不太明白）

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。
9.【強制】多執行緒並行處理定時任務時，Timer 執行多個 TimeTask 時，只要其中之一沒有捕獲 丟擲的異常，其它任務便會自動終止執行，使用 ScheduledExecutorService 則沒有這個問題。
14.【參考】 HashMap 在容量不夠進行 resize 時由於高併發可能出現死鏈，導致 CPU 飆升，在 開發過程中可以使用其它資料結構或加鎖來規避此風險。

控制語句

5.【推薦】迴圈體中的語句要考量效能，以下操作儘量移至迴圈體外處理，如定義物件、變數、 獲取資料庫連線，進行不必要的 try-catch 操作（這個 try-catch 是否可以移至迴圈體外）。
6.【推薦】介面入參保護，這種場景常見的是用於做批量操作的介面。
7.【參考】下列情形，需要進行引數校驗： 1） 呼叫頻次低的方法。 2） 執行時間開銷很大的方法。此情形中，引數校驗時間幾乎可以忽略不計，但如果因為參 數錯誤導致中間執行回退，或者錯誤，那得不償失。 3） 需要極高穩定性和可用性的方法。 4） 對外提供的開放介面，不管是 RPC/API/HTTP 介面。 5） 敏感許可權入口。
8.【參考】下列情形，不需要進行引數校驗： 1） 極有可能被迴圈呼叫的方法。但在方法說明裡必須註明外部引數檢查要求。 2） 底層呼叫頻度比較高的方法。畢竟是像純淨水過濾的最後一道，引數錯誤不太可能到底 層才會暴露問題。一般 DAO 層與 Service 層都在同一個應用中，部署在同一臺伺服器中，所 以 DAO 的引數校驗，可以省略。 3） 被宣告成 private 只會被自己程式碼所呼叫的方法，如果能夠確定呼叫方法的程式碼傳入參 數已經做過檢查或者肯定不會有問題，此時可以不校驗引數。

註釋規約

8.【參考】合理處理註釋掉的程式碼。在上方詳細說明，而不是簡單的註釋掉。如果無用，則刪除。 說明：程式碼被註釋掉有兩種可能性：1）後續會恢復此段程式碼邏輯。2）永久不用。前者如果沒 有備註資訊，難以知曉註釋動機。後者建議直接刪掉（程式碼倉庫儲存了歷史程式碼）。
9.【參考】對於註釋的要求：第一、能夠準確反應設計思想和程式碼邏輯；第二、能夠描述業務含 義，使別的程式設計師能夠迅速瞭解到程式碼背後的資訊。完全沒有註釋的大段程式碼對於閱讀者形同
天書，註釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；註釋也是給繼任者看 的，使其能夠快速接替自己的工作。
11.【參考】特殊註釋標記，請註明標記人與標記時間。注意及時處理這些標記，通過標記掃描， 經常清理此類標記。線上故障有時候就是來源於這些標記處的程式碼。 1） 待辦事宜（TODO）:（ 標記人，標記時間，[預計處理時間]） 表示需要實現，但目前還未實現的功能。這實際上是一個 Javadoc 的標籤，目前的 Javadoc 還沒有實現，但已經被廣泛使用。只能應用於類，介面和方法（因為它是一個 Javadoc 標籤）。
2） 錯誤，不能工作（FIXME）:（標記人，標記時間，[預計處理時間]） 在註釋中用 FIXME 標記某程式碼是錯誤的，而且不能工作，需要及時糾正的情況。

其它

2.【強制】velocity 呼叫 POJO 類的屬性時，建議直接使用屬性名取值即可，模板引擎會自動按 規範呼叫 POJO 的 getXxx()，如果是 boolean 基本資料型別變數（boolean 命名不需要加 is 字首），會自動呼叫 isXxx()方法。 說明：注意如果是 Boolean 包裝類物件，優先呼叫 getXxx()的方法。
3.【強制】後臺輸送給頁面的變數必須加!var——中間的感嘆號。說明：如果var=null或者不存在，那麼{var}會直接顯示在頁面上。
5.【強制】獲取當前毫秒數 System.currentTimeMillis(); 而不是 new Date().getTime(); 說明：如果想獲取更加精確的納秒級時間值，使用 System.nanoTime()的方式。在 JDK8 中， 針對統計時間等場景，推薦使用 Instant 類。

異常日誌

異常處理

9.【推薦】方法的返回值可以為 null，不強制返回空集合，或者空物件等，必須添加註釋充分 說明什麼情況下會返回 null 值。呼叫方需要進行 null 判斷防止 NPE 問題。 說明：本手冊明確防止 NPE 是呼叫者的責任。即使被呼叫方法返回空集合或者空物件，對呼叫
者來說，也並非高枕無憂，必須考慮到遠端呼叫失敗、序列化失敗、執行時異常等場景返回 null 的情況。
10.【推薦】防止 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.【參考】在程式碼中使用“拋異常”還是“返回錯誤碼”，對於公司外的 http/api 開放介面必須 使用“錯誤碼”；而應用內部推薦異常丟擲；跨應用間 RPC 呼叫優先考慮使用 Result 方式，封 裝 isSuccess()方法、“錯誤碼”、“錯誤簡簡訊息”。 說明：關於 RPC 方法返回方式使用 Result 方式的理由： 1）使用拋異常返回方式，呼叫方如果沒有捕獲到就會產生執行時錯誤。 2）如果不加棧資訊，只是 new 自定義異常，加入自己的理解的 error message，對於呼叫 端解決問題的幫助不會太多。如果加了棧資訊，在頻繁調用出錯的情況下，資料序列化和傳輸 的效能損耗也是問題。

日誌約束

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。
正例：
6.【強制】異常資訊應該包括兩類資訊：案發現場資訊和異常堆疊資訊。如果不處理，那麼通過 關鍵字 throws 往上丟擲。 正例：logger.error(各類引數或者物件 toString + “_” + e.getMessage(), e);
7.【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌；有選擇地輸出 info 日誌；如果使 用 warn 來記錄剛上線時的業務行為資訊，一定要注意日誌輸出量的問題，避免把伺服器磁碟 撐爆，並記得及時刪除這些觀察日誌。 說明：大量地輸出無效日誌，不利於系統性能提升，也不利於快速定位錯誤點。記錄日誌時請 思考：這些日誌真的有人看嗎？看到這條日誌你能做什麼？能不能給問題排查帶來好處？

MySQL資料庫

建表規則

1.【強制】表達是與否概念的欄位，必須使用 is_xxx 的方式命名，資料型別是 unsigned tinyint （ 1 表示是，0 表示否）。 說明：任何欄位如果為非負數，必須是 unsigned。 正例：表達邏輯刪除的欄位名 is_deleted，1 表示刪除，0 表示未刪除
3.【強制】表名不使用複數名詞。 說明：表名應該僅僅表示表裡面的實體內容，不應該表示實體數量，對應於 DO 類名也是單數 形式，符合表達習慣。
6.【強制】小數型別為 decimal，禁止使用 float 和 double。 說明：float 和 double 在儲存的時候，存在精度損失的問題，很可能在值的比較時，得到不 正確的結果。如果儲存的資料範圍超過 decimal 的範圍，建議將資料拆成整數和小數分開儲存。
8.【強制】varchar 是可變長字串，不預先分配儲存空間，長度不要超過 5000，如果儲存長 度大於此值，定義欄位型別為 text，獨立出來一張表，用主鍵來對應，避免影響其它欄位索 引效率。
9.【強制】表必備三欄位：id, gmt_create, gmt_modified。 說明：其中 id 必為主鍵，型別為 unsigned bigint、單表時自增、步長為 1。gmt_create, gmt_modified 的型別均為 date_time 型別。
13.【推薦】欄位允許適當冗餘，以提高查詢效能，但必須考慮資料一致。冗餘欄位應遵循： 1）不是頻繁修改的欄位。 2）不是 varchar 超長欄位，更不能是 text 欄位。 正例：商品類目名稱使用頻率高，欄位長度短，名稱基本一成不變，可在相關聯的表中冗餘存 儲類目名稱，避免關聯查詢。
14.【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。 說明：如果預計三年後的資料量根本達不到這個級別，請不要在建立表時就分庫分表。

索引約束

1.【強制】業務上具有唯一特性的欄位，即使是多個欄位的組合，也必須建成唯一索引。 說明：不要以為唯一索引影響了 insert 速度，這個速度損耗可以忽略，但提高查詢速度是明
顯的；另外，即使在應用層做了非常完善的校驗控制，只要沒有唯一索引，根據墨菲定律，必 然有髒資料產生。
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
9.【推薦】建組合索引的時候，區分度最高的在最左邊。 正例：如果 where a=? and b=? ，a 列的幾乎接近於唯一值，那麼只需要單建 idx_a 索引即 可。 說明：存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如：where a>? and b=? 那麼即使 a 的區分度更高，也必須把 b 放在索引的最前列。
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 IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;
7.【強制】禁止使用儲存過程，儲存過程難以除錯和擴充套件，更沒有移植性。
9.【推薦】in 操作能避免則避免，若實在避免不了，需要仔細評估 in 後邊的集合元素數量，控 制在 1000 個之內。

ORM對映

1.【強制】在表查詢中，一律不要使用 * 作為查詢的欄位列表，需要哪些欄位必須明確寫明。 說明：1）增加查詢分析器解析成本。2）增減欄位容易與 resultMap 配置不一致。
2.【強制】POJO 類的布林屬性不能加 is，而資料庫欄位必須加 is_，要求在 resultMap 中進行 欄位與屬性之間的對映。 說明：參見定義 POJO 類以及資料庫欄位定義規定，在中增加對映，是必須的。 在 MyBatis Generator 生成的程式碼中，需要進行對應的修改。
3.【強制】不要用 resultClass 當返回引數，即使所有類屬性名與資料庫欄位一一對應，也需 要定義；反過來，每一個表也必然有一個與之對應。 說明：配置對映關係，使欄位與 DO 類解耦，方便維護。
10.【參考】中的 compareValue 是與屬性值對比的常量，一般是數字，表示相等時帶 上此條件；表示不為空且不為 null 時執行；表示不為 null 值時 執行。