常温常新之阿里巴巴开发手册并发处理

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

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

正例：自定义线程工厂，并且根据外部特征进行分组，比如，来自同一机房的调用，把机房编号赋值给

whatFeatureOfGrouppublicclassUserThreadFactoryimplementsThreadFactory{privatefinalStringnamePrefix;privatefinalAtomicIntegernextId=newAtomicInteger(1);// 定义线程组名称，在利用 jstack 来排查问题时，非常有帮助UserThreadFactory(StringwhatFeatureOfGroup){namePrefix="From UserThreadFactory's "+whatFeatureOfGroup+"-Worker-";}@OverridepublicThreadnewThread(Runnabletask){Stringname=namePrefix+nextId.getAndIncrement();Threadthread=newThread(null,task,name,0,false);System.out.println(thread.getName());returnthread;}}

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

4. 【强制】线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
   说明：Executors 返回的线程池对象的弊端如下：
   1） FixedThreadPool 和 SingleThreadPool：
   允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
   2） CachedThreadPool：
   允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM

5. 【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为 static，必须加锁，或者使用 DateUtils 工具类。
   正例：注意线程安全，使用 DateUtils。亦推荐如下处理：

privatestaticfinalThreadLocal<DateFormat>df=newThreadLocal<DateFormat>(){@OverrideprotectedDateFormatinitialValue(){returnnewSimpleDateFormat("yyyy-MM-dd");}};

说明：如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。

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

objectThreadLocal.set(userInfo);try{// ...}finally{objectThreadLocal.remove();}

7. 【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
   说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。

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

9. 【强制】在使用阻塞等待获取锁的方式中，必须在 try 代码块之外，并且在加锁方法与 try 代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在 finally 中无法解锁。

说明一：如果在 lock 方法与 try 代码块之间的方法调用抛出异常，那么无法解锁，造成其它线程无法成功取锁。
说明二：如果 lock 方法在 try 代码块之内，可能由于其它方法抛出异常，导致在 finally 代码块中，unlock对未加锁的对象解锁，它会调用 AQS 的 tryRelease 方法（取决于具体实现类），抛出IllegalMonitorStateException 异常。
说明三：在 Lock 对象的 lock 方法实现中可能抛出 unchecked 异常，产生的后果与说明二相同。

10. 【强制】在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是否持有锁。锁的释放规则与锁的阻塞等待方式相同。
说明：Lock 对象的 unlock 方法在执行时，它会调用 AQS 的 tryRelease 方法（取决于具体实现类），如果当前线程不持有锁，则抛出 IllegalMonitorStateException 异常。

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

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

13.【推荐】资金相关的金融敏感信息，使用悲观锁策略。
说明：乐观锁在获得锁的同时已经完成了更新操作，校验逻辑容易出现漏洞，另外，乐观锁对冲突的解决策略有较复杂的要求，处理不当容易造成系统压力或数据异常，所以资金相关的金融敏感信息不建议使用乐观锁更新。
正例：悲观锁遵循一锁、二判、三更新、四释放的原则。

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

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

16.【推荐】通过双重检查锁（double-checked locking）（在并发场景下）存在延迟初始化的优化问题隐患（可参考 The “Double-Checked Locking is Broken” Declaration），推荐解决方案中较为简单一种（适用于 JDK5 及以上版本），将目标属性声明为 volatile 型，比如将 helper 的属性声明修改为private volatile Helper helper = null;。

publicclassLazyInitDemo{privatevolatileHelperhelper=null;publicHelpergetHelper(){if(helper==null){synchronized(this){if(helper==null){helper=newHelper();}}}returnhelper;}// other methods and fields...}

为啥helper判断两次？以及为啥被修饰为volatile类型的变量呢？
双重检查锁定（Double-Checked Locking, DCL） 模式，用于实现线程安全的懒加载（Lazy Initialization），它的核心目的是：在保证线程安全的前提下，尽可能减少同步锁（synchronized）带来的性能开销。
1. 为什么要判断两次？（双重检查的逻辑）
代码中有两个 if (helper == null) 判断：
第一次判断（锁外）：if (helper == null)
第二次判断（锁内）：if (helper == null)

第一次判断：为了性能（避免不必要的锁竞争）

• 场景：当 helper 已经被初始化后，绝大多数线程调用 getHelper() 时，helper 都不为 null。
• 作用：如果第一次判断发现 helper 不为 null，直接返回对象，完全不需要进入 synchronized 代码块。
• 收益：synchronized 是有性能开销的（涉及用户态/内核态切换、获取锁、释放锁等）。如果没有第一次判断，每次调用都要排队抢锁，即使对象已经创建好了，这会严重拖慢系统性能。

第二次判断：为了安全（防止重复创建）

• 场景：假设有两个线程 A 和 B 同时第一次调用 getHelper()
  1. 线程 A 执行第一次判断，发现 helper 为 null，准备进入锁
  2. 就在 A 进入锁之前，线程 B 也执行了第一次判断，发现 helper 依然为 null（因为 A 还没创建完），于是 B 也准备进入锁。
  3. 线程 A 抢到锁，进入内部，执行第二次判断（此时仍为 null），于是 new Helper()，赋值，释放锁。
  4. 线程 B 抢到锁，进入内部。如果没有第二次判断，B 也会执行 new Helper()，导致对象被创建了两次，且可能覆盖 A 创建的对象，造成逻辑错误或资源浪费。
• 作用：确保在多线程并发竞争锁的情况下，只有一个线程能真正执行创建对象的操作。
• 总结：外层判断：优化性能（大部分时间不走锁）。内层判断：保证正确性（防止并发下多次创建）。

2. 为什么要定义为 volatile？

这是 DCL 模式中最关键、也最容易被忽略的一点。如果没有 volatile，这段代码在多线程环境下是不安全的，可能会返回一个未初始化完成的“半成品的” Helper 对象。

根本原因：指令重排序（Instruction Reordering）

在 Java 中，helper = new Helper(); 这行代码并不是原子操作，它在底层字节码层面大致分为三步：

1. 分配内存：在堆内存中为 Helper 对象分配空间。
2. 初始化对象：调用构造函数，填充对象属性（执行 new Helper() 的逻辑）。
3. 引用赋值：将 helper 变量指向这块分配的内存地址。

在没有 volatile 修饰时，JVM 和 CPU 为了优化性能，可能会进行指令重排序。合法的执行顺序可能是：

• 正常顺序：1 -> 2 -> 3
• 重排序后：1 -> 3 -> 2 （先分配内存，立刻把地址赋给 helper 变量，最后再执行构造函数初始化）

发生的灾难场景（如果没有 volatile）
假设线程 A 正在初始化 helper，发生了重排序（1 -> 3 -> 2）：

1. 线程 A 分配了内存。
2. 线程 A 将helper 指向了内存地址（此时 helper != null）。
3. 但是！线程 A 还没来得及执行第 3 步（构造函数初始化对象属性）。
4. 此时，线程 B 调用了 getHelper()。
5. 线程 B 执行第一次判断 if (helper == null)。由于步骤 2 已经执行，helper 已经不是 null 了。
6. 线程 B 直接跳过 锁和第二次判断，返回了这个 helper 对象。
7. 线程 B 开始使用这个对象，但此时对象的属性还没有被初始化（步骤 3 还没跑），导致程序出现难以排查的脏数据错误或崩溃。

volatile 的作用
volatile 关键字有两个核心语义，正好解决了这个问题：

1. 禁止指令重排序：volatile 会插入内存屏障（Memory Barrier），强制保证上述三个步骤按 1 -> 2 -> 3 的顺序执行。只有当对象完全初始化好后，引用才会被赋值给 helper 变量。
2. 保证可见性：当线程 A 修改了 helper 的值，其他线程（如线程 B）能立即看到这个最新的值，而不是从自己的工作缓存中读取旧值。

一句话记忆：双重检查是为了快且对，volatile 是为了防止拿到半成品。

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

18.【参考】HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中注意规避此风险。

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