阿里巴巴java规范手册摘要

记录一些自己不太熟悉的规范！

(一) 命名风格

【强制】POJO类中布尔类型的变量不要加is
错误：Boolean isDeleted；正确：Boolean deleted
原因：方法isDeleted()，部分框架反向解析，“以为”属性是deleted，属性获取不到，抛出异常。
【推荐】将设计模式体现在名字中，利于阅读者快速理解架构设计。
正例：public class OrderFactory;
public class LoginProxy;
public class ResourceObserver;
【推荐】接口类的方法和属性不加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名：void f(); 接口基础常量表示：String COMPANY = "alibaba";
反例：接口方法定义：public abstract void f();
说明：JDK8中接口允许有默认实现，那么这个default方法，是对所有实现类都有价值的默认实现。
接口和实现类的命名有两套规则
： 1）【强制】对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。
正例：CacheServiceImpl实现CacheService接口。
2）【推荐】如果是形容能力的接口名称，取对应的形容词做接口名（通常是–able的形式）。
正例：AbstractTranslator实现 Translatable。
【参考】各层命名规约：
A) Service/DAO层方法命名规约
1）获取单个对象的方法用get做前缀。
2）获取多个对象的方法用list做前缀。
3）获取统计值的方法用count做前缀。
4）插入的方法用save/insert做前缀。
5）删除的方法用remove/delete做前缀。
6）修改的方法用update做前缀。
B) 领域模型命名规约
1）数据对象：xxxDO，xxx即为数据表名。
2）数据传输对象：xxxDTO，xxx为业务领域相关的名称。
3）展示对象：xxxVO，xxx一般为网页名称。
4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。
(二) 常量定义
【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
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规约

【强制】相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。
说明：可变参数必须放置在参数列表的最后。
（提倡同学们尽量不用可变参数编程）正例：public User getUsers(String type, Integer... ids) {...}
【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。
正例："test".equals(object);
反例：object.equals("test");
说明：推荐使用java.util.Objects#equals（JDK7引入的工具类）
关于基本数据类型与包装数据类型的使用标准如下：
1）【强制】所有的POJO类属性必须使用包装数据类型。
2）【强制】RPC方法的返回值和参数必须使用包装数据类型。
3）【推荐】所有的局部变量使用基本数据类型。
说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。
反例：比如显示成交总额涨跌情况，即正负x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示为0%，
这是不合理的，应该显示成中划线。所以包装数据类型的null值，能够表示额外的信息，如：远程调用失败，异常退出。
【强制】POJO类必须写toString方法。使用IDE的中工具：source> generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。
说明：在方法执行抛出异常时，可以直接调用POJO的toString()方法打印其属性值，便于排查问题。
【推荐】使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛IndexOutOfBoundsException的风险。
说明：
String str = "a,b,c,,";
String[] ary = str.split(",");
// 预期大于3，结果是3
System.out.println(ary.length);
【推荐】类成员与方法访问控制从严：
2）工具类不允许有public或default构造方法。 ( 直接类名调用静态方法，不需要构造器实例化 )

(五) 集合处理

【强制】 ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException异常，
说明：subList 返回的是 ArrayList 的内部类 SubList，并不是 ArrayList ，
而是 ArrayList 的一个视图，对于SubList子列表的所有操作最终会反映到原列表上。
【强制】在subList场景中，高度注意对原集合元素个数的修改，
会导致子列表的遍历、增加、删除均会产生ConcurrentModificationException 异常。
【强制】使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，
它的add/remove/clear方法会抛出UnsupportedOperationException异常。
说明：asList的返回对象是一个Arrays内部类，并没有实现集合的修改方法。
Arrays.asList体现的是适配器模式，只是转换接口，后台的数据仍是数组。
String[] str = new String[] { "you", "wu" }; List list = Arrays.asList(str);
第一种情况：list.add("yangguanbao"); 运行时异常。
第二种情况：str[0] = "gujin"; 那么list.get(0)也会随之修改。
如果想修改:
List list = new ArrayList<>(Arrays.asList(1,2,3));
【强制】泛型通配符来接收返回的数据，此写法的泛型集合不能使用add方法，
而不能使用get方法，做为接口调用赋值时易出错。
说明：扩展说一下PECS(Producer Extends Consumer Super)原则：
第一、频繁往外读取内容的，适合用。
第二、经常往里插入的，适合用。
【推荐】集合初始化时，指定集合初始值大小。
正例：initialCapacity =(需要存储的元素个数 / 负载因子) + 1。
注意负载因子（即loader factor）默认为0.75，如果暂时无法确定初始值大小，请设置为16（即默认值）。
反例：HashMap需要放置1024个元素，由于没有设置容量初始大小，随着元素不断增加，容量7次被迫扩大，resize需要重建hash表，严重影响性能。
【推荐】使用entrySet遍历Map类集合KV，而不是keySet方式进行遍历。(两者都都要遍历的时候)
说明：keySet其实是遍历了2次，一次是转为Iterator对象，另一次是从hashMap中取出key所对应的value。
而entrySet只是遍历了一次就把key和value都放到了entry中，效率更高。如果是JDK8，使用Map.foreach方法。 items.forEach((k,v)->{ System.out.println("Item : " + k + " Count : " + v); });
正例：values()返回的是V值集合，是一个list集合对象；keySet()返回的是K值集合，是一个Set集合对象；entrySet()返回的是K-V值组合集合。
【推荐】高度注意Map类集合K/V能不能存储null值的情况，如下表格：
集合类 Key Value Super 说明
Hashtable 不允许为null 不允许为null Dictionary 线程安全
ConcurrentHashMap 不允许为null 不允许为null AbstractMap 锁分段技术（JDK8:CAS）
TreeMap 不允许为null 允许为null AbstractMap 线程不安全
HashMap 允许为null 允许为null AbstractMap 线程不安全

(六) 并发处理

【强制】线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。说明：Executors返回的线程池对象的弊端如下：
1）FixedThreadPool和SingleThreadPool:允许的请求队列长度为Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM。
2）CachedThreadPool和ScheduledThreadPool:允许的创建线程数量为Integer.MAX_VALUE，可能会创建大量的线程，从而导致OOM。
【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁，或者使用DateUtils工具类。正例：注意线程安全，使用DateUtils。亦推荐如下处理：
private static final ThreadLocal df = new ThreadLocal() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
说明：如果是JDK8的应用，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。
【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。说明：线程一需要对表A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是A、B、C，否则可能出现死锁。
【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据。说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。
【推荐】使用CountDownLatch进行异步转同步操作，每个线程退出前必须调用countDown方法，线程执行代码注意catch异常，确保countDown方法被执行到，避免主线程无法执行至await方法，直到超时才返回结果。说明：注意，子线程抛出异常堆栈，不能在主线程try-catch到。
【参考】volatile解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题。
如果是count++操作，使用如下类实现：AtomicInteger count = new AtomicInteger(); count.addAndGet(1);
如果是JDK8，推荐使用LongAdder对象，比AtomicLong性能更好（减少乐观锁的重试次数）。
【参考】 HashMap在容量不够进行resize时由于高并发可能出现死链，导致CPU飙升，
在开发过程中可以使用其它数据结构或加锁来规避此风险。
【参考】ThreadLocal无法解决共享对象的更新问题，ThreadLocal对象建议使用static修饰。
这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，
也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量
好处： ThreadLocal来消除共享对象的同步问题

(七) 控制语句

【推荐】表达异常的分支时，少用if-else方式，这种方式可以改写成：
if (condition) {
...
return obj;
}
// 接着写else的业务逻辑代码;
说明：如果非得使用if()...else if()...else...方式表达逻辑，【强制】避免后续代码维护困难，请勿超过3层。
正例：超过3层的 if-else 的逻辑判断代码可以使用卫语句（将复杂的判断拆分为多个）、策略模式、状态模式等来实现
【推荐】除常用方法（如getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。说明：很多if语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？正例：
// 伪代码如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
【参考】下列情形，需要进行参数校验：
1）调用频次低的方法。
2）执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。
3）需要极高稳定性和可用性的方法。
4）对外提供的开放接口，不管是RPC/API/HTTP接口。
5）敏感权限入口。
【参考】下列情形，不需要进行参数校验：
1）极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。
2）底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般DAO层与Service层都在同一个应用中，部署在同一台服务器中，所以DAO的参数校验，可以省略。
3）被声明成private只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

阿里巴巴java规范手册摘要

你可能感兴趣的:(阿里巴巴java规范手册摘要)