public int    a = 1;  
    public String b = 2;  
    public float  c = 2.0;

OOP规约

强制

1. 避免使用一个类的对象来引用该类的静态变量或静态方法。无谓增加编译器解析成本, 直接用类名来访问即可。

2. 所有的覆写方法, 必须加 @Override 注解

   • 例如 getObject() 与 get0bject() 的问题, 前者是字母o,后者是数字0 通过使用覆盖的注解, 可以准确判断是否覆盖成功
   • 另外, 如果在抽象类中对方法签名进行修改, 其实现类 会立即编译报错

3. 相同参数类型, 相同业务含义, 才可以使用Java的可变参数, 避免使用Object.

   • 说明: 可变参数必须放置在参数列表的最后。 提倡尽量不用可变参数编程
   • 正例: public User getUsers(String type, Integer... ids) {...}

4. 外部正在调用或者二方库依赖的接口, 不允许修改方法签名, 避免对接口调用方产生影响。

   • 接口过时必须加 @Deprecated 注解, 并清晰地说明采用的新接口或者新服务是什么。

5. 不能使用过时的类或方法

   • 说明: java.net.URLDecoder 中的方法 decode(String encodeStr) 这个方法已经过时,
   • 应该使用双参数 decode(String source, String encode)。接口提供方既然明确是过时接口,
   • 那么有义务同时提供新的接口; 作为调用方来说, 有义务去考证过时方法的新实现是什么。

6. Object 的 equals 方法容易抛空指针异常, 应使用常量或确定有值的对象来调用equals。

   • 使用 "t".equals(test)方式
   • 推荐使用java.util.Object.equals (jdk7引入的工具类)

7. 所有的相同类型的包装类对象之间的 值的比较 , 全部使用equals方法比较,

   • 注意: 对于 Integer var = ? 在 -128 至 127 范围内的赋值, Integer 对象是在IntegerCache.cache 产生, 会复用已有对象,
   • 这个区间内的 Integer 值可以直接使用 == 进行判断, 但是这个区间之外的所有数据, 都会在堆上产生, 并不会复用已有对象, 所以 == 就会失效
   • 这是一个大坑！, 推荐统一使用 equals 方法进行判断

8. 关于基本数据类型与包装数据类型的使用标准如下:

   • 所有的 POJO 类属性必须使用包装数据类型。
   • RPC 方法的 返回值 和 参数 必须使用包装数据类型
   • 所有的局部变量 推荐使用基本数据类型
   • 说明: POJO 类属性没有初值是提醒使用者在需要使用时, 必须自己显式地进行赋值, 任何NPE 问题, 或者入库检查, 都由使用者来保证。
     • 数据库的查询结果可能是 null, 因为自动拆箱, 用基本数据类型接收有 NPE 风险。
   • 反例: 比如显示成交总额涨跌情况, 即正负 x%, x 为基本数据类型, 调用的 RPC 服务, 调用不成功时, 返回的是默认值,
     • 页面显示为 0%, 这是不合理的, 应该显示成中划线。所以包装数据类型的 null 值, 能够表示额外的信息
     • 如: 远程调用失败, 异常退出。

9. 定义 DO/DTO/VO等POJO类时, 不要给任何成员属性设定 默认值

   • 反例: POJO 类的 createTime属性 默认值为 new Date();
     • 但是这个属性在数据提取时并没有置入具体值, 在更新其它字段时又附带更新了此字段, 导致创建时间被修改成当前时间。

10. 序列化类新增属性时, 不要修改serialVersionUID字段, 避免反序列化失败

    • 如果完全不兼容升级, 为了避免反序列化混乱, 就需要修改serialVersionUID的值 (idea可以配置使用快捷键自动生成)
    • 说明: 当 serialVersionUID 不一致会抛出序列化运行时异常。

11. 构造方法里面禁止加入任何业务逻辑, 如果有初始化逻辑, 请放在 init 方法中。

12. POJO 类必须写 toString 方法。 如果继承了另一个 POJO 类, 注意在前面加一下 super.toString() lombok解救众生

    • 说明: 在方法执行抛出异常时, 可以直接调用 POJO 的 toString()方法打印其属性值, 便于排查问题

推荐

1. 使用索引访问用 String 的 split 方法得到的数组时, 需做最后一个分隔符后有无内容的检查, 否则会有 IndexOutOfBoundsException 的风险。

   • System.out.println("a,b,c,,".split(",").length); 预期是大于3,结果却是3

2. 当一个类有多个构造方法, 或者多个同名方法, 这些方法应该按顺序放置在一起, 优于下条规则

3. 类内方法的定义顺序依次是 共有方法或保护方法 -> 私有方法 -> setter/getter方法(lombok可省)

   • 公有方法是类的调用者和维护者最关心的方法, 首屏展示最好;
   • 保护方法虽然只是子类关心, 也可能是 模板设计模式 下的核心方法;
   • 而私有方法外部一般不需要特别关心, 是一个黑盒实现;
   • 因为承载的信息价值较低, 所有 Service 和 DAO 的 getter/setter 方法放在类的最后, 用了lombok就省去了。

4. setter 方法中, 参数名称与类成员变量名称一致, this.成员名 = 参数名。

   • 在getter/setter 方法中, 不要增加业务逻辑, 增加排查问题的难度。

5. 循环体中的字符串的连接方式, 使用StringBuffer的append方法进行扩展

   • 说明: 反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象, 然后进行 append 操作,
   • 最后通过 toString 方法返回 String 对象, 造成内存资源浪费。

   验证循环中String的拼接

   public class test{
       public void test(){
           String target = "1";
           for(int a=0; a<10; a++){
               target += a;
           }
       }
   }
   // 1. javac test.java 编译
   // 2. javap -c -l test 反编译, 就能大致看到new StringBuilder了
   
   

6. final 可以声明类、成员变量、方法、以及本地变量, 下列情况使用 final 关键字:

   1. 不允许被继承的类, 如: String 类。
   2. 不允许修改引用的域对象, 如: POJO 类的域变量。
   3. 不允许被重写的方法, 如: POJO 类的 setter 方法。
   4. 不允许运行过程中重新赋值的局部变量。
   5. 避免上下文重复使用一个变量, 使用 final 描述可以强制重新定义一个变量, 方便更好地进行重构。
      • 这里就隐含了一个习惯, 不应该把一个变量到处传, 到处用,赋值, 很难追踪调试

7. 慎用Object的clone方法来拷贝对象 详见API

   • 说明: 对象的 clone 方法默认是浅拷贝, 最好重写该方法, 实现属性对象的拷贝。

8. 类成员与方法访问控制从严:

   1. 如果不允许外部直接通过 new 来创建对象, 那么构造方法显式声明并 private
   2. 工具类 不允许有 public 或 default 的构造方法
   3. 类非static成员变量 或者 成员方法 若 只与 子类共享, 必须是 protected
   4. 成员属性或方法 若 仅 本类中使用, 必须是 private
   5. 若是static成员变量, 必须考虑是否final
   6. 类static 成员变量如果仅在本类使用, 必须是 private。
   • 注意 说明: 任何类、方法、参数、变量, 都需要严控访问范围。过于宽泛的访问范围, 不利于模块解耦。
     • 思考: 如果是一个 private 的方法, 想删除就删除, 可是一个 public 的 service 方法, 或者一个 public 的成员变量, 删除一下, 不得手心冒点汗吗？
     • 变量像自己的小孩, 尽量在自己的视线内, 变量作用域太大, 无限制的到处跑, 那么你会担心的。

集合处理

强制

1. 关于 hashCode 和 equals 的处理, 遵循如下规则:

   • 只要重写 equals, 就必须重写 hashCode
   • 因为 Set 存储的是不重复的对象, 依据 hashCode 和 equals 进行判断, 所以 Set 存储的方法必须重写这两个方法
   • 如果自定义对象作为 Map 的键, 那么必须重写 hashCode 和 equals
   • 说明: String 重写了 hashCode 和 equals 方法, 所以我们可以非常愉快地使用 String 对象作为 key 来使用。

2. ArrayList 的 subList 结果不可强转成 ArrayList 否则会抛出 ClassCastException异常,

   • 即 java.util.RandomAccessSubList cannot be cast to java.util.ArrayList.
   • 说明: subList返回的是 ArrayList 的内部类 SubList, 并不是ArrayList, 而是ArrayList的一个视图, 对于SubList的所有操作最终都会反映到原列表上

3. 在 subList 场景中, 高度注意对原集合元素 个数的修改, 会导致子列表的 遍历、增加、删除 均会产生 ConcurrentModificationException

4. 使用集合转数组的方法, 必须使用集合的 toArray(T[] array) , 传入的是类型完全一样的数组, 数组大小就是 list.size()

   • 使用 toArray 带参方法, 入参分配的数组空间不够大时, toArray 方法内部将重新分配内存空间, 并返回新数组地址, 原数组不做更改;
   • 如果数组元素大于实际所需, 下标超出的数组元素将被置为 null, 其它数组元素保持原值, 因此最好将方法入参数组大小定义与集合元素个数一致。
   • 注意 直接使用 toArray 无参方法存在问题, 此方法返回值只能是 Object[]类, 若强转其它类型数组将出现 ClassCastException 错误。

5. 把数组转换成集合: 使用工具类Arrays.asList()时, 不能使用其修改集合相关的方法, 其add/remove/clear方法会抛出UnsupportedOperationException异常。

   • 因为 asList 的返回对象是一个继承于 AbstractList 的内部类 Arrays, 实现集合的那些修改方法时 都是直接抛出异常
   • Arrays.asList体现的是适配器模式, 只是转换接口, 后台的数据仍是固定长度的数组。
   • 案例: String[] str = new String[] { "a", "b" }; List list = Arrays.asList(str);
     • 第一种情况: list.add("c"); 运行时异常。
     • 第二种情况: str[0]= "gujin"; 那么 list.get(0) 也会随之修改。

6. 泛型通配符<? extends T>来接收返回的数据, 此写法的泛型集合不能使用 add 方法。

   • 而<? super T>不能使用 get 方法, 做为接口调用赋值时易出错。
   • 说明: 扩展说一下 PECS(Producer Extends Consumer Super)原则:
     • 第一、 频繁往外读取内容的, 适合用<? extends T>。
     • 第二、 经常往里插入的, 适合用<? super T>。
   • 说明: 苹果装箱后返回一个<? extends Fruits>对象, 此对象就不能往里加任何水果, 包括苹果。

7. 不要在 foreach 循环里进行元素的 remove/add 操作。 remove 元素请使用 Iterator方式, 如果并发操作, 需要对 Iterator 对象加锁。

   *正例: *

       Iterator<String> iterator = list.iterator();
       while (iterator.hasNext()) {
           String item = iterator.next();
           if (删除元素的条件) {
               iterator.remove();
           }
       }
   

   *反例: *

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

   说明: 以上代码的执行结果肯定会出乎大家的意料, 那么试一下把“1”换成“2”, 会是同样的结果吗？

8. 在 JDK7 版本以上, Comparator 要满足自反性, 传递性, 对称性, 不然 Arrays.sort , Collections.sort 会报 IllegalArgumentException

   • 1 ） 自反性: x , y 的比较结果和 y , x 的比较结果相反。
   • 2 ） 传递性: x > y , y > z ,则 x > z 。
   • 3 ） 对称性: x = y ,则 x , z 比较结果和 y , z 比较结果相同。

   *反例: 下例中没有处理相等的情况, 实际使用中可能会出现异常: *

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

推荐

1. 集合初始化时, 尽量指定集合初始容量值。

   • HashMap 使用 HashMap(int initialCapacity) 初始化
   • 正例: initialCapacity=(需要存储的元素个数/负载因子)+1。注意负载因子（即 loaderfactor）默认为0.75
     • 如果暂时无法确定初始值大小, 请设置为 16（即默认值） 。
   • 反例: HashMap 需要放置 1024 个元素, 由于没有设置容量初始大小, 随着元素不断增加, 容量7次被迫扩大, resize 需要重建 hash 表, 严重影响性能。

2. 使用 entrySet 遍历 Map 类集合 KV , 而不是 keySet 方式进行遍历

   • keySet 其实是遍历了 2 次, 一次是转为 Iterator 对象, 另一次是从 hashMap 中取出key 所对应的 value 。
   • 而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中, 效率更高。 如果是 JDK8, 使用 lambda 的 foreach 方法。
   • 说明: values() 返回的是V值集合, 是一个 list 集合对象; keySet()返回的是K值集合, 是一个 Set集合对象;entrySet()返回的是 K - V 值组合集合。

3. 高度注意 Map 类集合 K/V 能不能存储 null 值的情况, 如下表格:

   • 反例: 由于 HashMap 的干扰, 很多人认为 ConcurrentHashMap 是可以置入 null 值, 而事实上, 存储 null 值时会抛出 NPE 异常。

   集合类	Key	Value	Super	说明
   Hashtable	! NULL	! NULL	Dictionary	线程安全
   ConcurrentHashMap	! NULL	! NULL	AbstractMap	锁分段技术（ JDK8:CAS）
   TreeMap	! NULL	NULL	AbstractMap	线程不安全
   HashMap	NULL	NULL	AbstractMap	线程不安全

4. 合理利用好集合的有序性 (sort) 和稳定性 (order) , 避免集合的无序性 (unsort) 和不稳定性 (unorder) 带来的负面影响。

   • 稳定性指集合每次遍历的元素次序是一定的。
   • 有序性是指遍历的结果是按某种比较规则依次排列的。
   • 如: ArrayList 是 order / unsort;
     • HashMap 是 unorder/unsort;
     • TreeSet 是 order / sort 。

5. 利用 Set元素唯一的特性, 可以快速对一个集合进行去重操作, 避免使用 List的contains 方法进行遍历、对比、去重操作。

   • OrderSet也是一个很重要的类

并发处理

强制

1. 获取单例对象需要保证线程安全, 其中的方法也要保证线程安全。

   • 资源驱动类、工具类、单例工厂类都需要注意。

2. 创建线程或线程池时请指定有意义的线程名称, 方便出错时回溯。

3. 线程资源必须通过线程池提供, 不允许在应用中自行显式创建线程。

   • 使用线程池的好处是减少在创建和销毁线程上所花的时间, 以及系统资源的开销,解决资源不足的问题, 如果不使用线程池, 有可能造成系统创建大量同类线程而导致消耗完内存或者 过度切换 的问题

4. 线程池不允许使用 Executors 去创建, 而是通过 ThreadPoolExecutor 的方式, 这样的处理方式让写的同学更加明确线程池的运行规则, 规避资源耗尽的风险。

   • Executors 返回的线程池对象的弊端如下:
     1. FixedThreadPool 和 SingleThreadPool :
        • 允许的请求队列长度为 Integer.MAX_VALUE , 可能会堆积大量的请求, 从而导致 OOM 。
     2. CachedThreadPool 和 ScheduledThreadPool :
        • 允许的创建线程数量为 Integer.MAX_VALUE , 可能会创建大量的线程, 从而导致 OOM 。

5. SimpleDateFormat 是线程不安全的类, 一般不要定义为 static 变量, 如果定义为static , 必须加锁, 或者使用 DateUtils 工具类。

   • 如果是 JDK 8 的应用, 可以使用 Instant 代替 Date , LocalDateTime 代替 Calendar , DateTimeFormatter 代替 Simpledateformatter ,
   • 官方给出的解释: simple beautiful strongimmutable thread - safe 。

   或者如下处理实例化

   private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {      
       @Override 
       protected DateFormat initialValue() {           
           return new SimpleDateFormat("yyyy-MM-dd");       
       }   
   };   
   

6. 高并发时, 同步调用应该去考量锁的性能损耗。

   • 能用无锁数据结构, 就不要用锁 ;
   • 能锁区块, 就不要锁整个方法体 ;
   • 能用对象锁, 就不要用类锁。
   • 尽可能使得加锁的代码块工作量尽可能的小, 避免在锁代码块中调用 RPC 方法;

7. 对多个资源、数据库表、对象同时加锁时, 需要保持一致的加锁顺序, 否则可能会造成死锁。

   • 线程一需要对表 A 、 B 、 C 依次全部加锁后才可以进行更新操作, 那么线程二的加锁顺序也必须是 A 、 B 、 C , 否则可能出现死锁。

8. 并发修改同一记录时, 避免更新丢失, 要么在应用层加锁, 要么在缓存加锁, 要么在数据库层使用乐观锁, 使用 version 作为更新依据。

   • 如果每次访问冲突概率小于 20%, 推荐使用乐观锁, 否则使用悲观锁。乐观锁的重试次数不得小于 3 次。

9. 多线程并行处理定时任务时, Timer 运行多个 TimeTask 时, 只要其中之一没有捕获抛出的异常, 其它任务便会自动终止运行

   • 使用 ScheduledExecutorService 则没有这个问题。

推荐

1. 使用 CountDownLatch 进行异步转同步操作, 每个线程退出前必须调用 countDown方法, 线程执行代码注意 catch 异常, 确保 countDown 方法被执行到, 避免主线程无法执行至 await 方法, 直到超时才返回结果。

   • 注意, 子线程抛出异常堆栈, 不能在主线程 try - catch 到。

2. 避免 Random 实例被多线程使用, 虽然共享该实例是线程安全的, 但会因竞争同一 seed 导致的性能下降。

   • Random 实例包括 java.util.Random 的实例或者 Math.random() 实例。
   • 在JDK7之后, 可以直接使用 TreadLocalRandom, 而在JDK7以前, 需要编码保证每个线程持有一个实例

3. 在并发场景下, 通过双重检查锁 （double - checked locking） 实现延迟初始化的优化问题隐患

   • 可参考 The "Double - Checked Locking is Broken" Declaration ,
   • 推荐问题解决方案中较为简单一种 （ 适用于 JDK 5 及以上版本 ） , 将目标属性声明为 volatile 型 。

4. volatile 解决多线程内存不可见问题。对于一写多读, 是可以解决变量同步问题

   • 但是如果多写, 同样无法解决线程安全问题。如果是 count++ 操作, 使用如下类实现:
     • AtomicInteger count = new AtomicInteger(); count . addAndGet( 1 );
   • 如果是 JDK 8, 推荐使用 LongAdder 对象, 比 AtomicLong 性能更好 （ 减少乐观锁的重试次数 ） 。

5. HashMap 在容量不够进行 resize 时由于高并发可能出现死链, 导致 CPU 飙升, 在开发过程中可以使用其他数据结构或加锁来规避此风险。

6. ThreadLocal 无法解决共享对象的更新问题, ThreadLocal 对象建议使用 static 修饰。

   • 这个变量是针对一个线程内所有操作共有的, 所以设置为静态变量, 所有此类实例共享此静态变量,
   • 也就是说在类第一次被使用时装载, 只分配一块存储空间, 所有此类的对象 ( 只要是这个线程内定义的 ) 都可以操控这个变量。

控制语句

强制

1. 在一个 switch 块内, 每个 case 要么通过 break/return 等来终止, 要么注释说明程序将继续执行到哪一个 case 为止 ;

   • 在一个 switch 块内, 都必须包含一个 default 语句并且放在最后, 即使它什么代码也没有。

2. 在 if/else/for/while/do 语句结构中必须使用大括号, 即使只有一行代码

推荐

1. 表达异常的分支时, 少用 if-else 的方式, 这种方式可以改写:

   • 逻辑上超过 3 层的 if-else 代码可以使用卫语句, 状态模式, 策略模式来实现

       // 卫语句就是将错误情况提前返回
       public void today(){
           if(isBusy()){
               System.out.println("change time.");
               return;
           }
           if(isFree()){
               ...
               return;
           }
           ....
       }
   

2. 除常用方法（如 getXxx/isXxx）等外, 不要在条件判断中执行其它复杂的语句

   • 并且将复杂逻辑判断的结果赋值给一个有意义的布尔变量名, 以提高可读性。
   • 很多 if 语句内的逻辑判断都是相当复杂, 不能一眼看出在判断什么, 需要停顿,分析一下表达式才能理解 if 语句存在的意义
   • 如果有个boolean变量接收, 变量名就起到了注释的作用

       // 正例
       final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
       if(existed){...}
   
       // 反例
       if ((file.open(fileName, "w") != null) && (...) || (...);){...}
   

3. 循环体中的语句要考量性能, 以下操作尽量移至循环体外处理, 如定义对象、变量、获取数据库连接

   • 进行不必要的 try-catch 操作 (需要考虑这个 try-catch 是否可以移至循环体外而不影响逻辑)。

4. 接口入参保护, 这种场景常见的是用于做批量操作的接口。

5. 方法中 必须 进行参数校验的场景:

   1. 调用频次低的方法。
   2. 执行时间开销很大的方法. 此情形中,参数校验时间几乎可以忽略不计,
      • 但如果因为参数错误导致中间执行回退, 或者错误, 那得不偿失。
   3. 需要极高稳定性和可用性的方法。
   4. 对外提供的开放接口, 不管是 RPC/API/HTTP 接口。
   5. 敏感权限入口。

6. 方法中 不需要 参数校验的场景:

   1. 极有可能被循环调用的方法, 不建议对参数进行校验。但在方法说明里必须注明外部参数检查要求。
   2. 底层的方法调用频度都比较高。毕竟是像纯净水过滤的最后一道, 参数错误不太可能到底层才会暴露问题。
      • 一般 DAO 层与 Service层都在同一个应用中, 部署在同一台服务器中, 所以 DAO 的参数校验, 可以省略。
   3. 被声明成 private 只会被自己代码所调用的方法, 如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题, 此时可以不校验参数。

注释规约

强制

1. 类、类属性、类方法的注释必须使用 Javadoc 规范, 使用 /** 内容 */ 格式, 不得使用 // xxx 方式。

   • 为了能在IDE中快速查看注释

2. 所有的抽象方法 （包括接口中的方法） 必须要用 Javadoc 注释、除了返回值、参数、异常说明外, 还必须指出该方法做什么事情, 实现什么功能。

   • 并且声明 对子类的实现要求, 或者调用注意事项

3. 所有的类都必须添加创建者和创建日期。

4. 方法内部单行注释, 在被注释语句上方另起一行, 使用//注释(而不是行尾注释)。方法内部多行注释使用 /* */ 注释, 注意与代码对齐。

5. 所有的枚举类型字段必须要有注释, 说明每个数据项的用途。

推荐

1. 与其“半吊子”英文来注释, 不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。

   • 反例: TCP连接超时 解释成 传输控制协议连接超时, 反而更难以理解

2. 代码修改的同时, 注释也要进行相应的修改, 尤其是参数、返回值、异常、核心逻辑等的修改。