Java开发最佳实践(一) ——《Java开发手册》之"编程规约"

Java开发手册版本更新说明
专有名词解释
一、编程规约

Java开发手册版本更新说明

1.3.0	终极版	2017.09.25	单元测试规约，IDE代码规约插件
1.3.1	纪念版	2017.11.30	修正部分描述
1.4.0	详尽版	2018.05.20	增加设计规约大类，共16条
1.5.0	华山版	2019.06.19	详细更新见下面

本笔记主要基于华山版(1.5.0)的总结。华山版具体更新如下：

鉴于本手册是社区开发者集体智慧的结晶，本版本移除阿里巴巴Java开发手册的限定词阿里巴巴
新增21条新规约。比如，switch的NPE问题、浮点数的比较、无泛型限制、锁的使用方式、判断表达式、日期格式等
修改描述112处。比如，IFNULL的判断、集合的toArray、日志处理等
完善若干处示例。比如，命名示例、卫语句示例、enum示例、finally的return示例等。

PDF下载地址: https://pan.baidu.com/s/1K-GZ_CzRC0igIxMgLGVtZQ 密码:关注行无际的微信公众号：it_wild，回复java开发手册

Java开发最佳实践(一) ——《Java开发手册》之"编程规约"-LMLPHP

专有名词解释

POJO（Plain Ordinary Java Object）: 在本手册中，POJO专指只有setter、getter、toString的简单类，包括DO、DTO、BO、VO等。
GAV（GroupId、ArtifactctId、Version）: Maven坐标，是用来唯一标识jar包。
OOP（Object Oriented Programming）: 本手册泛指类、对象的编程处理方式。
ORM（Object Relation Mapping）: 对象关系映射，对象领域模型与底层数据之间的转换，本文泛指ibatis, mybatis等框架。
NPE（java.lang.NullPointerException）: 空指针异常。
SOA（Service-Oriented Architecture）: 面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用，有利于提升组件可重用性，可维护性。
IDE（Integrated Development Environment）: 用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具，本《手册》泛指 IntelliJ IDEA 和eclipse。
OOM（Out Of Memory）: 源于java.lang.OutOfMemoryError，当JVM没有足够的内存来为对象分配空间并且垃圾回收器也无法回收空间时，系统出现的严重状况。
一方库：本工程内部子项目模块依赖的库（jar包）。
二方库：公司内部发布到中央仓库，可供公司内部其它应用依赖的库（jar包）。
三方库：公司之外的开源库（jar包）。

一、编程规约

(一) 命名风格

正例：

国际通用的名称，可视同英文；alibaba / youku / hangzhou 等
类名使用UpperCamelCase风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。如：UserDO / XmlService / TcpUdpDeal
方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式；localValue / getHttpMessage / inputUserId
常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。MAX_STOCK_COUNT / CACHE_EXPIRED_TIME
抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾
类型与中括号紧挨相连来表示数组，定义整形数组 int[] arrayDemo;
包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。包名com.alibaba.ai.util，类名为MessageUtils（此规则参考spring的框架结构）
为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。在JDK中，表达原子更新的类名为：AtomicReferenceFieldUpdater
在常量与变量的命名时，表示类型的名词放在词尾，以提升辨识度。如：startTime / workQueue / nameList / TERMINATED_THREAD_COUNT
如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式（将设计模式体现在名字中，有利于阅读者快速理解架构设计理念）。如： class OrderFactory / class LoginProxy / class ResourceObserver
接口类中的方法和属性不要加任何修饰符号（public也不要加），保持代码的简洁性,并加上有效的Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。接口方法签名void commit();，接口基础常量String COMPANY = "alibaba";
对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。如CacheServiceImpl实现CacheService接口
如果是形容能力的接口名称，取对应的形容词为接口名（通常是–able的形容词）如 AbstractTranslator实现Translatable接口
枚举类名带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。(说明：枚举其实就是特殊的类，域成员均为常量，且构造方法被默认强制是私有。)枚举名字为ProcessStatusEnum的成员名称：SUCCESS / UNKNOWN_REASON
各层命名规约:

反例：

不能以下划线或美元符号开始、结束，如：_name、$name、name_
严禁使用拼音与英文混合的方式，如：DaZhePromotion[打折]、 getPingfenByName() [评分]
避免在子父类的成员变量之间、或者不同代码块的局部变量之间采用完全相同的命名，使可读性降低。
杜绝完全不规范的缩写，避免望文不知义。AbstractClass“缩写”命名成AbsClass，condition“缩写”命名成condi，此类随意缩写严重降低了代码的可阅读性。
接口类中的方法和属性不要加任何修饰符号（public也不要加) public abstract void f();
POJO类中布尔类型变量都不要加is前缀，否则部分框架解析会引起序列化错误。

(二) 常量定义

不允许任何魔法值（即未经预先定义的常量）直接出现在代码中 String key ="Id#taobao_" + tradeId;
在long或者Long赋值时，数值后使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解。Long a = 2l;
不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。正例：缓存相关常量放在类CacheConsts下；系统配置相关常量放在类ConfigConsts下。
如果变量值仅在一个固定范围内变化用enum类型来定义。

(三) 代码格式

采用4个空格缩进，禁止使用tab字符。
注释的双斜线与注释内容之间有且仅有一个空格。
在进行类型强制转换时，右括号与强制转换值之间不需要任何空格隔开int second = (int)first + 2;
IDE的text file encoding设置为UTF-8;IDE中文件的换行符使用Unix格式，不要使用Windows格式。
单个方法的总行数不超过80行
不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性(说明：任何情形，没有必要插入多个空行进行隔开。)

(四) OOP 规约

避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可
所有的覆写方法，必须加@Override注解
外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated注解，并清晰地说明采用的新接口或者新服务是么。
不能使用过时的类或方法。
Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals，"test".equals(object);【推荐使用 java.util.Objects#equals（JDK7 引入的工具类】
所有整型包装类对象之间值的比较，全部使用equals方法比较。【在-128至127这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用equals方法进行判断】
定义数据对象DO类时，属性类型要与数据库字段类型相匹配。数据库字段的bigint必须与类属性的Long类型相对应。
为了防止精度损失，禁止使用构造方法BigDecimal(double)的方式把double值转化为BigDecimal对象(在精确计算或值比较的场景中可能会导致业务逻辑异常)。BigDecimal g = new BigDecimal(0.1f);实际的存储值为：0.10000000149。正例：优先推荐入参为String的构造方法，或使用BigDecimal的valueOf方法，此方法内部其实执行了Double的toString，而Double的toString按double的实际能表达的精度对尾数进行了截断。

BigDecimal recommend1 = new BigDecimal("0.1");

BigDecimal recommend2 = BigDecimal.valueOf(0.1);

关于基本数据类型与包装数据类型的使用标准如下：1）【强制】所有的POJO类属性必须使用包装数据类型。2）【强制】RPC方法的返回值和参数必须使用包装数据类型。3）【推荐】所有的局部变量使用基本数据类型。【说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。反例：比如显示成交总额涨跌情况，即正负x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示为0%，这是不合理的，应该显示成中划线。所以包装数据类型的null值，能够表示额外的信息，如：远程调用失败，异常退出。】
定义 DO/DTO/VO等POJO类时，不要设定任何属性默认值。【反例：POJO 类的 createTime 默认值为 new Date()，但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。】
序列化类新增属性时，请不要修改serialVersionUID字段，避免反序列失败；如果完全不兼容升级，避免反序列化混乱，那么请修改serialVersionUID值。(说明：注意serialVersionUID不一致会抛出序列化运行时异常。)
构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。
POJO类必须写toString方法。使用IDE中的工具：source> generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。【说明：在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题】
禁止在POJO类中，同时存在对应属性xxx的isXxx()和getXxx()方法。【说明：框架在调用属性 xxx 的提取方法时，并不能确定哪个方法一定是被优先调用到】
使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛IndexOutOfBoundsException的风险
当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读，此条规则优先于下一条
类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter方法。
在getter/setter方法中，不要增加业务逻辑，增加排查问题的难度
循环体内，字符串的连接方式，使用StringBuilder的append方法进行扩展
final可以声明类(不允许被继承的类，如String类)、成员变量(不允许修改引用的域对象)、方法、以及本地变量(不允许运行过程中重新赋值的局部变量),避免上下文重复使用一个变量，使用final可以强制重新定义一个变量，方便更好地进行重构
慎用Object的clone方法来拷贝对象，对象clone方法默认是浅拷贝，若想实现深拷贝需覆写clone方法实现域对象的深度遍历式拷贝。
类成员与方法访问控制从严。1）如果不允许外部直接通过new来创建对象，那么构造方法必须是private。2）工具类不允许有public或default构造方法。3）类非static 成员变量并且与子类共享，必须是protected。 4）类非static成员变量并且仅在本类使用，必须是private。5）类static成员变量如果仅在本类使用，必须是private。 6）若是static成员变量，考虑是否为final。7）类成员方法只供类内部调用，必须是 private。8）类成员方法只对继承类公开，那么限制为protected。【说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦】
浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用equals 来判断。【浮点数采用“尾数+阶码”的编码方式，类似于科学计数法的“有效数字+指数”的表示方式】

// 反例

float a = 1.0f - 0.9f;

float b = 0.9f - 0.8f;

if (a == b) { // 预期进入此代码快，执行其它业务逻辑

// 但事实上 a==b 的结果为 false

}

Float x = Float.valueOf(a);

Float y = Float.valueOf(b);

if (x.equals(y)) { // 预期进入此代码快，执行其它业务逻辑

// 但事实上 equals 的结果为 false

}

// 正例

// (1)指定一个误差范围，两个浮点数的差值在此范围之内，则认为是相等的

float a = 1.0f - 0.9f;

float b = 0.9f - 0.8f;

float diff = 1e-6f;

if (Math.abs(a - b) < diff) {

    System.out.println("true");

}

// (2)使用BigDecimal来定义值，再进行浮点数的运算操作

// BigDecimal构造的时候注意事项 见上文

BigDecimal a = new BigDecimal("1.0");

BigDecimal b = new BigDecimal("0.9");

BigDecimal c = new BigDecimal("0.8");

BigDecimal x = a.subtract(b);

BigDecimal y = b.subtract(c);

if (x.equals(y)) {

    System.out.println("true");

}

(五) 集合处理

关于hashCode和equals的处理，遵循如下规则:1）只要覆写equals，就必须覆写hashCode。2）因为Set存储的是不重复的对象，依据hashCode和equals进行判断，所以Set存储的对象必须覆写这两个方法。3）如果自定义对象作为Map的键，那么必须覆写hashCode和equals。【说明：String已覆写hashCode和equals方法，所以我们可以愉快地使用String对象作为key来使用】
ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException异常，即java.util.RandomAccessSubList cannot be cast to java.util.ArrayList【说明：subList返回的是ArrayList的内部类SubList，并不是ArrayList而是ArrayList的一个视图，对于SubList子列表的所有操作最终会反映到原列表上】
使用Map的方法keySet()/values()/entrySet()返回集合对象时，不可以对其进行添加元素操作，否则会抛出UnsupportedOperationException异常
Collections类返回的对象，如：emptyList()/singletonList()等都是immutable list，不可对其进行添加或者删除元素的操作【反例：如果查询无结果，返回 Collections.emptyList()空集合对象，调用方一旦进行了添加元素的操作，就会触发UnsupportedOperationException异常。】
在subList场景中，高度注意对原集合元素的增加或删除，均会导致子列表的遍历、增加、删除产生ConcurrentModificationException异常
使用集合转数组的方法，必须使用集合的toArray(T[] array)，传入的是类型完全一致、长度为0的空数组【反例：直接使用toArray无参方法存在问题，此方法返回值只能是Object[]类，若强转其它类型数组将出现ClassCastException错误。】

// 正例

List<String> list = new ArrayList<>(2);

list.add("行无际");

list.add("itwild");

String[] array = list.toArray(new String[0]);

/*

说明：

使用toArray带参方法，数组空间大小的length：

1）等于0，动态创建与size相同的数组，性能最好

2）大于0但小于size，重新创建大小等于size的数组，增加GC负担

3）等于size，在高并发情况下，数组创建完成之后，size正在变大的情况下，负面影响与上相同

4）大于size，空间浪费，且在size处插入null值，存在NPE隐患

*/

在使用Collection接口任何实现类的addAll()方法时，都要对输入的集合参数进行NPE判断【说明：在ArrayList#addAll方法的第一行代码即Object[] a = c.toArray();其中c为输入集合参数，如果为null，则直接抛出异常。】
使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，它的add/remove/clear方法会抛出UnsupportedOperationException异常【说明：asList的返回对象是一个Arrays内部类，并没有实现集合的修改方法。Arrays.asList体现的是适配器模式，只是转换接口，后台的数据仍是数组。】

String[] str = new String[] { "it", "wild" };

List list = Arrays.asList(str);

// 第一种情况：list.add("itwild"); 运行时异常

// 第二种情况：str[0] = "changed1"; 也会随之修改

// 反之亦然 list.set(0, "changed2");

泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用add方法，而<? super T>不能使用get方法，作为接口调用赋值时易出错。【说明：扩展说一下PECS(Producer Extends Consumer Super)原则：第一、频繁往外读取内容的，适合用<? extends T>。第二、经常往里插入的，适合用<? super T>】

// 这里就要求dest的List里面的元素类型 不能在src的List元素类型 之下

// 如果dest的List元素类型位于src的List元素类型之下，就会出现写不进dest

public static <T> void copy(List<? super T> dest, List<? extends T> src) {

    //....省略具体的copy代码

}

// 下面再看我写的测试代码就更容易理解了

static class Animal {}

static class Dog extends Animal {}

static class BlackDog extends Dog {}

@Test

public void test() throws Exception {

    List<Dog> dogList = new ArrayList<>(2);

    dogList.add(new BlackDog());

    dogList.add(new BlackDog());

    List<Animal> animalList = new ArrayList<>(2);

    animalList.add(new Animal());

    animalList.add(new Animal());

    // 错误，无法编译通过

    Collections.copy(dogList, animalList);

    // 正确

    Collections.copy(animalList, dogList);

    // Collections.copy()的泛型参数就起作到了很好的限制作用

    // 编译期就能发现类型不对

}

在无泛型限制定义的集合赋值给泛型限制的集合时，在使用集合元素时，需要进行instanceof判断，避免抛出ClassCastException异常。

// 反例

List<String> generics = null;

List notGenerics = new ArrayList(10);

notGenerics.add(new Object());

notGenerics.add(new Integer(1));

generics = notGenerics;

// 此处抛出 ClassCastException 异常

String string = generics.get(0);

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

// 正例

List<String> list = new ArrayList<>();

list.add("1");

list.add("2");

Iterator<String> iterator = list.iterator();

while (iterator.hasNext()) {

    String item = iterator.next();

    if (删除元素的条件) {

        iterator.remove();

    }

}

// 反例

for (String item : list) {

  if ("1".equals(item)) {

    list.remove(item);

  }

}

在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;

  }

};

集合泛型定义时，在JDK7及以上，使用diamond语法或全省略。【说明：菱形泛型，即 diamond，直接使用<>来指代前边已经指定的类型】

// 正例

// diamond 方式，即<>

HashMap<String, String> userCache = new HashMap<>(16);

// 全省略方式

ArrayList<User> users = new ArrayList(10);

集合初始化时，指定集合初始值大小【说明：HashMap使用HashMap(int initialCapacity)初始化。】

使用entrySet遍历Map类集合KV，而不是keySet方式进行遍历。【说明：keySet其实是遍历了2次，一次是转为Iterator对象，另一次是从hashMap中取出 key所对应的value。而entrySet只是遍历了一次就把key和value都放到了entry中，效率更高。如果是JDK8，使用Map.forEach方法。】

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

Hashtable	不允许为null	不允许为null	Dictionary	线程安全
ConcurrentHashMap	不允许为null	不允许为null	AbstractMap	锁分段技术（JDK8:CAS）
TreeMap	不允许为null	允许为null	AbstractMap	线程不安全
HashMap	允许为null	允许为null	AbstractMap	线程不安全

合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。【说明：有序性是指遍历的结果是按某种比较规则依次排列的。稳定性指集合每次遍历的元素次序是一定的。如：ArrayList是 order/unsort；HashMap是unorder/unsort；TreeSet是order/sort。】
利用Set元素唯一的特性，可以快速对一个集合进行去重操作，避免使用List的contains方法进行遍历、对比、去重操作

(六) 并发处理

获取单例对象需要保证线程安全，其中的方法也要保证线程安全【说明：资源驱动类、工具类、单例工厂类都需要注意】
创建线程或线程池时请指定有意义的线程名称，方便出错时回溯

// 正例：自定义线程工厂，并且根据外部特征进行分组，比如机房信息

public class UserThreadFactory implements ThreadFactory {

    private final String namePrefix;

    private final AtomicInteger nextId = new AtomicInteger(1);

    // 定义线程组名称，在 jstack 问题排查时，非常有帮助

    UserThreadFactory(String whatFeaturOfGroup) {

        namePrefix = "From UserThreadFactory's " + whatFeaturOfGroup + "-Worker-";

    }

    @Override

    public Thread newThread(Runnable task) {

        String name = namePrefix + nextId.getAndIncrement();

        Thread thread = new Thread(null, task, name, 0, false);

        System.out.println(thread.getName());

        return thread;

    }

}

线程资源必须通过线程池提供，不允许在应用中自行显式创建线程【说明：线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题】
线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

SimpleDateFormat是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁。【说明：如果是JDK8的应用，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。】

// 正例：注意线程安全。亦推荐如下处理

private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {

    @Override

    protected DateFormat initialValue() {

        return new SimpleDateFormat("yyyy-MM-dd");

    }

};

必须回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的ThreadLocal变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量使用try-finally块进行回收

// 正例

objectThreadLocal.set(userInfo);

try {

    // ...

} finally {

    objectThreadLocal.remove();

}

高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁【说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。】
对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。【说明：线程一需要对表A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是A、B、C，否则可能出现死锁。】
在使用阻塞等待获取锁的方式中，必须在try代码块之外，并且在加锁方法与try代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在finally中无法解锁

// 正例

Lock lock = new XxxLock();

// ...

lock.lock();

try {

    doSomething();

    doOthers();

} finally {

    lock.unlock();

}

// 反例

Lock lock = new XxxLock();

// ...

try {

    // 如果此处抛出异常，则直接执行 finally 代码块

    doSomething();

    // 无论加锁是否成功，finally 代码块都会执行

    lock.lock();

    doOthers();

} finally {

    lock.unlock();

}

在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是否持有锁。锁的释放规则与锁的阻塞等待方式相同

// 正例

Lock lock = new XxxLock();

// ...

boolean isLocked = lock.tryLock();

if (isLocked) {

    try {

      doSomething();

      doOthers();

    } finally {

      lock.unlock();

    }

}

并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据【说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。】
多线程并行处理定时任务时，Timer运行多个TimeTask时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，如果在处理定时任务时使用ScheduledExecutorService则没有这个问题
资金相关的金融敏感信息，使用悲观锁策略。【说明：乐观锁在获得锁的同时已经完成了更新操作，校验逻辑容易出现漏洞，另外，乐观锁对冲突的解决策略有较复杂的要求，处理不当容易造成系统压力或数据异常，所以资金相关的金融敏感信息不建议使用乐观锁更新。】
使用CountDownLatch进行异步转同步操作，每个线程退出前必须调用countDown方法，线程执行代码注意catch异常，确保countDown方法被执行到，避免主线程无法执行至await方法，直到超时才返回结果【说明：注意，子线程抛出异常堆栈，不能在主线程try-catch到。】
避免Random实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一seed导致的性能下降【说明：Random实例包括java.util.Random的实例或者Math.random()的方式。正例：在JDK7之后，可以直接使用APIThreadLocalRandom，而在JDK7之前，需要编码保证每个线程持有一个实例】
在并发场景下，通过双重检查锁（double-checked locking）实现延迟初始化的优化问题隐患(可参考 The "Double-Checked Locking is Broken" Declaration)，推荐解决方案中较为简单一种（适用于JDK5及以上版本），将目标属性声明为volatile型。

// 注意 这里的代码并非出自官方的《java开发手册》

// 参考 https://blog.csdn.net/lovelion/article/details/7420886

public class LazySingleton {

    // volatile除了保证内容可见性还有防止指令重排序

    // 对象的创建实际上是三条指令：

    // 1、分配内存地址 2、内存地址初始化 3、返回内存地址句柄

    // 其中2、3之间可能发生指令重排序

    // 重排序可能导致线程A创建对象先执行1、3两步，

    // 结果线程B进来判断句柄已经不为空，直接返回给上层方法

    // 此时对象还没有正确初始化内存，导致上层方法发生严重错误

    private volatile static LazySingleton instance = null;

    private LazySingleton() { }

    public static LazySingleton getInstance() {

        // 第一重判断

        if (instance == null) {

            synchronized (LazySingleton.class) {

                // 第二重判断

                if (instance == null) {

                    // 创建单例实例

                    instance = new LazySingleton();

                }

            }

        }

        return instance;

    }

}

// 既然这里提到 单例懒加载，还有这样写的

// 参考 https://blog.csdn.net/lovelion/article/details/7420888

class Singleton {

  private Singleton() { }

  private static class HolderClass {

  // 由Java虚拟机来保证其线程安全性，确保该成员变量只能初始化一次

    final static Singleton instance = new Singleton();

  }

  public static Singleton getInstance() {

      return HolderClass.instance;

  }

}

volatile解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题。【说明：如果是count++操作，使用如下类实现：AtomicInteger count = new AtomicInteger(); count.addAndGet(1);如果是JDK8，推荐使用LongAdder对象，比AtomicLong性能更好（减少乐观锁的重试次数）。】
HashMap在容量不够进行resize时由于高并发可能出现死链，导致CPU飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险
ThreadLocal对象使用static修饰，ThreadLocal无法解决共享对象的更新问题【说明：这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量】

(七) 控制语句

当switch括号内的变量类型为String并且此变量为外部参数时，必须先进行null判断。

public class SwitchString {

    public static void main(String[] args) {

        // 这里会抛异常 java.lang.NullPointerException

        method(null);

    }

    public static void method(String param) {

        switch (param) {

            // 肯定不是进入这里

            case "sth":

                System.out.println("it's sth");

                break;

            // 也不是进入这里

            case "null":

                System.out.println("it's null");

                break;

            // 也不是进入这里

            default:

                System.out.println("default");

        }

    }

}

在if/else/for/while/do语句中必须使用大括号。【说明：即使只有一行代码，避免采用单行的编码方式：if (condition) statements;】
在高并发场景中，避免使用”等于”判断作为中断或退出的条件。【说明：如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件来代替。】

表达异常的分支时，少用if-else方式，这种方式可以改写成下面代码：【说明：如果非使用if()...else if()...else...方式表达逻辑，避免后续代码维护困难，请勿超过3层】

if (condition) {

    ...

    return obj;

}

// 接着写 else 的业务逻辑代码;

// 示例代码

public void findBoyfriend(Man man) {

  if (man.isUgly()) {

    System.out.println("本姑娘是外貌协会的资深会员");

    return;

  }

  if (man.isPoor()) {

    System.out.println("贫贱夫妻百事哀");

    return;

  }

  if (man.isBadTemper()) {

    System.out.println("银河有多远，你就给我滚多远");

    return;

  }

  System.out.println("可以先交往一段时间看看");

}

除常用方法（如getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。【说明：很多if语句内的逻辑表达式相当复杂，与、或、取反混合运算，甚至各种方法纵深调用，理解成本非常高。如果赋值一个非常好理解的布尔变量名字，则是件令人爽心悦目的事情。】

// 正例

// 伪代码如下

final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);

if (existed) {

  ...

}

// 反例

// 哈哈，这好像是ReentrantLock里面有类似风格的代码

// 连Doug Lea的代码都拿来当做反面教材啊

// 早前就听别人说过“编程不识Doug Lea,写尽Java也枉然!!!”

public final void acquire(long arg) {

  if (!tryAcquire(arg) &&

    acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {

      selfInterrupt();

  }

}

不要在其它表达式（尤其是条件表达式）中，插入赋值语句【说明：赋值点类似于人体的穴位，对于代码的理解至关重要，所以赋值语句需要清晰地单独成为一行。】

// 反例

public Lock getLock(boolean fair) {

  // 算术表达式中出现赋值操作，容易忽略 count 值已经被改变

  threshold = (count = Integer.MAX_VALUE) - 1;

  // 条件表达式中出现赋值操作，容易误认为是 sync==fair

  return (sync = fair) ? new FairSync() : new NonfairSync();

}

循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的try-catch操作（这个try-catch是否可以移至循环体外）
避免采用取反逻辑运算符。【说明：取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。正例：使用if (x < 628)来表达x小于628。反例：使用 if (!(x >= 628))来表达x小于628。】
下列情形，需要进行参数校验

下列情形，不需要进行参数校验：

(八) 注释规约

类、类属性、类方法的注释必须使用Javadoc规范，使用/**内容*/格式，不得使用// xxx方式。【说明：在IDE编辑窗口中，Javadoc方式会提示相关注释，生成 Javadoc可以正确输出相应注释；在IDE中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。】
所有的抽象方法（包括接口中的方法）必须要用Javadoc注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能【说明：对子类的实现要求，或者调用注意事项，请一并说明】
所有的类都必须添加创建者和创建日期。
方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐
所有的枚举类型字段必须要有注释，说明每个数据项的用途
与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可【反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。】
代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。【代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义】
谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。【说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库已然保存了历史代码）】
对于注释的要求：第一、能够准确反映设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。
好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担【语义清晰的代码不需要额外的注释。】
特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

(九) 其它

在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度【说明：不要在方法体内定义：Pattern pattern = Pattern.compile("规则");】
注意Math.random()这个方法返回是double类型，注意取值的范围0≤x<1（能够取到零值，注意除零异常），如果想获取整数类型的随机数，不要将x放大10的若干倍然后取整，直接使用Random对象的nextInt或者nextLong方法。
获取当前毫秒数System.currentTimeMillis();而不是new Date().getTime();【说明：如果想获取更加精确的纳秒级时间值，使用System.nanoTime()的方式。在JDK8中，针对统计时间等场景，推荐使用Instant类。】
日期格式化时，传入pattern中表示年份统一使用小写的y。【说明：日期格式化时，yyyy表示当天所在的年，而大写的YYYY代表是 week in which year（JDK7之后引入的概念），意思是当天所在的周属于的年份，一周从周日开始，周六结束，只要本周跨年，返回的YYYY就是下一年。另外需要注意：表示月份是大写的M，表示分钟则是小写的m，24小时制的是大写的H，12小时制的则是小写的h 。正例：new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");】
任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存
及时清理不再使用的代码段或配置信息【说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由】

规约

Java开发最佳实践(一) ——《Java开发手册》之"编程规约"

Java开发手册版本更新说明

专有名词解释

一、 编程规约

(一) 命名风格

(二) 常量定义

(三) 代码格式

(四) OOP 规约

(五) 集合处理

(六) 并发处理

(七) 控制语句

(八) 注释规约

(九) 其它

一、编程规约