我的博客网站：http://www.caoyong.xin:8080/blogger（欢迎访问！有我更多的文章）

六：并发处理

 

1. 【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。说明：资源驱动类、工具类、单例工厂类都需要注意。

 

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

 

正例：

 

public class TimerTaskThread extends Thread {

 

public TimerTaskThread() {

 

super.setName("TimerTaskThread");

 

...

 

}

 

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

 

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

 

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

 

说明：Executors 返回的线程池对象的弊端如下：

 

1）FixedThreadPool 和 SingleThreadPool:

 

允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。

 

2）CachedThreadPool 和 ScheduledThreadPool:

 

允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。

 

5. 【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为

 

static，必须加锁，或者使用 DateUtils 工具类。

 

正例：注意线程安全，使用 DateUtils。亦推荐如下处理：

 

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

 

protected DateFormat initialValue() {

 

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

 

}

 

};

 

说明：如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，

 

DateTimeFormatter 代替 SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。

 

6. 【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

 

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。

 

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

 

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

 

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

 

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

 

9. 【强制】多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。

 

10. 【推荐】使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown

 

方法，线程执行代码注意 catch 异常，确保 countDown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果。

 

说明：注意，子线程抛出异常堆栈，不能在主线程 try-catch 到。

 

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

 

说明：Random 实例包括 java.util.Random 的实例或者 Math.random()的方式。

 

正例：在 JDK7 之后，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要编码保

 

证每个线程持有一个实例。

 

12. 【推荐】在并发场景下，通过双重检查锁（double-checked locking）实现延迟初始化的优化问题隐患(可参考 The "Double-Checked Locking is Broken" Declaration)，推荐解决方案中较为简单一种（适用于 JDK5 及以上版本），将目标属性声明为 volatile 型。

 

反例：

 

class Singleton {

 

private Helper helper = null;

 

public Helper getHelper() {

 

if (helper == null) synchronized(this) {

 

if (helper == null)

 

helper = new Helper();

 

}

 

return helper;

 

}

 

// other methods and fields...

 

}

 

 

13. 【参考】volatile 解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，

 

但是如果多写，同样无法解决线程安全问题。如果是 count++操作，使用如下类实现：

 

AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推

 

荐使用 LongAdder 对象，比 AtomicLong 性能更好（减少乐观锁的重试次数）。

 

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

 

15. 【参考】ThreadLocal 无法解决共享对象的更新问题，ThreadLocal 对象建议使用 static

 

修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享

 

此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只

 

要是这个线程内定义的)都可以操控这个变量。

 

 

 

 

七： 控制语句

 

1. 【强制】在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使空代码。

 

2. 【强制】在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用

 

单行的编码方式：if (condition) statements;

 

3. 【强制】在高并发场景中，避免使用”等于”判断作为中断或退出的条件。

 

说明：如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件来代替。

 

反例：判断剩余奖品数量等于 0 时，终止发放奖品，但因为并发处理错误导致奖品数量瞬间变成了负数，这样的话，活动无法终止。

 

4. 【推荐】表达异常的分支时，少用 if-else 方式，这种方式可以改写成：

 

if (condition) {

 

...

 

return obj;

 

}

 

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

 

说明：如果非得使用 if()...else if()...else...方式表达逻辑，【强制】避免后续代码维护困难，请勿超过 3 层。

 

正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，

 

其中卫语句示例如下：

 

public void today() {

 

if (isBusy()) {

 

System.out.println(“change time.”);

 

return;

}

 

if (isFree()) {

 

System.out.println(“go to travel.”);

 

return;

 

}

 

System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”); return;

 

}

 

5. 【推荐】除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

 

说明：很多 if 语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？

 

正例：

 

/ 伪代码如下

 

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

 

...

 

}

 

反例：

 

if ((file.open(fileName, "w") != null) && (...) || (...)) {

 

...

 

}

 

6. 【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的 try-catch 操作（这个 try-catch 是否可以移至循环体外）。

 

7. 【推荐】避免采用取反逻辑运算符。

 

说明：取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。

 

正例：使用 if (x < 628) 来表达 x 小于 628。

 

反例：使用 if (!(x >= 628)) 来表达 x 小于 628。

 

8. 【推荐】接口入参保护，这种场景常见的是用作批量操作的接口。

 

9. 【参考】下列情形，需要进行参数校验：

 

1） 调用频次低的方法。

 

2） 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参

 

数错误导致中间执行回退，或者错误，那得不偿失。

 

3） 需要极高稳定性和可用性的方法。

 

4） 对外提供的开放接口，不管是 RPC/API/HTTP 接口。

 

5） 敏感权限入口。

 

10. 【参考】下列情形，不需要进行参数校验：

 

     1） 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。

 

2） 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底

 

层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一台服务器中，所

 

以 DAO 的参数校验，可以省略。

 

3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参

 

数已经做过检查或者肯定不会有问题，此时可以不校验参数。

 

 

 

 

八：注释规约

 

1. 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用

 

/ xxx 方式。

 

说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。

 

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

 

说明：对子类的实现要求，或者调用注意事项，请一并说明。

 

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

 

4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。

 

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

 

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

 

反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。

 

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

 

说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。

 

8. 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。

 

说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。

 

9. 【参考】对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。

 

10. 【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

 

反例：

 

/ put elephant into fridge put(elephant, fridge);

 

方法名 put，加上两个有意义的变量名 elephant 和 fridge，已经说明了这是在干什么，语义清晰的代码不需要额外的注释。

 

11. 【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

 

1） 待办事宜（TODO）:（ 标记人，标记时间，[预计处理时间]）

 

表示需要实现，但目前还未实现的功能。这实际上是一个 Javadoc 的标签，目前的 Javadoc

 

还没有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个 Javadoc 标签）。

 

2） 错误，不能工作（FIXME）:（标记人，标记时间，[预计处理时间]）在注释中用 FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况