阿里Java编程规约【六】 并发处理

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

如果延迟加载实现的单例需要并发控制；如果初始化的时候new单例对象，本身是线程安全的，取得实例方法不需要同步。

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

public class TimerTaskThread extends Thread {
    public TimerTaskThread() {
        super.setName("TimerTaskThread");
        ...
    }

3. 【强制】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
   说明：使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

一个是使用线程池缓存线程可以提高效率，另外线程池帮我们做了管理线程的事情，提供了优雅关机、interrupt等待IO的线程，饱和策略等功能。

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");
    }
};

说明：如果是 JDK 8 的应用，可以使用 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 则没有这个问题。

线程执行体、任务最上层等一定要抓住Throwable并进行相应的处理，否则会使线程终止。

10. 【推荐】使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown方法，线程执行代码注意 catch 异常，确保countDown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果。
    说明：注意，子线程抛出异常堆栈，不能在主线程 try - catch 到。

• CountDownLatch 存在于java.util.concurrent包下。CountDownLatch这个类能够使一个线程等待其他线程完成各自的工作后再执行。
• 请在try...finally语句里执行countDown方法，与关闭资源类似。

11. 【推荐】避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一seed 导致的性能下降。
    说明： Random 实例包括 java.util.Random 的实例或者 Math.random()的方式。
    正例：在 JDK 7 之后，可以直接使用 API ThreadLocalRandom ，而在 JDK 7 之前，需要编码保证每个线程持有一个实例。

可以把Random放在ThreadLocal里，只在本线程中使用。

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

正例:
(在jdk1.5及其后的版本中，可以将instance 设置成volatile以让双重检查锁定生效，
系统将不允许对一个volatile的写操作与之前的读写操作进行重排。而且对volatile的读操作也不会与后续的读写进行重排。如下)

public class Singleton {
    private static volatile Singleton instance = null;
    private Singleton(){}
   
    public static Singleton getInstance() {
       if(instance == null) {
           synchronized(Singleton.class) {
              if(instance == null) {
                  instance = new Singleton();
              }
           }
       }
       return instance;
    }
}

反例：

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...
}

参考The "Double-Checked Locking is Broken" Declaration

• 静态内部类(属于懒汉式)
  这种写法仍然使用JVM本身机制保证了线程安全问题；由于SingletonHolder是私有的，除了getInstance()之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖JDK版本。

这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式就显得很合理。

public class Singleton {  
 
    private static class SingletonHolder {  
        private static Singleton instance = new Singleton();  
    }  
  
    /** 
     * 私有的构造函数 
     */  
    private Singleton() {  
  
    }  
  
    public static Singleton getInstance() {  
        return SingletonHolder.instance;  
    } 
}

• 枚举方式
  这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。

public enum SingletonEnum {  
    /** 
     * 1.从Java1.5开始支持; 
     * 2.无偿提供序列化机制; 
     * 3.绝对防止多次实例化，即使在面对复杂的序列化或者反射攻击的时候; 
     */  
    instance;  
    private String others;  
    SingletonEnum() {  
  
       } 
    }

13. 【参考】 volatile 解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题。如果是 count ++操作，使用如下类实现：
    AtomicInteger count = new AtomicInteger(); count . addAndGet( 1 ); 如果是 JDK 8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好 （ 减少乐观锁的重试次数 ） 。

volatile只有内存可见性语义，synchronized有互斥语义，一写多读使用volatile就可以，多写就必须使用synchronized，fetch-mod-get也必须使用synchronized。

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

• 开发程序的时候要预估使用量，根据使用量来设置初始值。
• resize需要重建hash表，严重影响性能，会让程序产生长尾的响应时间。

15. 【参考】 ThreadLocal 无法解决共享对象的更新问题， ThreadLocal 对象建议使用 static修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象 ( 只要是这个线程内定义的 ) 都可以操控这个变量。

• 为解决多线程程序的并发问题提供了一种新思路。使用这个工具类可以很简洁地编写出优美的多线程程序。
  当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
• ThreadLocal实际上是一个从线程ID到变量的Map，每次取得ThreadLocal变量，实际上是先取得当前线程ID，再用当前线程ID取得关联的变量。
• ThreadLocal使用了WeakHashMap，在key被回收的时候，value也被回收了，不用担心内存泄露。

推荐书籍

• Java并发编程的艺术
• Java并发编程实战(前5章) 可下载 如何打开?

参考

• 《编写高质量代码：改善Java程序的151个建议》
    白话阿里巴巴Java开发手册（安全规约） - 李艳鹏 - 简书(https://www.jianshu.com/p/9528c4ea1504)