1.1 命名風格
（1）常量命名全部大寫，單詞間用下划線隔開。
（2）抽象類命名以Abstract或Base開頭；異常類命名以Exception結尾；測試類命名以它要測試的類名開始，以Test結尾。
（3）類型與中括號之間無空格定義數組（例：String[] args）。
（4）Boolean類型的變量不要加is前綴（例：Boolean isDeleted，它的方法名稱也是isDeleted()，會造成部分框架解析失敗）。
（5）包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞（例：com.pajk.util），統一使用單數形式。
（6）接口類中的方法和屬性不要加任何修飾符（public也不要加，例：void commit()），盡量不要在接口里定義變量，如果一定要定義，必須是與接口方法相關的，並且是整個應用的基礎常量。
（7）枚舉類成員名稱需要全部大寫，單詞間用下划線隔開（枚舉就是特殊的常量類，且構造方法被默認強制為私有）。
1.2 常量定義
（1）不允許任何魔法值（即沒有預先定義的常量）出現在代碼中（例：String key = "pajk"）。
（2）long或者Long初始化時，使用大寫的L，因為小寫的容易跟數字1混淆。
1.3 代碼格式
（1）相同參數類型，相同業務含義，才可以使用可變參數。
1.4 OOP規約
（1）不能使用過時的類或方法，過時的接口必須加@Deprecated注解，並清晰的說明新接口是什么。
（2）Object的equals方法容易拋NPE異常，JDK7建議使用java.util.Objects#equlas方法。
（3）所有包裝類型對象之間的比較，全部使用equals方法，不要用==判斷。
（4）POJO類屬性必須使用包裝數據類型，RPC方法的返回值和參數必須使用包裝數據類型（防止NPE異常），所有的局部變量使用基本數據類型。
（5）在定義DO/DTO/VO等POJO類時，不要設定任何屬性默認值。
（6）POJO類必須寫toString方法。IDE中工具 source-generate toString時，如果繼承了另一個POJO類，注意在前面加一下super.toString。
（7）類內推薦的方法定義順序：public > private > getter / setter 方法。
（8）getter / setter 方法中不要增加業務邏輯，否則會增加排查問題的難度。
（9）對象的clone方法是淺拷貝，若想實現深拷貝，需要重寫clone方法來實現屬性對象的拷貝。
（10）對任何類、方法、參數和變量，嚴控訪問范圍，過於寬泛的訪問范圍，不利於模塊解耦（例：如果是一個private方法，想刪除很簡單，public則要考慮很多東西）。
1.5 集合處理
（1）只要重寫equlas，就必須重寫hashCode。
（2）String重寫了hashCode和equals，所以很方便用來作為Map的key使用。
（3）subList返回的是ArrayList的內部類，只是ArrayList的一個視圖，並不能轉為ArrayList。
（4）集合轉數組的方法，必須使用集合的toArray(T[] array)，傳入的是類型完全一樣的數組，大小就是list.size()。
（5）數組轉集合的方法為Arrays.asList，體現的是適配器模式，后台的數據結構仍是數組，所以用該方法轉換后的集合不能修改內部元素。
（6）remove集合元素請使用Iterator方式，如果並發操作，需要對Iterator對象加鎖。
（7）HashMap的key和value可以為空，ConcurrentHashMap則不行。
（8）有序性（遍歷的結果是按某種比較規則排列的）和穩定性（每次遍歷的元素次序是一定的）的比較：ArrayList是order/unsort，HashMap是unorder/unsort，TreeSet是order/sort。
1.6 並發處理
（1）獲取單例對象需要保證線程安全，其中的方法也要保證線程安全。
（2）線程資源必須通過線程池提供。
（3）線程池不允許使用Executors創建，而是通過ThreadPoolExecutor的方式創建。
（4）SimpleDateFormat是線程不安全的類，一般不要定義為static變量，如果定義為static，必須加鎖，或者使用DateUtils工具類。
（5）如果是JDK8，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat。
（6）高並發場景中，同步調用要考慮鎖對性能的損耗。能用無鎖數據結構，就不要用鎖；能鎖區塊，就不要鎖整個方法體；能用對象鎖，就不要用類鎖。
（7）如果線程一需要對A、B、C依次全部加鎖后才可以進行更新操作，那么線程而的加鎖順序也必須是A、B、C，否則可能出現死鎖。
（8）要么在應用層加鎖，要么在緩存層加鎖，要么在數據庫層使用樂觀鎖。如果每次訪問沖突概率小於20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數不得小於3次。
1.7 控制語句
（1）在一個swtich塊內，都必須包含一個default語句並且放在最后，即使它什么代碼也沒有。
（2）在高並發場景中，避免使用“等於”判斷作為中斷或退出的條件，應使用大於或者小於的區間判斷來代替，因為如果並發控制沒有處理好，容易產生等值判斷被“擊穿”的情況。
（3）為了日后方便維護代碼，if-else應避免使用，就算使用，請勿超過3層，超過的話可以使用衛語句來代替（衛語句：就是把復雜的條件表達式拆分成多個條件表達式為真時，立刻從方法體返回給調用方，例：if(isBusy())）