阿里巴巴Java开发手册学习小结5-并发处理

本次学习 来源 阿里巴巴Java开发手册 ，文档更新时间2016.12.7 是阿里巴巴集团技术部 首次向Java业界公开，如果有需要开发手册源文档的，欢迎联系

编程规范

并发处理

1.【强制】获取单例对象要线程安全，在对象里面做操作也要保证线程安全。
说明：资源驱动类，工具类，单例工厂类都需要注意。

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

3.【强制】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代替Simpledateformatter，官方给出的解释：simple beautiful strong immutable thread-safe。

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

5.【强制】对多个资源，数据库表，对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。
说明：线程一 需要对表A 、B、 C 依次 全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是A、B、C，否则可能出现死锁。

6.【强制】并发修改同一记录时，避免更新丢失，要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version 作为更新依据。
说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。

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

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

• 1 newFixedThreadPool 和 newSingleThreadExecutor ：主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至OOM。
• 2 newCacheThreadPool 和newScheduledThreadPool :主要问题是线程数最大数是Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至OOM。

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

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

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

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

14.【参考】注意HashMap的扩容死链，导致CPU飙升的问题。

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