當前位置：首頁 > 编程语言 > java >内容正文

java

[转]白话阿里巴巴Java开发手册高级篇

發布時間：2023/12/4 java 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 [转]白话阿里巴巴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>() { @Overrideprotected 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，否則可能出現死鎖。

白話：解決死鎖的方法：按順序鎖資源、超時、優先級、死鎖檢測等?？蓞⒖颊軐W家進餐問題學習更深入的并發機制。

【強制】并發修改同一記錄時，避免更新丟失，需要加鎖。要么在應用層加鎖，要么在緩存加鎖，要么在數據庫層使用樂觀鎖，使用 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 {@Overridepublic String toString() {return "A";} }class B extends A {@Overridepublic 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>() {@Overridepublic 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 值的情況，如下表格:

集合類KeyValueSuper說明

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 是否可以移至循環體外)。

白話：切記，循環體內盡量不要獲取資源、不要處理異常。

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

白話：用白話說，就是控制批量參數的數量，一次不能太多，否則內存溢出。

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

調用頻次低的方法。

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

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

對外提供的開放接口，不管是RPC/API/HTTP接口。

敏感權限入口。

白話：

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

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

極有可能被循環調用的方法，不建議對參數進行校驗。但在方法說明里必須注明外部參
數檢查要求。

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

被聲明成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 等保留字與左右括號之間都必須加空格。

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

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

【強制】縮進采用 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 都要增加幾個空格，在變量比較多的情況下，是一種累贅的事情。

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

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

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

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

---------------------
作者：CSDN官方博客
來源：CSDN
原文：https://blog.csdn.net/blogdevteam/article/details/102975554
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件

總結

以上是生活随笔為你收集整理的[转]白话阿里巴巴Java开发手册高级篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： [转]《吐血整理》系列-顶级程序员工具集
下一篇： Navicat Premium 64 b