白話阿里巴巴Java開發手冊高階篇

CSDN官方部落格發表於2020-01-20
阿里Java

不久前，阿里巴巴釋出了《阿里巴巴Java開發手冊》，總結了阿里巴巴內部實際專案開發過程中開發人員應該遵守的研發流程規範，這些流程規範在一定程度上能夠保證最終的專案交付質量，通過在時間中總結模式，並推廣給廣大開發人員，來避免研發人員在實踐中容易犯的錯誤，確保最終在大規模協作的專案中達成既定目標。

無獨有偶，筆者去年在公司裡負責升級和制定研發流程、設計模板、設計標準、程式碼標準等規範，並在實際工作中進行了應用和推廣，收效頗豐，也總結了適合支付平臺的技術規範，由於阿里巴巴Java開發手冊本身定位為規約和規範，語言簡單、精煉，沒有太多的解讀和示例，有些條款對於一般開發人員理解起來比較困難，本文藉著阿里巴巴釋出的Java開發手冊，詳細解讀Java平臺下開發規範和標準的制定和實施，強調那些在開發過程中需要重點關注的技術點，特別是解決某類已識別問題的模式和反模式。

異常處理

【強制】Java 類庫中定義的一類 RuntimeException 可以通過預先檢查進行規避，而不應該通過 catch 來處理，比如: IndexOutOfBoundsException，NullPointerException等等。

說明: 無法通過預檢查的異常除外，如在解析一個外部傳來的字串形式數字時，通過 catch NumberFormatException 來實現。

正例: if (obj != null) {…}

反例: try { obj.method() } catch (NullPointerException e) {…}

白話：
	
判空是一個永恆的話題，只要你不確定變數是否為空，都應該判空，否則後患無窮。

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

白話：
	
禁止使用異常來封裝業務邏輯，業務異常應該用錯誤碼來表示，系統異常則使用Java原生異常。

異常處理是通過異常表查詢來實現的，肯定沒有跳轉語句效能高。

【強制】對大段程式碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定程式碼和非穩定程式碼，穩定程式碼指的是無論如何不會出錯的程式碼。對於非穩定程式碼的catch儘可能進行區分異常型別，再做對應的異常處理。

白話：
	
做事要直切主題，不能一概而論。

不能簡單的catch Throwable，然後列印日誌，這是不負責任的表現，應該有針對的抓住和處理異常。

【強制】捕獲異常是為了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請 將該異常拋給它的呼叫者。最外層的業務使用者，必須處理異常，將其轉化為使用者可以理解的內容。

白話：	

禁止吃掉異常，吃掉異常就是捕獲異常什麼都沒做，也沒丟擲，這也是不負責任的表現。

是在不能處理的異常丟擲去，但是得讓使用方知道這種情況，這是程式設計提供方契約的一種方式。

【強制】有 try 塊放到了事務程式碼中，catch 異常後，如果需要回滾事務，一定要注意手動回滾事務。

白話：我們基本採用宣告式事務，出現異常需要回滾的情況，建議繼續丟擲異常讓宣告式事務自動回滾，不建議程式碼中手工控制事務。

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

白話：永恆的資源關閉原則。

【強制】不能在 finally 塊中使用 return，finally 塊中的 return 返回後方法結束執行，不會再執行 try 塊中的 return 語句。

白話：
	
確實會覆蓋try塊裡面的return語句。
	
思維不混亂的話，沒人會把return語句寫在finally語句裡。

【強制】捕獲異常與拋異常，必須是完全匹配，或者捕獲異常是拋異常的父類。

如果預期對方拋的是繡球，實際接到的是鉛球，就會產生意外情況。

白話：異常處理後，讓異常變得更小，而不是變大，大而化小，小而化了。

在這裡插入圖片描述
【推薦】方法的返回值可以為 null，不強制返回空集合，或者空物件等，必須新增註釋充分 說明什麼情況下會返回 null 值。呼叫方需要進行 null 判斷防止 NPE 問題。

說明: 本規約明確防止 NPE 是呼叫者的責任。即使被呼叫方法返回空集合或者空物件，對呼叫 者來說，也並非高枕無憂，必須考慮到遠端呼叫失敗，執行時異常等場景返回 null 的情況。

白話：如前面所說，只要不確定的變數，一定要判空，別自找麻煩。

【推薦】防止 NPE，是程式設計師的基本修養，注意 NPE 產生的場景:

  • 返回型別為包裝資料型別，有可能是null，返回int值時注意判空。

    反例: public int f() { return Integer 物件}; 如果為 null，自動解箱拋 NPE。

  • 資料庫的查詢結果可能為null。

  • 集合裡的元素即使isNotEmpty，取出的資料元素也可能為null。

  • 遠端呼叫返回物件，一律要求進行NPE判斷。

  • 對於Session中獲取的資料，建議NPE檢查，避免空指標。

  • 級聯呼叫obj.getA().getB().getC();一連串呼叫，易產生NPE。

正例: 可以使用 JDK8 的 Optional 類來防止 NPE 問題。

白話：判空，判空，快取的資料，別人的資料，都要判空。

【推薦】在程式碼中使用“拋異常”還是“返回錯誤碼”，對於公司外的 http/api 開放介面必須 使用“錯誤碼”;而應用內部推薦異常丟擲;跨應用間 RPC 呼叫優先考慮使用 Result 方式，封 裝 isSuccess、“錯誤碼”、“錯誤簡簡訊息”。

說明: 關於 RPC 方法返回方式使用 Result 方式的理由:

使用拋異常返回方式，呼叫方如果沒有捕獲到就會產生執行時錯誤。

如果不加棧資訊，只是new自定義異常，加入自己的理解的error message，對於呼叫端解決問題的幫助不會太多。如果加了棧資訊，在頻繁呼叫出錯的情況下，資料序列化和傳輸的效能損耗也是問題。

白話：
	
業務異常使用Result模式，系統異常用Java原生異常。

RPC建議使用Result模式，不想讓一個異常在系統間跳來跳去的，異常是包含呼叫棧的。

【推薦】定義時區分unchecked/checked 異常，避免直接使用RuntimeException丟擲， 更不允許丟擲 Exception 或者 Throwable，應使用有業務含義的自定義異常。推薦業界已定義 過的自定義異常，如:DAOException / ServiceException 等。

白話：
	
不要所有異常都整合自Runtime異常，希望呼叫方處理的異常一定用checked異常。

【參考】避免出現重複的程式碼(Don’t Repeat Yourself)，即DRY原則。

說明: 隨意複製和貼上程式碼，必然會導致程式碼的重複，在以後需要修改時，需要修改所有的副 本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是共用模組。

正例: 一個類中有多個 public 方法，都需要進行數行相同的引數校驗操作，這個時候請抽取:
private boolean checkParam(DTO dto) {...}

白話：如果不知道DRY原則，但是回顧你以前寫的程式碼都是這樣寫的，那麼恭喜你，你是個好程式設計師，也為你發愁。

併發處理

【強制】獲取單例物件需要保證執行緒安全，其中的方法也要保證執行緒安全。

說明: 資源驅動類、工具類、單例工廠類都需要注意。

白話：
    
如果延遲載入實現的單例需要併發控制；如果初始化的時候new單例物件，本身是執行緒安全的，取得例項方法不需要同步。

【強制】建立執行緒或執行緒池時請指定有意義的執行緒名稱，方便出錯時回溯。

正例:

public class TimerTaskThread extends Thread { 
    public TimerTaskThread() {
        super.setName("TimerTaskThread"); 
        ... 
    }
}

白話：寫程式碼的時候就要想到查bug的時候要用到什麼資訊，然後決定如何命名、列印日誌等。

【強制】執行緒資源必須通過執行緒池提供，不允許在應用中自行顯式建立執行緒。

說明: 使用執行緒池的好處是減少在建立和銷燬執行緒上所花的時間以及系統資源的開銷，解決資 源不足的問題。如果不使用執行緒池，有可能造成系統建立大量同類執行緒而導致消耗完記憶體或者 “過度切換”的問題。

白話：一個是使用執行緒池快取執行緒可以提高效率，另外執行緒池幫我們做了管理執行緒的事情，提供了優雅關機、interrupt等待IO的執行緒，飽和策略等功能。

【強制】執行緒池不允許使用 Executors 去建立，而是通過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同學更加明確執行緒池的執行規則，規避資源耗盡的風險。

說明: Executors 返回的執行緒池物件的弊端如下:

  • FixedThreadPool 和 SingleThreadPool: 允許的請求佇列長度為 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。

  • CachedThreadPool 和 ScheduledThreadPool: 允許的建立執行緒數量為 Integer.MAX_VALUE，可能會建立大量的執行緒，從而導致 OOM。

    白話：

    執行緒池如果沒有限制最大數量，執行緒池撐開的時候，由於記憶體不夠或者系統配置的最大執行緒數超出，都會產生oom: unalbe to create native thread。

一個元件的核心引數最好要顯式的傳入，不要預設，就像你交給屬下一個任務，任務的目標、原則、時間點、邊界都要明確，不能模糊處理一樣，免得扯皮。

【強制】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。

白話：
    
記住，打死你，我也不會把SimpleDateFormat共享到類中。

【強制】高併發時，同步呼叫應該去考量鎖的效能損耗。能用無鎖資料結構，就不要用鎖; 能鎖區塊，就不要鎖整個方法體; 能用物件鎖，就不要用類鎖。

白話：
    
優先無鎖，不用鎖能解決的一定不要用鎖，即使用鎖也要控制粒度，越細越好。

【強制】對多個資源、資料庫表、物件同時加鎖時，需要保持一致的加鎖順序，否則可能會造 成死鎖。

說明: 執行緒一需要對錶 A、B、C 依次全部加鎖後才可以進行更新操作，那麼執行緒二的加鎖順序也必須是 A、B、C，否則可能出現死鎖。

白話：
        
解決死鎖的方法：按順序鎖資源、超時、優先順序、死鎖檢測等。

可參考哲學家進餐問題學習更深入的併發機制。

【強制】併發修改同一記錄時，避免更新丟失，需要加鎖。要麼在應用層加鎖，要麼在快取加 鎖，要麼在資料庫層使用樂觀鎖，使用 version 作為更新依據。

說明: 如果每次訪問衝突概率小於 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次 數不得小於 3 次。

白話：
    
狀態流轉、維護可用餘額等最好直接利用資料庫的行級鎖，不需要顯式的加鎖。

【強制】多執行緒並行處理定時任務時，Timer 執行多個 TimerTask 時，只要其中之一沒有捕獲丟擲的異常，其它任務便會自動終止執行，使用 ScheduledExecutorService 則沒有這個問題。

白話：
    
執行緒執行體、任務最上層等一定要抓住Throwable並進行相應的處理，否則會使執行緒終止。

【推薦】使用 CountDownLatch 進行非同步轉同步操作，每個執行緒退出前必須呼叫 countDown 方法，執行緒執行程式碼注意 catch 異常，確保 countDown 方法可以執行，避免主執行緒無法執行至 await 方法，直到超時才返回結果。

說明: 注意，子執行緒丟擲異常堆疊，不能在主執行緒 try-catch 到。

白話：
    
請在try...finally語句裡執行countDown方法，與關閉資源類似。

【推薦】避免 Random 例項被多執行緒使用，雖然共享該例項是執行緒安全的，但會因競爭同一 seed 導致的效能下降。

說明: Random 例項包括 java.util.Random 的例項或者 Math.random()例項。

正例: 在 JDK7 之後，可以直接使用 API ThreadLocalRandom，在 JDK7 之前，可以做到每個執行緒一個例項。

白話：
    
可以把Random放在ThreadLocal裡，只在本執行緒中使用。

【推薦】在併發場景下，通過雙重檢查鎖(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...
}

白話：
    
網上對雙檢鎖有N多討論，這裡很負責任的告訴大家，只要不是特別老的JDK版本(1.4以下)，雙檢鎖是沒問題的。

【參考】volatile 解決多執行緒記憶體不可見問題。對於一寫多讀，是可以解決變數同步問題， 但是如果多寫，同樣無法解決執行緒安全問題。如果是 count++操作，使用如下類實現: AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推薦使用 LongAdder 物件，比 AtomicLong 效能更好(減少樂觀鎖的重試次數)。

白話：
    
volatile只有記憶體可見性語義，synchronized有互斥語義，一寫多讀使用volatile就可以，多寫就必須使用synchronized，fetch-mod-get也必須使用synchronized。

【參考】 HashMap 在容量不夠進行 resize 時由於高併發可能出現死鏈，導致 CPU 飆升，在開發過程中注意規避此風險。

白話：
    
開發程式的時候要預估使用量，根據使用量來設定初始值。

resize需要重建hash表，嚴重影響效能，會讓程式產生長尾的響應時間。

【參考】ThreadLocal 無法解決共享物件的更新問題，ThreadLocal 物件建議使用 static 修飾。這個變數是針對一個執行緒內所有操作共有的，所以設定為靜態變數，所有此類例項共享此靜態變數 ，也就是說在類第一次被使用時裝載，只分配一塊儲存空間，所有此類的物件(只 要是這個執行緒內定義的)都可以操控這個變數。

白話：
    
ThreadLocal實際上是一個從執行緒ID到變數的Map，每次取得ThreadLocal變數，實際上是先取得當前執行緒ID，再用當前執行緒ID取得關聯的變數。

ThreadLocal使用了WeakHashMap，在key被回收的時候，value也被回收了，不用擔心記憶體洩露。

日誌規約

【強制】應用中不可直接使用日誌系統(Log4j、Logback)中的 API，而應依賴使用日誌框架
SLF4J中的API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。

java
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);

白話：
	
使用slf4jAPI更爽更清新。

通過佔位符的方式不但程式碼清晰，物件的toString等方法也是根據日誌等級來呼叫的。

【強制】日誌檔案推薦至少儲存 15 天，因為有些異常具備以“周”為頻次發生的特點。

白話：
	
其實需要更長，有的線上事故覆盤週期更長，需要更長的日誌儲存。

這其實不是開發的職責，應該構建大資料日誌系統，比如：ELK等。

【強制】應用中的擴充套件日誌(如打點、臨時監控、訪問日誌等)命名方式:
appName_logType_logName.log。

logType: 日誌型別，推薦分類有stats/desc/monitor/visit 等;

logName: 日誌描述。

這種命名的好處: 通過檔名就可知道日誌檔案屬於什麼應用，什麼型別，什麼目的，也有利於歸類查詢。

正例: mppserver 應用中單獨監控時區轉換異常，如: mppserver_monitor_timeZoneConvert.log

說明: 推薦對日誌進行分類，錯誤日誌和業務日誌儘量分開存放，便於開發人員檢視，也便於 通過日誌對系統進行及時監控。

白話：
	
邏輯上分開更利於日誌管理。

效能上，機械硬碟如果是單檔案寫可以一定程度利用磁碟順序寫提高效能。

【強制】對 trace/debug/info 級別的日誌輸出，必須使用條件輸出形式或者使用佔位符的方 式。

說明: logger.debug("Processing trade with id: " + id + " symbol: " + symbol); 如果日誌級別是 warn，上述日誌不會列印，但是會執行字串拼接操作，如果 symbol 是物件， 會執行 toString()方法，浪費了系統資源，執行了上述操作，最終日誌卻沒有列印。

正例: (條件)

java
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
}

正例: (佔位符)

logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);

白話：
	
一定不要用字串相加，一定要用佔位符。

【強制】避免重複列印日誌，浪費磁碟空間，務必在 log4j.xml 中設定additivity=false。

正例: <logger name="com.taobao.dubbo.config" additivity="false">

白話：
	
日誌需要CPU處理，快取的時候需要佔用記憶體，列印過程中要佔用IO頻寬，儲存到磁碟又需要儲存空間，要綠色環保。

【強制】異常資訊應該包括兩類資訊: 案發現場資訊和異常堆疊資訊。如果不處理，那麼通過 關鍵字 throws 往上丟擲。

正例: logger.error(各類引數或者物件 toString + "_" + e.getMessage(), e);

白話：
	
列印日誌一定要包含環境，否則找bug的時候日誌對不上，勤奮愛幹活的人一下就聽懂我在說啥了。

【推薦】謹慎地記錄日誌。生產環境禁止輸出 debug 日誌;有選擇地輸出 info 日誌;如果使 用 warn 來記錄剛上線時的業務行為資訊，一定要注意日誌輸出量的問題，避免把伺服器磁碟撐爆，並記得及時刪除這些觀察日誌。

說明: 大量地輸出無效日誌，不利於系統效能升，也不利於快速定位錯誤點。記錄日誌時請思考:這些日誌真的有人看嗎?看到這條日誌你能做什麼?能不能給問題排查帶來好處?

白話：
	
我常常和小夥伴們說，寫程式碼的時候就要想到查bug的時候怎麼查，需要哪些日誌，列印日誌只需要列印核心內容，不要隨便就把物件json序列化列印出來，如果是列表會很大。

【參考】可以使用 warn 日誌級別來記錄使用者輸入引數錯誤的情況，避免使用者投訴時，無所適 從。注意日誌輸出的級別，error 級別只記錄系統邏輯出錯、異常等重要的錯誤資訊。如非必要，請不要在此場景打出 error 級別。

白話：
	
合理利用warn級別日誌，error級別日誌最重要，理想情況下生產上產生的error和warn日誌開發要定期的梳理。

安全規約

【強制】隸屬於使用者個人的頁面或者功能必須進行許可權控制校驗。

說明: 防止沒有做水平許可權校驗就可隨意訪問、修改、刪除別人的資料，比如檢視他人的私信內容、修改他人的訂單。

白話：
	
面向使用者的所有服務都要有許可權校驗。

後端服務沒有許可權校驗，也要有服務化平臺下的呼叫許可權管理。

【強制】使用者敏感資料禁止直接展示，必須對展示資料脫敏。

說明: 檢視個人手機號碼會顯示成:158****9119，隱藏中間 4 位，防止隱私洩露。

白話：
	
除了手機號，在金融領域會有更多的敏感資訊。

防洩露必須加密，防篡改必須簽名，防抵賴必須非對稱簽名。

【強制】使用者輸入的 SQL 引數嚴格使用引數繫結或者 METADATA 欄位值限定，防止 SQL 注入， 禁止字串拼接 SQL 訪問資料庫。

白話：
	
這條一般用程式碼檢查工具都會檢查出來。

開發人員千萬不要做字串連線SQL。

【強制】使用者請求傳入的任何引數必須做有效性驗證。

說明:

忽略引數校驗可能導致:

  • page size過大導致記憶體溢位。

  • 惡意order by導致資料庫慢查詢。

  • 任意重定向。

  • SQL隱碼攻擊。

  • 反序列化注入。

  • 正則輸入源串拒絕服務ReDoS.

說明: Java 程式碼用正則來驗證客戶端的輸入，有些正則寫法驗證普通使用者輸入沒有問題， 但是如果攻擊人員使用的是特殊構造的字串來驗證，有可能導致死迴圈的結果。

白話：
	
一般在框架層都要做特殊字元的過濾，包括：大於號、小於號、單引號等。

任何使用集合的時候，輸入引數是集合的時候，返回是集合的時候，一定要有條數的限制，不能無限大。

【強制】禁止向 HTML 頁面輸出未經安全過濾或未正確轉義的使用者資料。

白話：
	
系統的入口要堵住特殊字元，入口可能是web介面，也可能是開發的介面。

系統的出口也要堵住特殊字元，出口一般指的是web介面。

【強制】表單、AJAX 提交必須執行 CSRF 安全過濾。

說明: CSRF(Cross-site request forgery)跨站請求偽造是一類常見程式設計漏洞。對於存在 CSRF 漏洞的應用/網站，攻擊者可以事先構造好 URL，只要受害者使用者一訪問，後臺便在使用者 不知情情況下對資料庫中使用者引數進行相應修改。

白話：堵住系統的入口！

【強制】在使用平臺資源，譬如簡訊、郵件、電話、下單、支付，必須實現正確的防重放限制， 如數量限制、疲勞度控制、驗證碼校驗，避免被濫刷、資損。

說明: 如註冊時傳送驗證碼到手機，如果沒有限制次數和頻率，那麼可以利用此功能騷擾到其它使用者，並造成簡訊平臺資源浪費。

白話：針對使用者輸入，一定要做防禦式程式設計。

【推薦】發貼、評論、傳送即時訊息等使用者生成內容的場景必須實現防刷、文字內容違禁詞過濾等風控策略。

白話：這個一般是大資料部門提供決策資料，各個業務方埋點。

OOP 規約

【強制】避免通過一個類的物件引用訪問此類的靜態變數或靜態方法，無謂增加編譯器解析成
本，直接用類名來訪問即可。

白話：也不直觀，看呼叫程式碼看不出來是靜態方法，容易誤解。

【強制】所有的覆寫方法，必須加@Override 註解。

反例:getObject()與 get0bject()的問題。一個是字母的 O，一個是數字的 0，加@Override 可以準確判斷是否覆蓋成功。另外，如果在抽象類中對方法簽名進行修改，其實現類會馬上編譯報錯。

 白話：
    
Java和C++不一樣，C++是在父類先宣告虛擬函式子類才覆寫，Java是任何方法都能覆寫，也可以不覆寫，所以覆寫不覆寫是沒有編譯器檢查的，除非介面中某一個方法完全沒有被實現才會編譯報錯。

【強制】相同引數型別，相同業務含義，才可以使用 Java 的可變引數，避免使用 Object。

說明: 可變引數必須放置在引數列表的最後。(提倡同學們儘量不用可變引數程式設計)

正例: public User getUsers(String type, Integer... ids)

白話：用處不大，可以用過載方法或者陣列引數代替。

一般應用在日誌的 API 定義上，用於傳不定的日誌引數。

【強制】外部正在呼叫或者二方庫依賴的介面，不允許修改方法簽名，避免對介面呼叫方產生 影響。介面過時必須加@Deprecated 註解，並清晰地說明採用的新介面或者新服務是什麼。

白話：
    
設計時沒有考慮周全，需要改造介面，需要通過增加新介面，遷移後下線老介面的方式實現。

REST介面只能增加引數，不能減少引數，返回值的內容也是隻增不減。

【強制】不能使用過時的類或方法。

說明: java.net.URLDecoder 中的方法 decode(String encodeStr) 這個方法已經過時，應該使用雙引數 decode(String source, String encode)。介面提供方既然明確是過時介面，那麼有義務同時提供新的介面; 作為呼叫方來說，有義務去考證過時方法的新實現是什麼。

白話：
    
明確了責任和義務，介面提供方也有義務推動介面使用方儘早遷移，不要積累技術負債。

【強制】Object 的 equals 方法容易拋空指標異常，應使用常量或確定有值的物件來呼叫 equals。

正例: "test".equals(object);

反例: object.equals("test");

說明: 推薦使用java.util.Objects#equals (JDK7引入的工具類)

白話：常量比變數，永遠都不變的原則。

【強制】所有的相同型別的包裝類物件之間值的比較，全部使用 equals 方法比較。

說明: 對於Integer var = ?在-128至127之間的賦值，Integer物件是在 IntegerCache.cache 產生，會複用已有物件，這個區間內的 Integer 值可以直接使用==進行 判斷，但是這個區間之外的所有資料，都會在堆上產生，並不會複用已有物件，這是一個大坑， 推薦使用 equals 方法進行判斷。

白話：
    
Java世界裡相等請用equals方法，==表示物件相等，一般在框架開發中會用到。

關於基本資料型別與包裝資料型別的使用標準如下:

  • 【強制】所有的POJO類屬性必須使用包裝資料型別。

  • 【強制】RPC方法的返回值和引數必須使用包裝資料型別。

  • 【推薦】所有的區域性變數使用基本資料型別。

說明: POJO 類屬性沒有初值是提醒使用者在需要使用時，必須自己顯式地進行賦值，任何
NPE 問題，或者入庫檢查，都由使用者來保證。

正例: 資料庫的查詢結果可能是 null，因為自動拆箱，用基本資料型別接收有 NPE 風險。

反例: 比如顯示成交總額漲跌情況，即正負 x%，x 為基本資料型別，呼叫的 RPC 服務，呼叫不成功時，返回的是預設值，頁面顯示:0%，這是不合理的，應該顯示成中劃線-。所以包裝資料型別的 null 值，能夠表示額外的資訊，如:遠端呼叫失敗，異常退出。

白話：
    
其實包裝資料型別與基本資料型別相比，增加了一個null的狀態，可以攜帶更多的語義。

【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何屬性預設值。

反例: POJO類的gmtCreate預設值為new Date(); 但是這個屬性在資料提取時並沒有置入具體值，在更新其它欄位時又附帶更新了此欄位，導致建立時間被修改成當前時間。

白話： 
    
雖然這裡反例不太容易看懂，但是要記得持久領域物件之前由應用層統一賦值gmtCreate和gmtModify欄位。

【強制】序列化類新增屬性時，請不要修改 serialVersionUID 欄位，避免反序列失敗; 如 果完全不相容升級，避免反序列化混亂，那麼請修改 serialVersionUID 值。

說明:注意 serialVersionUID 不一致會丟擲序列化執行時異常。

白話：   
    
不到萬不得已不要使用JDK自身的序列化，機制很重，資訊冗餘有版本。

【強制】構造方法裡面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。

白話： 
    
這樣做一種是規範，程式碼清晰，還有就是異常堆疊上更容易識別出錯的方法和語句。

【強制】POJO 類必須寫 toString 方法。使用 IDE 的中工具:source> generate toString 時，如果繼承了另一個 POJO 類，注意在前面加一下 super.toString。

說明: 在方法執行丟擲異常時，可以直接呼叫 POJO 的 toString()方法列印其屬性值，便於排 查問題。

白話：
    
這裡還有一個大坑，寫toString的時候要保證不會發生NPE，有的時候toString呼叫例項變數的toString，例項變數由於某些原因為null，導致NPE，程式碼沒有處理好就終止，這個問題坑了好多次。

【推薦】使用索引訪問用 String 的 split 方法得到的陣列時，需做最後一個分隔符後有無內容的檢查，否則會有拋 IndexOutOfBoundsException 的風險。

說明:

String str = "a,b,c,,";			
String[] ary = str.split(","); //預期大於 3，結果是 3 
System.out.println(ary.length);	

白話： 
    
程式設計要留心眼，任何不確定的地方都要判斷、處理，否則掉到坑裡了自己爬出來很費勁。
    
Java程式設計判空的思想要實施縈繞在每個開發人員的腦海裡。

【推薦】當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一起， 便於閱讀。

白話： 這規範說的咋就和我的習慣一模一樣呢！

【推薦】 類內方法定義順序依次是: 公有方法或保護方法 > 私有方法 > getter/setter
方法。

說明: 公有方法是類的呼叫者和維護者最關心的方法，首屏展示最好; 保護方法雖然只是子類 關心，也可能是“模板設計模式”下的核心方法; 而私有方法外部一般不需要特別關心，是一個黑盒實現; 因為方法資訊價值較低，所有 Service 和 DAO 的 getter/setter 方法放在類體最 後。

白話：
        
我推薦把一套邏輯的共有方法、保護方法、私有方法放在一起，所有getter/setter放在最後，這樣感覺更有邏輯！

【推薦】setter 方法中，引數名稱與類成員變數名稱一致，this.成員名 = 引數名。在
getter/setter 方法中，儘量不要增加業務邏輯，增加排查問題的難度。

反例:

public Integer getData() { 
    if (true) {
        return data + 100; 
    } else {
        return data - 100; }
    }

白話：雙手贊成。

【推薦】迴圈體內，字串的連線方式，使用 StringBuilder 的 append 方法進行擴充套件。

反例:

    String str = "start";
    for (int I = 0; I < 100; i++) {
        str = str + "hello"; 
    }

說明: 反編譯出的位元組碼檔案顯示每次迴圈都會 new 出一個 StringBuilder 物件，然後進行 append 操作，最後通過 toString 方法返回 String 物件，造成記憶體資源浪費。

白話：
    
一定使用StringBuilder，不要使用StringBuffer，StringBuffer是執行緒安全的，太重。
    
我就一直想不明白Java編譯器為什麼不做個優化呢？

【推薦】下列情況，宣告成 final 會更有提示性:

  • 不需要重新賦值的變數，包括類屬性、區域性變數。

  • 物件引數前加final，表示不允許修改引用的指向。

  • 類方法確定不允許被重寫。

    白話：

    儘量多使用final關鍵字，保證編譯器的校驗機制起作用，也體現了“契約式程式設計”的思想。

【推薦】慎用 Object 的 clone 方法來拷貝物件。

說明: 物件的 clone 方法預設是淺拷貝，若想實現深拷貝需要重寫 clone 方法實現屬性物件的拷貝。

白話：  
    
最好是使用建構函式來重新構造物件，使用clone淺拷貝的時候，物件引用關係可能很複雜，不直觀，不好理解。

【推薦】類成員與方法訪問控制從嚴:

  • 如果不允許外部直接通過new來建立物件，那麼構造方法必須是private.

  • 工具類不允許有public或default構造方法。

  • 類非static成員變數並且與子類共享，必須是protected.

  • 類非static成員變數並且僅在本類使用，必須是private.

  • 類static成員變數如果僅在本類使用，必須是private.

  • 若是static成員變數，必須考慮是否為final.

  • 類成員方法只供類內部呼叫，必須是private.

  • 類成員方法只對繼承類公開，那麼限制為protected.

說明: 任何類、方法、引數、變數，嚴控訪問範圍。過寬泛的訪問範圍，不利於模組解耦。

思考: 如果是一個 private 的方法，想刪除就刪除，可是一個 public 的 Service 方法，或者一個 public 的成員變數，刪除一下，不得手心冒點汗嗎?變數像自己的小孩，儘量在自己的視 線內，變數作用域太大，如果無限制的到處跑，那麼你會擔心的。

白話：
    
沒什麼好說的，兩個詞，高內聚，低耦合，功能模組閉包，哦，是三個詞。

###集合處理

【強制】關於 hashCode 和 equals 的處理，遵循如下規則:

  • 只要重寫equals，就必須重寫hashCode.

  • 因為Set儲存的是不重複的物件，依據hashCode和equals進行判斷，所以Set儲存的物件必須重寫這兩個方法。

  • 如果自定義物件做為Map的鍵，那麼必須重寫hashCode和equals.

說明: String 重寫了 hashCode 和 equals 方法，所以我們可以非常愉快地使用 String 物件作為 key 來使用。

白話：  
    
Hash是個永恆的話題，大家可以看下times33和Murmurhash演算法。

【強制】ArrayList的subList結果不可強轉成ArrayList，否則會丟擲ClassCastException.

異常: java.util.RandomAccessSubList cannot be cast to java.util.ArrayList .

說明: subList 返回的是 ArrayList 的內部類 SubList，並不是 ArrayList ，而是 ArrayList 的一個檢視，對於SubList子列表的所有操作最終會反映到原列表上。

白話：  
    
這種問題本來測試可以測試到，但是開發永遠都不要有依賴測試的想法，一切靠自己，當然我們的測試人員都是很靠譜的。

【強制】 在 subList 場景中，高度注意對原集合元素個數的修改，會導致子列表的遍歷、增 加、刪除均產生ConcurrentModificationException 異常。

白話： 
    
如果一定要更改子列表，重新構造新的ArrayList，使用`public ArrayList(Collection<? extends E> c)`。

【強制】使用集合轉陣列的方法，必須使用集合的toArray(T[] array)，傳入的是型別完全 一樣的陣列，大小就是 list.size()。

說明: 使用 toArray 帶參方法，入參分配的陣列空間不夠大時，toArray 方法內部將重新分配記憶體空間，並返回新陣列地址; 如果陣列元素大於實際所需，下標為[ list.size() ]的陣列元素將被置為 null，其它陣列元素保持原值，因此最好將方法入引數組大小定義與集合元素個數一致。

正例:

 java    
    List<String> list = new ArrayList<String>(2); list.add("guan");
    list.add("bao");
    String[] array = new String[list.size()]; 
    array = list.toArray(array);

反例: 直接使用 toArray 無參方法存在問題，此方法返回值只能是 Object[]類，若強轉其它型別陣列將出現 ClassCastException 錯誤。

白話：
    
搞不懂Java編譯器為什麼不做優化，人用邏輯能推導的，程式一定可以自動實現。

【強制】使用工具類 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)也會隨之修改。

白話：

如果需要對asList返回的List做更改，可以構造新的ArrayList，使用`public ArrayList(Collection<? extends E> c)`構造器。

【強制】泛型萬用字元 < extends T> 來接收返回的資料，此寫法的泛型集合不能使用add方 法，而< super T>不能使用get方法，做為介面呼叫賦值時易出錯。

說明: 擴充套件說一下PECS(Producer Extends Consumer Super)原則: 1)頻繁往外讀取內容的，適合用上界 Extends。 2)經常往裡插入的，適合用下界 Super。

白話： `<extends T>`，必須是T或T的子類。

集合寫(add)： 因為不能確定集合例項化時用的是T或T的子類，所以沒有辦法寫。例如：List<? extends Number> foo = new ArrayList<Number/Integer/Double>()，你不能add Number，因為也可能是Integer或Double的List， 同理也不能add Integer或Double，即，extends T， 不能集合add。集合讀(get)： 只能讀出T型別的資料。< super T>， 必須是T或T的父類。集合寫(add)： 可以add T或T的子類。集合讀(get)： 不能確定從集合裡讀出的是哪個型別（可能是T也可能是T的父類，或者Object），所以沒有辦法使用get。例如：List<? super Integer> foo3 = new ArrayList<Integer/Number/Object>(); 只能保證get出來是Object。

下面是示例，test1和test2在編譯時都有錯誤提示。

package com.robert.javaspec;

import java.util.LinkedList;
import java.util.List;

/**
 * Created by WangMeng on 2017-04-13.
 * FIX ME
 */
public class Main {
    public static void main(String[] args) {

    }

    public void test1(){
        List<? extends A> childofa=new LinkedList<>();
        B b=new B();
        A a=new A();
        childofa.add(a);
        childofa.add(b);
        A ta= childofa.get(0);
    }

    public void test2(){
        List<? super B> superOfb = new LinkedList<>();
        B b = new B();
        A a = new A();
        superOfb.add(a);
        superOfb.add(b);
        A ta = superOfb.get(0);
        B tb = superOfb.get(0);
    }
}

class A {
    @Override
    public String toString() {
        return "A";
    }
}

class B extends A {

    @Override
    public String toString() {
        return "B";
    }
}

【強制】不要在 foreach 迴圈裡進行元素的 remove/add 操作。remove 元素請使用 Iterator 方式，如果併發操作，需要對 Iterator 物件加鎖。

反例:

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”，會是同樣的結果嗎?

正例:

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

白話：修改一定要使用Iterator。

反例中改成2，丟擲ConcurrentModificationException，因為2是陣列的結束邊界。

【強制】 在 JDK7 版本及以上，Comparator 要滿足如下三個條件，不然 Arrays.sort， Collections.sort 會報 IllegalArgumentException 異常。

說明:

x，y的比較結果和y，x的比較結果相反。

x>y，y>z，則x>z。

x=y，則x，z比較結果和y，z比較結果相同。

反例: 下例中沒有處理相等的情況，實際使用中可能會出現異常:

new Comparator<Student>() {
    @Override
    public int compare(Student o1, Student o2) {
        return o1.getId() > o2.getId() ? 1 : -1; 
    }
}

白話：
    
除非邏輯混亂，否則這些條件都能滿足。

【推薦】集合初始化時，儘量指定集合初始值大小。

說明: ArrayList儘量使用ArrayList(int initialCapacity) 初始化。

白話：
        
預估陣列大小，能夠提高程式效率，寫程式碼的時候腦袋裡面要有執行的思想。

想了解效能和容量評估，請參考網際網路效能與容量評估的方法論和典型案例。

【推薦】使用 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 值組合集合。

白話：    

寫程式碼其實就是在程式設計師腦袋裡執行程式碼的過程，直覺就是兩次肯定不如一次做完事更快。

【推薦】高度注意 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 異常。

白話：
    
儲存null值場景不多，在防止快取穿透的情況下，有的時候會快取null key。

【參考】合理利用好集合的有序性(sort)和穩定性(order)，避免集合的無序性(unsort)和 不穩定性(unorder)帶來的負面影響。

說明: 有序性是指遍歷的結果是按某種比較規則依次排列的。穩定性指集合每次遍歷的元素次 序是一定的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort。

白話：
    
對於HashMap理論上是無序的，我做了個試驗，每次輸出都是穩定的。

數值：

HashMap<Integer, Integer> map = new HashMap<Integer, Integer>();
    
map.put(3, 3);
map.put(1, 1);
map.put(2, 2);
map.put(4, 4);

for (Entry<Integer, Integer> entry : map.entrySet()) {
    System.out.println(entry.getKey());
}

事實證明，每次輸出也是1、2、3、4，有序並且穩定的。

字串值：

HashMap<String, String> map = new HashMap<String, String>();
    
map.put("3000", "3");
map.put("1000", "1");
map.put("2000", "2");
map.put("4000", "4");

for (Entry<Integer, Integer> entry : map.entrySet()) {
    System.out.println(entry.getKey());
}

事實證明，每次輸出也是4000、1000、2000、3000，無序但是穩定的。

與阿里專家諮詢，這裡HashMap不穩定性是指rehash後輸出順序則會變化。

【參考】利用 Set 元素唯一的特性，可以快速對一個集合進行去重操作，避免使用 List 的 contains 方法進行遍歷、對比、去重操作。

白話：

如果不需要精確去重，參考布隆過濾器（Bloom Filter）。

控制語句

【強制】在一個 switch 塊內，每個 case 要麼通過 break/return 等來終止，要麼註釋說明程式將繼續執行到哪一個 case 為止;在一個 switch 塊內，都必須包含一個 default 語句並且放在最後，即使它什麼程式碼也沒有。

白話：
    
最好每個case都用break結束，不要組合幾個分支到一個邏輯，太不直觀。

【強制】在 if/else/for/while/do 語句中必須使用大括號，即使只有一行程式碼，避免使用 下面的形式:if (condition) statements;

白話：
    
這條有歧義，個人認為有的時候就一行語句不加也可以。

【推薦】推薦儘量少用 else， if-else 的方式可以改寫成:

if (condition) { ...
    return obj; 
}
// 接著寫 else 的業務邏輯程式碼;

說明: 如果非得使用if()…else if()…else…方式表達邏輯，【強制】請勿超過3層， 超過請使用狀態設計模式。

正例: 邏輯上超過 3 層的 if-else 程式碼可以使用衛語句，或者狀態模式來實現。

白話：
    
朋友說超過三層考慮狀態設計模式也不完全正確，大概可以理解為多層的邏輯巢狀不是好的程式碼風格，需要使用對應的重構方法做出優化，而每種壞味都有對應的優化方法和步驟，以及優缺點限制條件。

寫程式一定要遵守紅花綠葉原則，主邏輯放在主方法中，這是紅花，子邏輯封裝成小方法呼叫，這是綠葉，不要把不同層次的邏輯寫在一個大方法體裡，很難理解，就像綠葉把紅花擋住了，誰還能看到。舉例說明：

public void handleProcess() {
    // 骨架邏輯
    validate();
    doProcess();
    declareResource();
}

普及一下，如下類似排比句的程式碼就是衛語句，以前每天都這麼寫但是還真是剛剛知道這叫衛語句:)

public double getPayAmount() {  
   if (isDead()) return deadPayAmount();  
   if (isSeparated()) return separatedPayAmount();  
   if (isRetired()) return retiredPayAmount();  
   return normalPayAmount();  
     
}

不提倡的寫法：

public double getPayAmount() {  
   if (isDead()) 
       return deadPayAmount();  
   else if (isSeparated()) 
       return separatedPayAmount();  
   else if (isRetired())
       return retiredPayAmount();  
   else 
       return normalPayAmount();  
}

【推薦】除常用方法(如 getXxx/isXxx)等外，不要在條件判斷中執行其它複雜的語句，將復 雜邏輯判斷的結果賦值給一個有意義的布林變數名，以提高可讀性。

說明: 很多 if 語句內的邏輯相當複雜，閱讀者需要分析條件表示式的最終結果，才能明確什麼 樣的條件執行什麼樣的語句，那麼，如果閱讀者分析邏輯表示式錯誤呢?

正例:

//虛擬碼如下
boolean existed = (file.open(fileName, "w") != null) && (...) || (...); 
if (existed) {
    ... 
}

反例:

if ((file.open(fileName, "w") != null) && (...) || (...)) { ...}

白話：
    
這個反例真的經常見到，寫這個程式碼的人自己不覺得這樣很難看嗎？

【推薦】迴圈體中的語句要考量效能，以下操作儘量移至迴圈體外處理，如定義物件、變數、
獲取資料庫連線，進行不必要的 try-catch 操作(這個 try-catch 是否可以移至迴圈體外)。

白話：
    
切記，迴圈體內儘量不要獲取資源、不要處理異常。

【推薦】介面入參保護，這種場景常見的是用於做批量操作的介面。

白話：
    
用白話說，就是控制批量引數的數量，一次不能太多，否則記憶體溢位。

【參考】方法中需要進行引數校驗的場景:

  1. 呼叫頻次低的方法。

  2. 執行時間開銷很大的方法，引數校驗時間幾乎可以忽略不計，但如果因為引數錯誤導致中間執行回退，或者錯誤，那得不償失。

  3. 需要極高穩定性和可用性的方法。

  4. 對外提供的開放介面，不管是RPC/API/HTTP介面。

  5. 敏感許可權入口。

    白話：

    在這個框框內，根據業務適當調整是可以的。

【參考】方法中不需要引數校驗的場景:

  1. 極有可能被迴圈呼叫的方法，不建議對引數進行校驗。但在方法說明裡必須註明外部參
    數檢查要求。

  2. 底層的方法呼叫頻度都比較高，一般不校驗。畢竟是像純淨水過濾的最後一道，引數錯誤不太可能到底層才會暴露問題。一般 DAO 層與 Service 層都在同一個應用中，部署在同一 臺伺服器中，所以 DAO 的引數校驗，可以省略。

  3. 被宣告成private只會被自己程式碼所呼叫的方法，如果能夠確定呼叫方法的程式碼傳入引數已經做過檢查或者肯定不會有問題，此時可以不校驗引數。

    白話：

    在這個框框裡，根據業務適當調整是可以的。

命名規約

【強制】 程式碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。

反例: _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

白話：
        
約定俗稱的名稱或者縮寫例外。

ID為簡寫，Id和ID均可。

【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

正例: MAX_STOCK_COUNT

反例: MAX_COUNT

白話：
    
必須全部大寫，除了字母數字只可以使用下劃線，並且不能用在開頭和結尾。

【強制】抽象類命名使用 Abstract 或 Base 開頭;異常類命名使用 Exception 結尾;測試類命名以它要測試的類的名稱開始，以 Test 結尾。

白話：
    
家裡放一瓶敵敵畏，上面不寫標籤，萬一喝大了、渴了、喝了、就慘了，你懂的。

【強制】中括號是陣列型別的一部分，陣列定義如下:String[] args;

反例: 使用String args[]的方式來定義。

白話：
    
這種語法編譯器也認，但是我們畢竟寫Java程式，而不是寫C/C++程式。

這怪Java編譯器小組，一開始就不應該支援這種語法。

【強制】POJO 類中布林型別的變數，都不要加 is，否則部分框架解析會引起序列化錯誤。

反例: 定義為基本資料型別Boolean isSuccess;的屬性，它的方法也是isSuccess()，RPC 框架在反向解析的時候，“以為”對應的屬性名稱是 success，導致屬性獲取不到，進而丟擲異常。

白話：
    
一些框架使用getter和setter做序列化，有的根據屬性本身取值，帶了is字首就找不到了，變數名不要帶be動詞，語法不對，英文補考！

【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用 單數形式，但是類名如果有複數含義，類名可以使用複數形式。

正例: 應用工具類包名為com.alibaba.open.util、類名為MessageUtils(此規則參考 spring 的框架結構)

白話：
    
包名大寫、帶下劃線等，不專業、難看、不高大上。

【強制】杜絕完全不規範的縮寫，避免望文不知義。

反例: AbstractClass“縮寫”命名成 AbsClass;condition“縮寫”命名成 condi，此類 隨意縮寫嚴重降低了程式碼的可閱讀性。

白話：

不要太摳，不是太長的名字直接寫上就好，編譯器編譯優化後變數名將不存在，會編譯成相對於方法堆疊bp指標地址的相對地址，長變數名不會佔用更多空間。

英文中的縮寫有個慣例，去掉母音留下子音即可，不能亂縮寫。

【推薦】如果使用到了設計模式，建議在類名中體現出具體模式。

說明: 將設計模式體現在名字中，有利於閱讀者快速理解架構設計思想。

正例:

public class OrderFactory;

public class LoginProxy;

public class ResourceObserver;

白話：
    
讓全世界都知道你會設計模式，這是個崇尚顯擺的社會。

【推薦】介面類中的方法和屬性不要加任何修飾符號(public 也不要加)，保持程式碼的簡潔 性，並加上有效的 Javadoc 註釋。儘量不要在介面裡定義變數，如果一定要定義變數，肯定是與介面方法相關，並且是整個應用的基礎常量。

正例: 介面方法簽名:void f();介面基礎常量表示:String COMPANY = “alibaba”;

反例: 介面方法定義:public abstract void f();

說明:JDK8 中介面允許有預設實現，那麼這個 default 方法，是對所有實現類都有價值的默 認實現。

白話：脫了褲子放屁始終有點麻煩。

介面和實現類的命名有兩套規則:

【強制】對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務一定是介面，內部的實現類用 Impl 的字尾與介面區別。

正例: CacheServiceImpl 實現 CacheService 介面。

【推薦】 如果是形容能力的介面名稱，取對應的形容詞做介面名(通常是–able 的形式)。

正例: AbstractTranslator 實現 Translatable。

白話：
    
嚴重同意！可是想想Observer和Observable，我就不說話了。

【參考】列舉類名建議帶上 Enum 字尾，列舉成員名稱需要全大寫，單詞間用下劃線隔開。

說明: 列舉其實就是特殊的常量類，且構造方法被預設強制是私有。

正例: 列舉名字:DealStatusEnum，成員名稱: SUCCESS / UNKOWN_REASON。

白話：
    
不要駝峰！記住列舉不要駝峰！總是有好多人列舉用駝峰。

【參考】各層命名規約:

  • Service/DAO層方法命名規約：

  • 獲取單個物件的方法用get做字首。

  • 獲取多個物件的方法用list做字首。

  • 獲取統計值的方法用count做字首。

  • 插入的方法用save(推薦)或insert做字首。

  • 刪除的方法用remove(推薦)或delete做字首。

  • 修改的方法用update做字首。

  • 領域模型命名規約：

  • 資料物件:xxxDO，xxx即為資料表名。

  • 資料傳輸物件:xxxDTO，xxx為業務領域相關的名稱。

  • 展示物件:xxxVO，xxx一般為網頁名稱。

  • POJO是DO/DTO/BO/VO的統稱，禁止命名成xxxPOJO。

    白話：大家都這麼認為很重要。

常量定義

【強制】不允許出現任何魔法值(即未經定義的常量)直接出現在程式碼中。

反例: String key = "Id#taobao_"+tradeId; cache.put(key, value);

白話：
    
這個不用說了，隨地吐痰和隨地大小便是不應該的，新加坡是要鞭刑的！

【強制】long 或者 Long 初始賦值時，必須使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，造成誤解。

說明: Long a = 2l; 寫的是數字的21，還是Long型的2?

白話：
    
看看區塊鏈中用了base58，而不是base64，秒懂什麼是從使用者角度考慮產品設計！

【推薦】不要使用一個常量類維護所有常量，應該按常量功能進行歸類，分開維護。如:快取相關的常量放在類: CacheConsts 下; 系統配置相關的常量放在類: ConfigConsts 下。

說明: 大而全的常量類，非得使用查詢功能才能定位到修改的常量，不利於理解和維護。

白話：
    
儘量讓功能自閉包，標準是一個小模組拷貝出去直接就能用，而不是缺這缺那的，是不是讀者很多時候拷貝了一套類，執行時候發現不能用，缺常量，把常量類拷貝過來，發現常量類中有很多不相關的常量，還得清理。

【推薦】常量的複用層次有五層: 跨應用共享常量、應用內共享常量、子工程內共享常量、包內共享常量、類內共享常量。

跨應用共享常量: 放置在二方庫中，通常是client.jar中的constant目錄下。

應用內共享常量: 放置在一方庫的modules中的constant目錄下。

反例: 易懂變數也要統一定義成應用內共享常量，兩位攻城師在兩個類中分別定義了表示 “是”的變數:

類A中: public static final String YES = "yes";

類B中: public static final String YES = "y"; A.YES.equals(B.YES)，預期是 true，但實際返回為 false，導致產生線上問題。

子工程內部共享常量: 即在當前子工程的constant目錄下。

包內共享常量: 即在當前包下單獨的constant目錄下。

類內共享常量: 直接在類內部private static final定義。

白話：
    
一方庫、二方庫、三方庫，叫法很專業，放在離自己最近的上面一個層次即可。

【推薦】如果變數值僅在一個範圍內變化用 Enum 類。如果還帶有名稱之外的延伸屬性，必須 使用 Enum 類，下面正例中的數字就是延伸資訊，表示星期幾。

正例: public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}

白話：

列舉值需要定義延伸屬性的場景通常是要持久資料庫，或者顯示在介面上。

格式規約

【強制】大括號的使用約定。如果是大括號內為空，則簡潔地寫成{}即可，不需要換行; 如果 是非空程式碼塊則:

  • 左大括號前不換行。

  • 左大括號後換行。

  • 右大括號前換行。

  • 右大括號後還有else等程式碼則不換行;表示終止右大括號後必須換行。

    白話：

    好風格，討厭那種左大括號前換行的，看不慣。

【強制】 左括號和後一個字元之間不出現空格; 同樣，右括號和前一個字元之間也不出現空 格。詳見第 5 條下方正例提示。

白話：
    
程式寫完可以用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程式的時候有個習慣，每次謝了一段程式碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。

【強制】if/for/while/switch/do 等保留字與左右括號之間都必須加空格。

白話：
    
程式寫完可以用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程式的時候有個習慣，每次謝了一段程式碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。

【強制】任何運算子左右必須加一個空格。

說明: 運算子包括賦值運算子=、邏輯運算子&&、加減乘除符號、三目運算子等。

白話：
    
程式寫完可以用編輯器的格式化功能格式化，Eclipse中快捷鍵是shift+alt+f，筆者寫程式的時候有個習慣，每次謝了一段程式碼都會按ctrl+alt+o、ctrl+alt+f、ctrl+s，相信會有相同習慣的同行。

【強制】縮排採用 4 個空格，禁止使用 tab 字元。

說明: 如果使用 tab 縮排，必須設定 1 個 tab 為 4 個空格。IDEA 設定 tab 為 4 個空格時，請勿勾選Use tab character; 而在 eclipse 中，必須勾選 insert spaces for tabs。

正例: (涉及1-5點)

public static void main(String[] args) {
    // 縮排 4 個空格
    String say = "hello";
    // 運算子的左右必須有一個空格
    int flag = 0;
    // 關鍵詞 if 與括號之間必須有一個空格，括號內的 f 與左括號，0 與右括號不需要空格     
    if (flag == 0) {
        System.out.println(say);
    }
    // 左大括號前加空格且不換行;左大括號後換行 
    if (flag == 1) {
        System.out.println("world");
        // 右大括號前換行，右大括號後有 else，不用換行
    } else { System.out.println("ok");
        // 在右大括號後直接結束，則必須換行
    }
}

白話：
    
這樣看慣了，怎麼看怎麼清晰。

【強制】單行字元數限制不超過 120 個，超出需要換行，換行時遵循如下原則:

  • 第二行相對第一行縮排 4 個空格，從第三行開始，不再繼續縮排，參考示例。

  • 運算子與下文一起換行。

  • 方法呼叫的點符號與下文一起換行。

  • 在多個引數超長，逗號後進行換行。

  • 在括號前不要換行，見反例。

正例:

StringBuffer sb = new StringBuffer();
//超過 120 個字元的情況下，換行縮排 4 個空格，並且方法前的點符號一起換行     
sb.append("zi").append("xin")...
      .append("huang")...
      .append("huang")...
      .append("huang");

反例:

StringBuffer sb = new StringBuffer();
//超過 120 個字元的情況下，不要在括號前換行      
sb.append("zi").append("xin")...append
    ("huang");
    
//引數很多的方法呼叫可能超過 120 個字元，不要在逗號前換行 
method(args1,   args2, args3, ...
, argsX);

白話：
    
一行程式碼儘量不要寫太長，長了拆開不就得了。

【強制】方法引數在定義和傳入時，多個引數逗號後邊必須加空格。

正例: 下例中實參的"a", 後邊必須要有一個空格。

method("a", "b", "c");

白話：
    
不加空格太擠了，就像人沒長開似得。

【強制】IDE的text file encoding設定為UTF-8; IDE中檔案的換行符使用Unix格式， 不要使用 windows 格式。

白話：
    
請不要用GB字符集，換了環境總有問題，Java程式多數跑在Linux上，當然要用Unix換行符。

【推薦】沒有必要增加若干空格來使某一行的字元與上一行的相應字元對齊。

正例:

int a = 3;		
long b = 4L;		
float c = 5F;		
StringBuffer sb = new StringBuffer();

說明: 增加 sb 這個變數，如果需要對齊，則給 a、b、c 都要增加幾個空格，在變數比較多的 情況下，是一種累贅的事情。

白話：
    
沒必要，沒必要，那樣反而不好看。

【推薦】方法體內的執行語句組、變數的定義語句組、不同的業務邏輯之間或者不同的語義
之間插入一個空行。相同業務邏輯和語義之間不需要插入空行。

說明: 沒有必要插入多行空格進行隔開。

白話：
    
和我的習慣一樣一樣的，一段邏輯空一行。

在這裡插入圖片描述

本文首發於GitChat，未經授權不得轉載，轉載需與GitChat聯絡。
原文地址：https://gitchat.csdn.net/activity/58ff50f5831cb45b69937ec5

相關文章