并发编程

Java学习

笔记内容来源：
1. jk：《Java并发编程实战》-王宝令（极客）
2. xn：《Java性能调优实战》-多线程性能调优-刘超（极客）

ListenableFuture

https://blog.csdn.net/PROGRAM_anywhere/article/details/83552126

tips

1. 《操作系统原理》----“并发编程最早的应用领域就是操作系统的实现”
2. github：https://github.com/CL0610/Java-concurrency

CPU缓存

1. 是什么
   
   • 在金字塔式存储体系中它位于自顶向下的第二层，仅次于CPU寄存器。（然后是内存-存储器[ROM\RAM\Cache]、外存-硬盘）
     存储 硬盘<内存(<缓存Cache)
   • 高速缓冲存储器Cache是位于CPU与内存之间的临时存储器，它的容量比内存小但交换速度快。

一、并发的优缺点

1. 为什么要用到并发

   • 充分利用多核CPU的计算能力；
     并发编程的形式可以将多核CPU的计算能力发挥到极致，性能得到提升。
   • 方便进行业务拆分，提升应用性能
     面对复杂业务模型，并行程序会比串行程序更适应业务需求，而并发编程更能吻合这种业务拆分 。

2. 并发编程有哪些缺点

   • 时间片是CPU分配给各个线程的时间，因为时间非常短，所以CPU不断通过切换线程，让我们觉得多个线程是同时执行的，时间片一般是几十毫秒。而每次切换时，需要保存当前的状态起来，以便能够进行恢复先前状态，而这个切换时非常损耗性能，过于频繁反而无法发挥出多线程编程的优势。

3. 减少上下文切换
   通常减少上下文切换可以采用无锁并发编程，CAS算法，使用最少的线程和使用协程。

   • 无锁并发编程：可以参照concurrentHashMap锁分段的思想，不同的线程处理不同段的数据，这样在多线程竞争的条件下，可以减少上下文切换的时间。
   • CAS算法，利用Atomic下使用CAS算法来更新数据，使用了乐观锁，可以有效的减少一部分不必要的锁竞争带来的上下文切换
   • 使用最少线程：避免创建不需要的线程，比如任务很少，但是创建了很多的线程，这样会造成大量的线程都处于等待状态
   • 协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换
   • 
     Lmbench3测量上下文切换的时长 vmstat测量上下文切换次数

问题

1. 线程切换的问题

1. 问题：抢购活动-多线程（xn）
   
   • 分析问题：通过工具分析，发现 cs（上下文切换每秒次数）指标已经接近了 60w，平时的话最高 5w。再通过日志分析，我发现了大量带有 wait() 的 Exception。
   • 初步怀疑是大量线程处理不及时导致的，进一步锁定问题是连接池大小设置不合
     理。
   • 解决：模拟了生产环境配置，对连接数压测进行调节，降低最大线程数，最后系统的性能就上去了。
   • 经验：并发程序中，并不是启动更多的线程就能让程序最大限度地并发执行。线程数量设置太小，会导致程序不能充分地利用系统资源；线程数量设置太大，又可能带来资源的过度竞争，导致上下文切换带来额外的系统开销

--------------------分割线------------

1. 并发理论基础

1-预备知识

1-上下文切换

1. 时间片？

   • CPU 时间片是 CPU 分配给每个线程执行的时间段，一般为几十毫秒
   • 处理器给每个线程分配 CPU 时间片（Time Slice），线程在分配获得的时间片内执行任务。
   • 时间片决定了一个线程可以连续占用处理器运行的时长。

2. 上下文切换是什么？

   • 当一个线程的时间片用完了，或者因自身原因被迫暂停运行了，这个时候，另外一个线程（可以是同一个线程或者其它进程的线程）就会被操作系统选中，来占用处理器。这种一个线程被暂停剥夺使用权，另外一个线程被选中开始或者继续运行的过程就叫做上下文切换（Context Switch）。
   • 上下文：一个线程被剥夺处理器的使用权而被暂停运行，就是“切出”；一个线程被选中占用处理器开始或者继续运行，就是“切入”。在这种切出切入的过程中，操作系统需要保存和恢复相应的进度信息，这个进度信息就是“上下文”了。
   • 下文包含内容：寄存器的存储内容以及程序计数器存储的指令内容。
     -- CPU 寄存器负责存储已经、正在和将要执行的任务
     -- 程序计数器负责存储CPU 正在执行的指令位置以及即将执行的下一条指令的位置。
   • 分类：
     -- 进程间的上下文切换
     多线程编程中，主要为线程间的上下文切换导致的性能问题
     -- 线程间的上下文切换

3. 多核下的上下文切换？

   • CPU 数量远远不止一个的情况：
     操作系统将 CPU轮流分配给线程任务，此时的上下文切换就变得更加频繁了，并且存在跨 CPU 上下文切换，比起单核上下文切换，跨核切换更加昂贵。

4. 多线程上下文切换的原因？

   • 线程主要有“新建”（NEW）、“就绪”（RUNNABLE）、“运行”（RUNNING）、“阻
     塞”（BLOCKED）、“死亡”（DEAD）五种状态。
   • 线程由RUNNABLE转为非RUNNABLE 的过程就是线程上下文切换；
   • 一个线程的状态由 RUNNING 转为 BLOCKED ，再由BLOCKED 转为 RUNNABLE ，然后再被调度器选中执行，这就是一个上下文切换的过程。
   • 当一个线程从RUNNING状态转为BLOCKED状态时，我们称为一个线程的暂停，线程暂停被切出之后，操作系统会保存相应的上下文，以便这个线程稍后再次进入RUNNABLE 状态时能够在之前执行进度的基础上继续执行。
   • 当一个线程从BLOCKED状态进入到RUNNABLE状态时，我们称为一个线程的唤醒，此时线程将获取上次保存的上下文继续完成执行。
   • 总结：多线程的上下文切换实际上就是由多线程两个运行状态的互相切换导致的。

5. 线程运行时，各状态之间转换的原因？

   • 如线程状态由RUNNING转为BLOCKED或者由BLOCKED转为RUNNABLE；
   • 2种原因：
     -- 程序本身触发的切换，称为自发性上下文切换
     -- 由系统或者虚拟机诱发的非自发性上下文切换。

6. 自发性上下文切换？

   • 概念：线程由 Java 程序调用导致切出，在多线程编程中，执行调用以下方法或关键字，常常就会引发自发性上下文切换。
   • sleep()、wait()、yield()、join()、park()、synchronized、lock

7. 非自发性上下文切换？

   • 概念：
     指线程由于调度器的原因被迫切出。
   • 常见：
     -- 线程被分配的时间片用完，
     -- 虚拟机垃圾回收导致
     -- 执行优先级的问题导致。
   • JVM垃圾回收，原因
     JVM中，对象的内存都是由虚拟机中的堆分配的，在程序运行过程中，新的对象将不断被创建，如果旧的对象使用后不进行回收，堆内存将很快被耗尽。JVM提供了一种回收机制，对创建后不再使用的对象进行回收，从而保证堆内存的可持续性分配。而这种垃圾回收机制的使用有可能会导致stop-the-world事件的发生，这其实就是一种线程暂停行为。

8. 上下文切换性能问题？
   串行和并行代码的比较：

   • 串联的执行速度比并发的执行速度要快。因为线程的上下文切换导致了额外的开销，
   • 使用 Synchronized 锁关键字，会导致了资源竞争，从而引起了上下文切换
   • 即使不使用 Synchronized锁关键字，并发的执行速度也无法超越串联的执行速度，这是因为多线程同样存在着上下文切换。
   • Redis、NodeJS 的设计就很好地体现了单线程串行的优势。

9. 如何监测到上下文切换？

   • Linux
     vmstat命令：监视Java程序运行过程中系统的上下文切换频率；
     pidstat命令：监控指定进程的Context Switch上下文切换

10. 上下文切换到底开销在哪些环节？

    • 操作系统保存和恢复上下文；
    • 调度器进行线程调度；
    • 处理器高速缓存重新加载；
    • 上下文切换也可能导致整个高速缓存区被冲刷，从而带来时间开销

11. 在并发量比较大的情况下，什么时候用单线程，什么时候用多线程呢？

    • 一般在单个逻辑比较简单，而且速度相对来非常快的情况下，我们可以使用单线程。
      例如，Redis，从内存中快速读取值，不用考虑 I/O 瓶颈带来的阻塞问题。
    • 在逻辑相对来说很复杂的场景，等待时间相对较长又或者是需要大量计算的场景，我建议使用多线程来提高系统的整体性能。
      例如，NIO时期的文件读写操作、图像处理以及大数据分析等。

12. 在多线程中使用Synchronized还会发生进程间的上下文切换吗？具体又会发生在哪些环节呢？

    • 进程上下文切换，是指用户态和内核态的来回切换。我们知道，如果一旦Synchronized锁资源竞争激烈，线程将会被阻塞，阻塞的线程将会从用户态调用内核态，尝试获取mutex，这个过程就是进程上下文切换。
    • 使用Synchronized获得锁失败，进入等待队列会发生上下文切换。
    • Synchronized在轻量级锁之前，锁资源竞争产生的是线程上下文切换，一旦升级到重量级锁，就会产生进程上下文切换

2-线程的生命周期状态

1. 图示
   
   • 线程主要有“新建”（NEW）、“就绪”（RUNNABLE）、“运行”（RUNNING）、“阻塞”（BLOCKED）、“死亡”（DEAD）五种状态。
     

3-管程

1. 参考：
   本节说的可能并不好。该篇我看了三遍也没能完全看懂，于是自己搜索java管程相关的技术文章，才大致对管程有了个认知，总结如下：
   1.管程是一种概念，任何语言都可以通用。
   2.在java中，每个加锁的对象都绑定着一个管程（监视器）
   3.线程访问加锁对象，就是去拥有一个监视器的过程。如一个病人去门诊室看医生，医生是共享资源，门锁锁定医生，病人去看医生，就是访问医生这个共享资源，门诊室其实是监视器（管程）。
   4.所有线程访问共享资源，都需要先拥有监视器。就像所有病人看病都需要先拥有进入门诊室的资格。
   5.监视器至少有两个等待队列。一个是进入监视器的等待队列一个是条件变量对应的等待队列。后者可以有多个。就像一个病人进入门诊室诊断后，需要去验血，那么它需要去抽血室排队等待。另外一个病人心脏不舒服，需要去拍胸片，去拍摄室等待。
   6.监视器要求的条件满足后，位于条件变量下等待的线程需要重新在门诊室门外排队，等待进入监视器。就像抽血的那位，抽完后，拿到了化验单，然后，重新回到门诊室等待，然后进入看病，然后退出，医生通知下一位进入。
   总结起来就是，管程就是一个对象监视器。任何线程想要访问该资源，就要排队进入监控范围。进入之后，接受检查，不符合条件，则要继续等待，直到被通知，然后继续进入监视器。

2. 管程的发展？

   • 管程是一把解决并发问题的万能钥匙；
   • Java1.5前，提供的唯一的并发原语就是管程；
   • Java1.5后，提供的SDK并发包，也是以管程技术为基础的。
   • 除此之外，C/C++、C# 等高级语言也都支持管程。

3. 为什么Java在1.5之前仅仅提供了synchronized关键字及wait()、notify()、notifyAll()这三个看似从天而降的方法？
   在刚接触Java的时候，我以为它会提供信号量这种编程原语，因为操作系统原理课程告诉我，用信号量能解决所有并发问题，结果我发现不是。

   • 原因：
   • Java 采用的是管程技术，synchronized关键字及wait()、notify()、notifyAll()这三个方法都是管程的组成部分。
   • 管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。但是管程更容易使用，所以 Java 选择了管程。

4. 什么是管程？

   • 管程，英文是 Monitor，Java领域多直译监视器。操作系统领域翻译成管程。
   • 管程指的是管理共享变量以及对共享变量的操作过程，让他们支持并发。
   • 翻译为Java领域的语言，就是管理类的成员变量和成员方法，让这个类是线程安全的。

5. 管程如何管理？

   • 管程模型：MESA 模型
   • 发展：先后出现过三种不同的管程模型，分别是：Hasen模型、Hoare模型和MESA模型。
   • 现广泛应用的是MESA模型
   • Java管程的实现参考的也是MESA模型。

6. MESA模型介绍？

   • 在并发编程领域，有两大核心问题：
     -- 互斥，即同一时刻只允许一个线程访问共享资源；
     -- 同步，即线程之间如何通信、协作。
   • 这两大问题，管程都是能够解决的。
   • 管程如何解决互斥问题？
     -- 将共享变量及其对共享变量的操作统一封装起来。
     -- 管程X将共享变量queue这个队列和相关的操作入队enq()、出队deq()都封装起来；线程A和B如果想访问共享变量queue，只能通过调用管程提供的enq()、deq()方法来实现；enq()、deq()保证互斥性，只允许一个线程进入管程。
     -- 管程模型和面向对象高度契合。估计这也是Java选择管程的原因吧。
     -- 后面的互斥锁背后的模型其实就是它。
     
   • 管程如何解决线程间同步问题？
     -- 如下，MESA管程模型示意图，详细描述MESA模型的主要组成部分。
     -- 在管程模型里，共享变量和对共享变量的操作是被封装起来的，最外层的框就代表封装。框的上面只有一个入口，并且在入口旁边还有一个入口等待队列。当多个线程同时试图进入管程内部时，只允许一个线程进入，其他线程则在入口等待队列中等待。
     -- 管程里还引入了条件变量的概念，而且每个条件变量都对应有一个等待队列，如图，条件变量A 和条件变量 B 分别都有自己的等待队列。
     
   • 条件变量和等待队列的作用是什么呢？
     -- 解决线程同步问题。
     -> 假设有个线程T1执行出队操作，操作前提条件是队列不能是空的，而队列不空这个前提条件就是管程里的条件变量。
     -> 如果线程T1进入管程后恰好发现队列是空的，就去条件变量对应的等待队列里面等。此时线程T1就去“队列不空”这个条件变量的等待队列中等待。
     -> 线程T1进入条件变量的等待队列后，是允许其他线程进入管程的。
     -> 再假设之后另外一个线程T2执行入队操作，入队操作执行成功之后，“队列不空”这个条件对于线程 T1 来说已经满足了，此时线程T2要通知T1，告诉它需要的条件已经满足了。当线程 T1得到通知后，会从等待队列里面出来，但是出来之后不是马上执行，而是重新进入到入口等待队列里面。
   • 说一下wait()、notify()、notifyAll() 这三个操作？
     -- 前面线程T1发现“队列不空”这个条件不满足，需要进到对应的等待队列里等待。这个过程就是通过调用wait()来实现的。如果用对象A代表“队列不空”这个条件，那么线程T1需要调用A.wait()。同理当“队列不空”这个条件满足时，线程T2需要调用A.notify()来通知A等待队列中的一个线程，此时这个队列里面只有线程T1。至于notifyAll() 这个方法，它可以通知等待队列中的所有线程。

7. 代码再次说明MESA模型？

   • 代码实现一个阻塞队列，阻塞队列有两个操作分别是入队和出队，这两个方法都是先获取互斥锁，类比管程模型中的入口。
     1) 对于入队操作，如果队列已满，就需要等待直到队列不满，所以这里用了notFull.await();
     2) 对于出队操作，如果队列为空，就需要等待直到队列不空，所以就用了notEmpty.await();
     3) 如果入队成功，那么队列就不空了，就需要通知条件变量：队列不空notEmpty对应的等待队列;
     4) 如果出队成功，那就队列就不满了，就需要通知条件变量：队列不满notFull对应的等待队列。

     public class BlockedQueue<T> {
         final Lock lock = new ReentrantLock();
         // 条件变量：队列不满
         final Condition notFull = lock.newCondition();
         // 条件变量：队列不空
         final Condition notEmpty = lock.newCondition();
         // 入队
         void enq(T x) {
             lock.lock();
             try {
                 while (队列已满)
                     // 等待队列不满
                     notFull.await();
                 // 省略入队操作...
                 // 入队后, 通知可出队
                 notEmpty.signal();
             } finally {
                 lock.unlock();
             }
         }
         // 出队
         void deq() {
             lock.lock();
             try {
                 while (队列已空)
                     // 等待队列不空
                     notEmpty.await();
                 // 省略出队操作...
                 // 出队后，通知可入队
                 notFull.signal();
             } finally {
                 lock.unlock();
             }
         }
     }

   • 示例中，用了Java并发包里面的Lock和Condition。
     注意：await()和前面我们提到的wait()语义是一样的；signal()和前面我们提到的notify()语义是一样的。

8. wait() 的正确姿势？

   • 对于MESA管程来说，有一个编程范式，就是需要在一个while循环里面调用wait()。这个是MESA管程特有的。

     while(条件不满足) {
          wait();
     }

   • Hasen模型、Hoare模型和MESA模型的一个核心区别就是当条件满足后，如何通知相关线程。

   • 管程要求同一时刻只允许一个线程执行，那当线程T2的操作使线程T1等待的条件满足时，T1 和 T2 究竟谁可以执行呢？
     1）Hasen 模型里面，要求 notify() 放在代码的最后，这样 T2 通知完 T1 后，T2 就结束了，然后 T1 再执行，这样就能保证同一时刻只有一个线程执行。
     2）Hoare 模型里面，T2 通知完 T1 后，T2 阻塞，T1 马上执行；等 T1 执行完，再唤醒 T2，也能保证同一时刻只有一个线程执行。但是相比 Hasen 模型，T2 多了一次阻塞唤醒操作。
     3）MESA 管程里面，T2通知完T1后，T2还是会接着执行，T1并不立即执行，仅仅是从条件变量的等待队列进到入口等待队列里面。这样做的好处是notify() 不用放到代码的最后，T2也没有多余的阻塞唤醒操作。但是也有个副作用，就是当 T1 再次执行的时候，可能曾经满足的条件，现在已经不满足了，所以需要以循环方式检验条件变量。

9. notify()何时可以使用？

   • 除非经过深思熟虑，否则尽量使用notifyAll()。
   • notify()的使用需要满足以下三个条件：
     1）所有等待线程拥有相同的等待条件；
     2）所有等待线程被唤醒后，执行相同的操作；
     3）只需要唤醒一个线程。
   • 比如上面阻塞队列的例子中，对于“队列不满”这个条件变量，其阻塞队列里的线程都是在等待“队列不满”这个条件，反映在代码里就是下面这3行代码。对所有等待线程来说，都是执行这3行代码，重点是while里面的等待条件是完全相同的。
     

     while (队列已满)
      // 等待队列不满
      notFull.await()

   所有等待线程被唤醒后执行的操作也是相同的，都是下面这几行：

   // 省略入队操作...
   // 入队后, 通知可出队
   notEmpty.signal();

   同时也满足第 3 条，只需要唤醒一个线程。所以上面阻塞队列的代码，使用 signal() 是可以的。

10. Java内置的管程？

    • Java 参考了 MESA 模型，语言内置的管程（synchronized）对 MESA 模型进行了精简。
    • MESA模型中，条件变量可以有多个，Java语言内置的管程里只有一个条件变量。
      
    • Java内置的管程方案（synchronized）使用简单，synchronized关键字修饰的代码块，在编译期会自动生成相关加锁和解锁的代码，但是仅支持一个条件变量；
    • 而Java SDK并发包实现的管程支持多个条件变量，不过并发包里的锁，需要开发人员自己进行加锁和解锁操作。

3. 数据一致性

1-一致性概念

1. 主要内容？
   “并发编程中共享变量的一致性”。
   CPU缓存导致的数据不一致、重排序

2. 结合Happens-before规则，可以将一致性分为以下几个级别：

   • 严格一致性（强一致性）：所有的读写操作都按照全局时钟下的顺序执行，且任何时刻线程读取到的缓存数据都是一样的，Hashtable 就是严格一致性；
     
   • 顺序一致性：多个线程的整体执行可能是无序的，但对于单个线程而言执行是有序的，要保证任何一次读都能读到最近一次写入的数据，volatile可以阻止指令重排序，所以修饰的变量的程序属于顺序一致性；
     
   • 弱一致性：不能保证任何一次读都能读到最近一次写入的数据，但能保证最终可以读到写入的数据，单个写锁 + 无锁读，就是弱一致性的一种实现。

3. Happens-before 规则?

   • 为了解决重排序问题，Java 提出了 Happens-before 规则来规范线程的执行顺序：
     ① 程序次序规则：在单线程中，代码的执行是有序的，虽然可能会存在运行指令的重排序，但最终执行的结果和顺序执行的结果是一致的；
     ② 锁定规则：一个锁处于被一个线程锁定占用状态，那么只有当这个线程释放锁之后，其它线程才能再次获取锁操作；
     ③ volatile 变量规则：如果一个线程正在写 volatile 变量，其它线程读取该变量会发生在写入之后；
     ④ 线程启动规则：Thread 对象的 start() 方法先行发生于此线程的其它每一个动作；
     ⑤ 线程终结规则：线程中的所有操作都先行发生于对此线程的终止检测；
     ⑥ 对象终结规则：一个对象的初始化完成先行发生于它的 finalize() 方法的开始；
     ⑦ 传递性：如果操作 A happens-before 操作 B，操作 B happens-before 操作 C，那么操作 A happens-before 操作 C；
     ⑧ 线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生。

2-不一致原因

1. 多线程操作共享变量可能出现的问题?

   • 假设有两个线程（线程 1 和线程 2）分别执行下面的方法，x 是共享变量：

     // 代码 1
     public class Example {
          int x = 0;
          public void count() {
              x++; //1
              System.out.println(x)//2
              }
     }
     

   • 两个线程同时运行，线程的变量的值可能的结果：

   线程1调用count	线程2调用count
   x++;	x++;

   结果：

   结果1	结果2	结果3
   1,1	2,1	1,2

2. CPU缓存-理解"1,1"的情况？

   • CPU缓存可以分为一级缓存（L1）、二级缓存（L2）和三级缓存（L3），每一级缓存中所储存的全部数据都是下一级缓存的一部分。当CPU要读取一个缓存数据时，首先会从一级缓存中查找；如果没有找到，再从二级缓存中查找；如果还是没有找到，就从三级缓存或内存中查找。
   • 单核CPU：
     如果是单核CPU运行多线程，多个线程同时访问进程中的共享数据，CPU 将共享变量加载到高速缓存后，不同线程在访问缓存数据的时候，都会映射到相同的缓存位置，这样即使发生线程的切换，缓存仍然不会失效。
   • 多核CPU：
     如果是多核CPU运行多线程，每个核都有一个L1缓存，如果多个线程运行在不同的内核上访问共享变量时，每个内核的 L1 缓存将会缓存一份共享变量。
     

3. CPU缓存-理解"1,1"的情况？
   1,1 的运行结果：

   • 如果是多核 CPU 运行多线程，每个核都有一个 L1 缓存，如果多个线程运行在不同的内核上访问共享变量时，每个内核的 L1缓存将会缓存一份共享变量。
   • 假设线程 A 操作 CPU 从堆内存中获取一个缓存数据，此时堆内存中的缓存数据值为 0，该缓存数据会被加载到 L1 缓存中，在操作后，缓存数据的值变为 1，然后刷新到堆内存
     中。
   • 在正好刷新到堆内存中之前，又有另外一个线程 B 将堆内存中为 0 的缓存数据加载到了另外一个内核的 L1 缓存中，此时线程 A 将堆内存中的数据刷新到了 1，而线程 B 实际拿到的缓存数据的值为 0。
   • 此时，内核缓存中的数据和堆内存中的数据就不一致了，且线程 B在刷新缓存到堆内存中的时候也将覆盖线程 A中修改的数据。这时就产生了数据不一致的问题。
     

4. 重排序问题？

   • 在不影响运算结果的前提下，编译器有可能会改变顺序代码的指令执行顺序，特别是在一些可以优化的场景。

   // 代码 1
   public class Example {
        int x = 0;
        boolean flag = false;
        public void writer() {
             x = 1; //1
            flag = true; //2
        }
        public void reader() {
            if (flag) { //3
                int r1 = x; //4
                System.out.println(r1==x)
            }
        }
   }

   

   • r1=1 的运行结果如下：
     
   • r1=0 的运行结果如下：
     

5. 重排序-问题解析？

   • 在JVM中，重排序是十分重要的一环，特别是在并发编程中。可JVM要是能对它们进行任意排序的话，也可能会给并发编程带来一系列的问题，其中就包括了一致性的问题。
   • 编译器为了尽可能地减少寄存器的读取、存储次数，会充分复用寄存器的存储值。如果没有进行
     重排序优化，正常的执行顺序是步骤1\2\3，而在编译期间进行了重排序优化之后，执行的步骤有可能就变成了步骤1/3/2 或者 2/1/3，这样就能减少一次寄存器的存取次数。
     

     int x = 1;//步骤1：加载x变量的内存地址到寄存器中，加载1到寄存器中，CPU通过mov指令把1写入到寄存器指定的内存中
     boolean flag = true; //步骤2 加载flag变量的内存地址到寄存器中，加载true到寄存器中，CPU通过mov指令把1写入到寄存器指定的内存中
     int y = x + 1;//步骤3 重新加载x变量的内存地址到寄存器中，加载1到寄存器中，CPU通过mov指令把1写入到寄存器指定的内存中

3. 其他基本概念

1. 临界区？

   • 一段需要互斥执行的代码称为临界区。

2. 管程？

   • 一种通用的同步原语，在Java中指的就是synchronized，synchronized是Java里对管程的实现。
   • 管程中的锁在Java里是隐式实现的
     例如下面的代码，在进入同步块之前，会自动加锁，而在代码块执行完会自动释放锁，加锁以及释放锁都是编译器帮我们实现的。
     

     synchronized (this)
     { // 此处自动加锁 
         // x 是共享变量, 初始值 =10 
         if (this.x < 12) {
             this.x = 12;
         }
     } // 此处自动解锁

2-并发基础理论

1. 并发编程中的问题

1. 总结？
   
   • 并发编程微观上涉及到原子性问题、可见性问题和有序性问题，宏观则表现为安全性、活跃性以及性能问题。
   • 在设计并发程序的时候，主要是从宏观出发，也就是要重点关注它的安全性、活跃性以及性能。安全性方面要注意数据竞争和竞态条件，活跃性方面需要注意死锁、活锁、饥饿等问题，性能方面介绍了两个方案，但具体问题具体分析。

1-安全性问题

1. 什么是线程安全呢？

   • 本质上就是正确性
   • 正确性的含义就是程序按照我们期望的执行

2. 如何写出线程安全的程序呢？

   • 并发Bug的三个主要源头：原子性问题、可见性问题和有序性问题。
   • 理论上线程安全的程序，就要避免出现原子性问题、可见性问题和有序性问题。

3. 所有的代码都需要分析否存在这三个问题吗？

   • 只有一种情况：
     存在共享数据并且该数据会发生变化，通俗地讲就是有多个线程会同时读写同一数据。
   • 解决一：
     -- 不共享数据或者数据状态不发生变化。
     -- 方案：如线程本地存储（Thread Local Storage，TLS）、不变模式等等。
   • 解决二：
     现实中，必须共享会发生变化的数据的应用场景还很多。

4. 什么叫数据竞争？

   • 概念：
     当多个线程同时访问同一数据，并且至少有一个线程会写这个数据的时候，如果我们不采取防护措施，那么就会导致并发Bug，对此还有一个专业的术语，叫做数据竞争（Data Race）
   • 例子1：
     如下，当多个线程调用add10k()方法时就会发生数据竞争。
     

     public class Test {
          private long count = 0;
              void add10K() {
                  int idx = 0;
                  while(idx++ < 10000) {
                     count += 1;
              }
          }
     }

5. 竞态条件（Race Condition）？

   • 概念
   • 指的是程序的执行结果依赖线程执行的顺序。
   • 在并发环境里，线程的执行顺序是不确定的，如果程序存在竞态条件问题，那就意味着程序执行的结果是不确定的，而执行结果不确定这可是个大Bug。
   • 抽象理解
     理解竞态条件：并发场景中，程序的执行依赖于某个状态变量，类似于：
     

     if (状态变量 满足 执行条件) {
         执行操作
     }

   -- 当某个线程发现状态变量满足执行条件后，开始执行操作；可是就在这个线程执行操作的时候，其他线程同时修改了状态变量导致状态变量不满足执行条件了。当然很多场景下，这个条件不是显式的。

   • 例子2-1：例子1加锁
     -- 在访问数据的地方加个锁保护，如下：
     -- 所有访问共享变量value的地方，都增加了互斥锁，此时是不存在数据
     竞争的。但add10K()并不是线程安全的。

     public class Test {
         private long count = 0;
         // synchronized
         synchronized long get(){
             return count；
         }
         // synchronized
         synchronized void set(long v){
             count = v;
         }
         void add10K() {
             int idx = 0;
             while(idx++ < 10000) {
                 set(get()+1) 
             }
         }
     }

   • 问题：竞态条件
     -- 假设count=0，A、B两个线程同时执行get()方法时，get()方法会返回相同的值0，A、B执行get()+1操作，结果都是1，之后A、B再将结果1写入了内存。期望是 2，而结果却是1。
     -- A、B完全同时执行，结果是 1；A、B前后执行，结果是2。

   • 例子2-2：转账操作
   • 转账操作里面有个判断条件——转出金额不能大于账户余额，但在并发环境里面，如果不加控制，当多个线程同时对一个账号执行转出操作时，就有可能出现超额转出问题。
   • 假设，账户A余额200，线程1、2都要从账户A转出150，存在程1、2同时执行到第6行，这样1和2都会发现转出金额150小于账户余额200，于是就会发生超额转出的情况。
     

     class Account {
         private int balance;
         // 转账
         void transfer(Account target, int amt){
             if (this.balance > amt) { // 6
                 this.balance -= amt; // A-150
                 target.balance += amt;//B+150
             }
          }
     }

6. 数据竞争、竞态条件如何保证线程安全？

   • 互斥这个技术方案
   • 实现互斥的方案，如CPU提供了相关的互斥指令，操作系统、编程语言
     也会提供相关的API。从逻辑上来看，可以统一归为：锁。

2-活跃性问题

1. 活跃性问题概念？

   • 指的是某个操作无法执行下去。
   • 典型的活跃性问题：死锁，还有活锁、饥饿两种情况

2. 死锁、活锁、饥饿？

   • 1-死锁：发生“死锁”后，线程会互相等待，而且会一直等待下去，技术上表现形式是线程永久地“阻塞”了。
   • 2-活锁：线程没发生阻塞，但仍存在执行不下去的情况。
   • 活锁例子：
     -- 类比，路人甲从左边出门，乙从右边进门，为了不相撞，互相谦让，甲让路走右边，乙也让甲走左边，结果又相撞。基于人的交流，谦让几次就解决了。而编程世界，有可能会一直谦让下去，成为没有发生阻塞但依然执行不下去的活锁。
     -- 解决
     尝试等待一个随机的时间。甲走左发现前面有人，并不是立刻换到右手边，而是等待一个随机的时间后，再换到边；同样，路人乙也不是立刻切换路线，也是等待一个随机的时间再切换。由于路人甲和路人乙等待的时间是随机的，所以同时相撞后再次相撞的概率就很低了。“等待一个随机时间”的方案虽然很简单，却非常有效
   • 3-饥饿
     -- 指的是线程因无法访问所需资源而无法执行下去的情况。
     “不患寡，而患不均”，如果线程优先级“不均”，在CPU繁忙的情况下，优先级低的线程得到执行的机会很小，就可能发生线程“饥饿”；持有锁的线程，如果执行的时间过长，也可能导致“饥饿”问题。
   • 饥饿三种解决方案
     -- 一是保证资源充足，二是公平地分配资源，三就是避免持有锁的线程长时间执行。
     -- 一、三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。二的适用场景相对来说更多一些。
   • 如何公平地分配资源
     -- 并发编程里，主要是使用公平锁。
     -- 公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

3-性能问题

1. 性能问题？

   • 过度使用锁，也可能出“性能问题”。
   • “锁”的过度使用可能导致串行化的范围过大，不能够发挥多线程的优势了，而使用多线程搞并发程序的目的，主要为的就是提升性能。
   • 所以我们要尽量减少串行

2. 串行对性能的影响是怎么样的呢？
   假设串行百分比是 5%，用多核多线程相比单核单线程能提速多少呢？

   • 阿姆达尔（Amdahl）定律，代表了处理器并行运算之后效率提升的能力：
     20201127015019225.png#pic_center未知大小
     其中，n理解为CPU的核数，p可以理解为并行百分比，那（1-p）就是串行百分比了，也就是我们假设的5%。再假设CPU的核数（也就是n）无穷大，那加速比 S 的极限就是20。
     即，如果我们的串行率是5%，那么无论采用什么技术，最高也就只能提高 20倍的性能。

3. 怎么避免锁带来的性能问题呢？
   方案层面：

   • 第一，既然使用锁会带来性能问题，那最好的方案自然就是使用无锁的算法和数据结构了。
     -- 实现：如线程本地存储 (Thread Local Storage, TLS)、写入时复制(Copyon-write)、乐观锁等；Java并发包里面的原子类也是一种无锁的数据结构；Disruptor则是一个无锁的内存队列，性能都非常好……
   • 第二，减少锁持有的时间。互斥锁本质上是将并行的程序串行化，所以要增加并行度，一定要减少持有锁的时间。
     -- 实现：如使用细粒度的锁，一个典型的例子就是 Java 并发包里的 ConcurrentHashMap，使用了所谓分段锁的技术；还可以使用读写锁，也就是读是无锁的，只有写的时候才会互斥。

4. 性能方面的三个重要度量指标？

   • 吞吐量、延迟和并发量。
   • 吞吐量：指的是单位时间内能处理的请求数量。吞吐量越高，说明性能越好。
   • 延迟：指的是从发出请求到收到响应的时间。延迟越小，说明性能越好。
   • 并发量：指的是能同时处理的请求数量，一般来说随着并发量的增加、延迟也会增加。所以延迟这个指标，一般都会是基于并发量来说的。例如并发量是 1000 的时候，延迟是 50 毫秒。

1. 可见性、原子性、有序性

1. 并发问题的根源（CPU、内存、I/O）？
   1）缓存导致的可见性问题
   2）线程切换带来的原子性问题
   3）CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符

1. 可见性

1. 可见性概念
   一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。

2. 缓存导致的可见性问题？

   • 单核，所有线程都是操作同一个CPU的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。
   • 多核，每个CPU都有自己的缓存，当多个线程在不同的CPU上执行时，这些线程操作的是不同的CPU缓存。

3. 验证多核场景下的可见性问题

   public class Test {
   private static long count =0;
   private void add10K(){
       int idx=0;
       while (idx++<100000){
           count+=1;
       }
   }
   private static long calc(){
       final Test test =new Test();
       //创建两个线程，执行 add() 操作
       Thread thread1=new Thread(()->{
           test.add10K();
       });
       Thread thread2=new Thread(()->{
           test.add10K();
       });
       //启动两个线程
       thread1.start();
       thread2.start();
       //等待两个线程执行结束
       try {
           thread1.join();
           thread2.join();
       } catch (InterruptedException e) {
           e.printStackTrace();
       }
       System.out.println(count);
       return count;
   }
   public static void main(String[] args) {
       calc();
   }
   }

   • add10K() 方法，都会循环 10000 次 count+=1 操作。（10000次太少）
   • calc() 方法中我们创建了两个线程，每个线程调用一次 add10K()
   • 循环 10000 次 count+=1操作如果改为循环 1亿次，你会发现效果更明显，最终 count的值接近 1 亿，而不是 2 亿。如果循环 10000 次，count的值接近20000，原因是两个线程不是同时启动的，有一个时差。

2. 原子性

1. 时间片

   • 操作系统允许某个进程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），这个 50 毫秒称为“时间片”。

2. 原子性概念

   • 我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。

3. 线程切换
   

   • 在一个时间片内，如果一个进程进行一个 IO 操作，例如读个文件，这个时候该进程可以把自己标记为“休眠状态”并出让 CPU 的使用权，待文件读进内存，操作系统会把这个休眠的进程唤醒，唤醒后的进程就有机会重新获得 CPU 的使用权了。
   • 这里的进程在等待 IO 时之所以会释放 CPU 使用权，是为了让 CPU 在这段等待时间里可以做别的事情，这样一来 CPU 的使用率就上来了；此外，如果这时有另外一个进程也读文件，读文件的操作就会排队，磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样 IO 的使用率也上来了。

4. 任务切换->线程切换发展

   • 早期的操作系统基于进程来调度CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，
   • 一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。
   • 现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。

5. count+=1
   1）CPU指令

   • 任务切换的时机大多数是在时间片结束的时候
   • 高级语言里一条语句往往需要多条 CPU 指令完成
   • 操作系统做任务切换，可以发生在任何一条CPU 指令执行完
   • CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符，

   2）执行顺序
   

   • count += 1，至少需要三条 CPU 指令
     

     指令 1：把变量 count 从内存加载到 CPU 的寄存器；
     指令 2：在寄存器中执行 +1 操作；
     指令 3：将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

   • 假设 count=0，
     A 在指令 1 执行完后做线程切换，
     A、B 如下序列执行，
     其中两个线程都执行了 count+=1 ，
     但结果 2，而是 1。
     

1.3 有序性

1. 有序性

   • CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符

2. 例子

   • 编译器优化，有时候会改
     变程序中语句的先后顺序
   • 如：“a=6；b=7；”
     编译器优化后可能变成“b=7；a=6；”

3. 双重检查单例模式（DCL）

   • 线程 A、B 同时调用 getInstance() 方法,同时发现 instance ==null，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是 A），另外一个线程则会处于等待状态（假设是 B）；
   • A 会创建一个 Singleton实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。
   • https://blog.csdn.net/qq_38734403/article/details/106976266
     

     public class SingletonLazy {
         /**懒汉模式-双重检验锁-线程安全且并行效率高*/
         private static SingletonLazy instance;
         public static SingletonLazy getInstance() {
             // 先判断实例是否存在，若不存在再对类对象进行加锁处理
             if (instance == null) {                   //Single Checked
                 synchronized (SingletonLazy.class) {
                     if (instance == null) {           //Double Checked
                         instance = new SingletonLazy();
                     }
                 }
             }
             return instance;
         }
     }

4. DCL 问题：出在 new 操作上

   • 我们以为的 new 操作应该是：
     1）分配一块内存 M；
     2）在内存 M 上初始化 Singleton 对象；
     3）然后 M 的地址赋值给 instance 变量。
   • 实际优化后的执行路径是：
     1） 分配一块内存 M；
     2） 将 M 的地址赋值给 instance 变量；
     3） 最后在内存 M 上初始化 Singleton 对象。

5. DCL 问题：导致问题-空指针

   • A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；
   • 如果此时线程 B 也执行 getInstance() 方法，那么线程 B 会发现instance != null，所以直接返回 instance，
   • 而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。
     

2. JMM

1. 概念：
   
   • Java内存模型（JMM）是个很复杂的规范，规范了JVM如何提供按需禁用缓存和编译优化的方法。
   • 具体来说，这些方法包括 volatile、synchronized 和 final 三个关键字，以及六
     项Happens-Before规则。
2. Java如何解决可见性和有序性问题

2.1 JMM概述

1. JMM作用
   
   • Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的
     方法。
   • volatile、synchronized 和 final 三个关键字
   • 六项 Happens-Before 规则

2.2 volatile

1. 概述

   • volatile 关键字并不是 Java 语言的特产，古老的 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。
   • 声明一个 volatile 变量 volatile int x = 0，它表达的是：告诉编译器，对这个变量的读写，不能使用 CPU 缓存，必须从内存中读取或者写入。

2. 例子

   • 线程 A 执行 writer() 方法，按照 volatile 语义，会把变量“v=true” 写入内存；假设线程 B 执行 reader() 方法，同样按照 volatile 语义，线程 B会从内存中读取变量 v，如果线程 B 看到 “v == true” 时，那么线程 B 看到的变量 x多少呢？
   • Java1.5前：x 可能是 42或 0；
   • Java1.5后：x 等于 42。
     

     class VolatileDemo {
         int x = 0;
         volatile boolean v = false;
         public void writer() {
             x = 42;
             v = true;
         }
         public void reader() {
             if (v == true) {
         // 这里 x 会是多少呢？
             }
         }
     }

3. Java5前的问题

   • 问题：Java5前出现 x = 0
   • 原因：变量 x 可能被 CPU缓存而导致可见性问题。
   • 解决：Java 内存模型在 1.5 版本对 volatile 语义进行了增强。即Happens-
     Before 规则。（Java5已解决

2.3 Happens-Before 规则

1. 概念

   • Happens-Before并不是说前面一个操作发生在后续操作的前面，它真正要表达的是：前面一个操作的结果对后续操作是可见的。
   • 比较正式的说法是：Happens-Before 约束了编译器的优化行为，虽允许编译器优化，但是要求编译器优化后一定遵守Happens-Before 规则。

2. Happens-Before 六规则

   • 程序的顺序性规则
   • 这条规则是指在一个线程中，按照程序顺序，前面的操作Happens-Before于后续的任意操作。

   • 程序前面对某个变量的修改一定是对后续操作可见的。

     // “x = 42;” Happens-Before  “v = true;”
     x = 42;
     v = true;

   • volatile 变量规则

   • 这条规则是指对一个 volatile 变量的写操作， Happens-Before 于后续对这个volatile变量的读操作。
   • 关联规则3看
   • 传递性
   • A Happens-Before B，
     且 B Happens-Before C，
     则 A Happens-Before C。
     
   • 规则 2：
     写变量“v=true” Happens-Before 读变量 “v=true”
   • x=42” Happens-Before 读变量“v=true”
     如果线程 B 读到了“v=true”，那么线程 A 设置的“x=42”对线程 B 是可见的。也就是说，线程 B 能看到 “x == 42”
     即 1.5 版本对volatile 语义的增强
   • 管程中锁的规则
   • 这条规则是指对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。
   • 管程是一种通用的同步原语，在Java 中指的就是synchronized，synchronized 是 Java 里对管程的实现。

   • 管程中的锁在 Java 里是隐式实现的

     synchronized (this) { // 此处自动加锁
         // x 是共享变量, 初始值 =10
         if (this.x < 12) {
         this.x = 12;
         }
     } // 此处自动解锁

   • 结合规则 4——管程中锁的规则理解：假设 x 的初始值是 10，线程 A 执行完代码块后 x 的值会变成12（执行完自动释放锁），线程 B 进入代码块时，能够看到线程 A 对 x 的写操作，也就是线程 B 能够看到x==12。

   • 线程 start() 规则

   • 指主线程 A 启动子线程 B 后，子线程 B 能够看到主线程在启动子线程 B 前的操作。

      Thread B = new Thread(() -> {
         // 主线程调用 B.start() 之前
         // 所有对共享变量的修改，此处皆可见
         // 此例中，var==77
     });
     // 此处对共享变量 var 修改
     var =77;
     // 主线程启动子线程
     B.start();

   • 线程的join()规则

   • 指主线程 A 等待子线程 B 完成（主线程 A 通过调用子线程B 的 join() 方法实现），当子线程 B 完成后（主线程 A 中 join() 方法返回），主线程能够看到子线程的操作。当然所谓的“看到”，指的是对共享变量的操作。

   • 换句话说就是，如果在线程 A 中，调用线程 B 的 join() 并成功返回，那么线程 B 中的任意操作 Happens-Before 于该 join() 操作的返回。

     Thread B = new Thread(()->{
     // 此处对共享变量 var 修改
         var = 66;
     });
     // 例如此处对共享变量修改，
     // 则这个修改结果对线程 B 可见
     // 主线程启动子线程
     B.start();
     B.join();
     // 子线程所有对共享变量的修改
     // 在主线程调用 B.join() 之后皆可见
     // 此例中，var==66

   • 线程中断规则：

   • 对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
   • 对象终结规则：
   • 一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。

2.4 final

1. 概念

   • final 修饰变量时，初衷是告诉编译器：这个变量生而不变，可以可劲儿优化。

2. 逸出

   • 1.5 以后 Java 内存模型对 final 类型变量的重排进行了约束。现在只要我们提供正确构造函数没有“逸出”，就不会出问题了。
   • 如下，在构造函数里面将 this 赋值给
     了全局变量global.obj，这就是“逸出”，线程通过 global.obj 读取 x 是有可能读到 0的，一定要避免“逸出”。（有可能通过global.obj 可能访问到还没有初始化的this对象；将this赋值给global.obj时，this还没有初始化完）
     

     final int x;
     // 错误的构造函数
     public FinalFieldExample() {
         x = 3;
         y = 4;
     // 此处就是讲 this 逸出，
         global.obj = this;
     }

3. 互斥锁：解决原子性问题

3.1 原子性问题

1. 原子性概念？

   • 一个或者多个操作在 CPU 执行的过程中不被中断的特性，称为原子性。

2. 32位CPU上执行long型变量的写操作？

   • long型变量是64位，在32位CPU上执行写操作会被拆分成两次写操作（写高32位和写低32位）。
   • 单核
     CPU同一时刻只有一个线程执行，禁止CPU中断，意味着操作系统不会重新调度线程，也就是禁止了线程切换，获得CPU使用权的线程就可以不间断地执行，所以两次写操作一定是：要么都被执行，要么都没有被执行，具有原子性。
   • 多核
     同一时刻，有可能有两个线程同时在执行，一个线程执行在CPU-1上，一个线程执行在CPU-2上，此时禁止CPU中断，只能保证CPU上的线程连续执行，并不能保证同一时刻只有一个线程执行，这两个线程同时写long型变量高32位的话，就会出现非原子性问题。
   • 解决条件：
     “同一时刻只有一个线程执行”这个条件非常重要，形成互斥条件即可。

3.2 锁模型

1. 锁模型
   
   • 一段需要互斥执行的代码称为临界区
   • 基本：
     线程在进入临界区之前，首先尝试加锁lock()，如果成功，则进入临界区，此时我们称这个线程持有锁；否则呢就等待，直到持有锁的线程解锁；持有锁的线程执行完临界区的代码后，执行解锁 unlock()。
   • 改进
     首先，我们要把临界区要保护的资源标注出来，如图中临界区里增加了一个元素：受保护的资源R；其次，我们要保护资源R就得为它创建一把锁LR；最后，针对这把锁LR，我们还需在进出临界区时添上加锁操作和解锁操作。另外，在锁LR和受保护资源之间，我特地用一条线做了关联，这个关联关系非常重要。
     

3-synchronized

1. synchronized 是Java在语言层面提供的互斥原语.

2. synchronized的使用？

   • 与上述模型比较，lock()和解锁unlock()两个操作是被Java默默加上的，Java编译器会在synchronized修饰的方法或代码块前后自动加上加锁lock()和解锁unlock()
   • 代码
     

     class X {
         //1. 修饰非静态方法
         synchronized void foo() {
             // 临界区
         }
         //2. 修饰静态方法
         synchronized static void bar() {
             // 临界区
         }
         //3. 修饰代码块
         Object obj = new Object();
         void baz() {
             synchronized (obj) {
                 // 临界区
             }
         }
     }

3. 修饰方法的时候锁定的是什么呢？

   • 显式：
     修饰代码块，锁定了一个obj对象；
   • 隐式：
     -- 修饰非静态方法，锁定的是当前实例对象 this。
     -- 修饰静态方法，锁定的是当前类的Class对象，例子中为 Class X；
     

     Class X {
     //1. 修饰非静态方法
     synchronized(this) void foo() {
             // 临界区
     }
      //2. 修饰静态方法
     synchronized(X.class) static void bar() {
             // 临界区
         }
     }

4. 用 synchronized 解决 count+=1 问题?

   • 代码

     class SafeCalc {
         long value = 0L;
         long get() {
             return value;
         }
         synchronized void addOne() {
             value += 1;
         }
     }

   • 原子性：
     addOne()方法，被synchronized修饰后，无论是单核CPU还是多核CPU，只有一个线程能够执行addOne()方法，所以一定能保证原子操作。

   • 可见性-addOne()：
     -- 管程中锁的规则：对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。
     -- 即前一个线程的解锁操作对后一个线程的加锁操作可见
     -- 综合Happens-Before的传递性原则，得出前一个线程在临界区修改的共享变量（该操作在解锁之前），对后续进入临界区（该操作在加锁之后）的线程是可见的。

   • 可见性-get()：
     -- 管程中锁的规则，是只保证后续对这个锁的加锁的可见性，而get()方法并没有加锁操作，可见性没法保证。
     -- 加上syc关键字

     synchronized long get() {
         return value;
     }

   • get()方法和addOne()方法都需要访问value这个受保护的资源，这个资源用this这把锁来保护。线程要进入临界区get()和addOne()，必须先获得this这把锁，这样get()和addOne()也是互斥的。

5. 锁和受保护资源的关系?

   • 受保护资源和锁之间的关联关系是N:1的关系。

   • 加上static

     class SafeCalc {
         static long value = 0L; // +static
         long get() {
             return value;
         }
         synchronized static void addOne() { // +static
             value += 1;
         }
     }

   • 两个锁保护一个资源。这个受保护的资源就是静态变量 value，两个锁分别是 this 和 SafeCalc.class。我们可以用下面这幅图来形象描述这个关系。由于临界区 get() 和 addOne() 是用两个锁保护的，因此这两个临界区没有互斥关系，临界区 addOne() 对 value 的修改对临界区 get() 也没有可见性保证，这就导致并发问题。

6. 两种加锁对比？
   
   

一把锁保护多个资源

保护没有关联关系的多个资源

1. 问题类型？

   • 保护没有关联关系的多个资源
     如，银行业务中有针对账户余额（余额是一种资源）的取款操作，也有针对账户密码（密码也是一种资源）的更改操作，可以为账户余额和账户密码分配不同的锁来解决并发问题。
   • 一把互斥锁来保护多个资源
     如，用this这一把锁来管理账户类里所有的资源：账户余额和用户密码。
     -- 实现，示例所有的方法都增加同步关键字synchronized。
     

      class Account {
         // 锁：保护账户余额
         private final Object balLock = new Object();
         // 账户余额
         private Integer balance;
         // 锁：保护账户密码
         private final Object pwLock = new Object();
         // 账户密码
         private String password;
         // 取款
         void withdraw(Integer amt) {
             synchronized (balLock) {
                 if (this.balance > amt) {
                     this.balance -= amt;
                 }
             }
         }
         // 查看余额 
         Integer getBalance() {
             synchronized (balLock) {
                 return balance;
             }
         }
         // 更改密码 
         void updatePassword(String pw) {
             synchronized (pwLock) {
                 this.password = pw;
             }
         }
         // 查看密码 
         String getPassword() {
             synchronized (pwLock) {
                 return password;
             }
         }
     }

2. 一把互斥锁来保护多个资源的问题？

   • 问题：
     性能太差，会导致取款、查看余额、修改密码、查看密码这四个操作都是串行的。而我们用两把锁，取款和修改密码是可以并行的。
   • 解决：
     用不同的锁对受保护资源进行精细化管理，能够提升性能。这种锁还有个名字，叫细粒度锁。

保护有关联关系的多个资源

1. 如何保护有关联关系的多个资源？

   • 问题：
     例如，银行业务里面的转账操作，账户A减少100元，账户B增加100元。怎么保证转账操作transfer()没有并发问题呢？
   • 解决：
     -- 同一把锁来保护多个资源，使锁能覆盖所有受保护资源。
     -- 用 Account.class 作为共享的锁。Account.class 是所有 Account 对象共享的，而且这个对象是Java虚拟机在加载Account类的时候创建的，所以我们不用担心它的唯一性。使用Account.class 作为共享的锁，就无需在创建 Account对象时传入，代码也简化了。
     

     class Account {
         private int balance;
         // 转账 
         void transfer(Account target, int amt) {
             synchronized (Account.class) {
                 if (this.balance > amt) {
                     this.balance -= amt;
                     target.balance += amt;
                 }
             }
         }
     }

4. 死锁

1-死锁的产生与预防

1. 死锁的一个比较专业的定义是：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

2. 死锁的原因？

   • 细粒度锁
     使用细粒度锁可以提高并行度，是性能优化的一个重要手段。但使用细粒度锁可能会导致死锁
   • 现象
     客户找柜员张三做个转账业务：账户 A 转账户 B 100元，
     另一个客户找柜员李四也做个转账业务：账户 B 转账户 A 100元，
     于是张三和李四同时都去文件架上拿账本，可能出现张三拿到了账本 A，李四拿到了账本 B。张三拿到账本 A 后就等着账本 B（账本 B已经被李四拿走），而李四拿到账本 B 后就等着账本 A（账本 A 已经被张三拿走），他们要等多久呢？他们会永远等待下去…

3. 如何预防死锁？

   • 死锁的产生
     1）互斥，共享资源 X 和 Y 只能被一个线程占用；
     2）占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
     3）不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
     4）循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等
     待。
   • 破坏死锁条件
     1）对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
     2）对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
     3）对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

2-“等待-通知”机制优化循环等待

1. 循环等待问题？

   • 问题：
     破坏占用且等待条件的时，如果转出账本和转入账本不满足同时在文件架上这个条件，就用死循环的方式来循环等待，

   • 核心代码：

     // 一次性申请转出账户和转入账户，直到成功
     while(!actr.apply(this, target))
      ；

   • 如果apply()操作耗时非常短，而且并发冲突量也不大时，循环上几次或者几十次就能一次性获取转出账户和转入账户了。但如果apply()操作耗时长，或者并发冲突量大的时候，可能要循环上万次才能获取到锁太消耗CPU，循环等待方案就不适用了。

2. 循环等待问题的解决方案？

   • 方案：如果线程要求的条件（转出账本和转入账本同在文件架上）不满足，则线程阻塞自己，进入等待状态；当线程要求的条件（转出账本和转入账本同在文
     件架上）满足后，通知等待的线程重新执行。其中，使用线程阻塞的方式就能避免循环等待消耗CPU的问题。

Java语言是如何支持等待-通知机制

1. 类比于现实的等待 - 通知机制的就医流程？
   1）患者先去挂号，然后到就诊门口分诊，等待叫号；
   2）当叫到自己的号时，患者就可以找大夫就诊了；
   3）就诊过程中，大夫可能会让患者去做检查，同时叫下一位患者；
   4）当患者做完检查后，拿检测报告重新分诊，等待叫号；
   5）当大夫再次叫到自己的号时，患者再去找大夫就诊。

   • 等待-通知机制的就医流程，不仅能够保证同一时刻大夫只为一个患者服务，而且还能够保证大夫和患者的效率。
   • 上述等待-通知机制中的一些细节：
     1）患者到就诊门口分诊，类似于线程要去获取互斥锁；当患者被叫到时，类似线程已经获取到锁了。
     2）大夫让患者去做检查（缺乏检测报告不能诊断病因），类似于线程要求的条件没有满足。
     3）患者去做检查，类似于线程进入等待状态；然后大夫叫下一个患者，这个步骤我们在前面的等待-通知机制中忽视了，这个步骤对应到程序里，本质是线程释放持有的互斥锁。
     4）患者做完检查，类似于线程要求的条件已经满足；患者拿检测报告重新分诊，类似于线程需要重新获取互斥锁，这个步骤我们在前面的等待-通知机制中也忽视了。
   • 综合可以得出一个完整的等待-通知机制：线程首先获取互斥锁，当线程要求的条件不满足时，释放互斥锁，进入等待状态；当要求的条件满足时，通知等待的线程重新获取互斥锁。

2. 如何用synchronized实现等待-通知机制？

   • Java语言里，等待-通知机制可以有多种实现方式，比如 Java 语言内置的 synchronized配合wait()、notify()、notifyAll()这三个方法就能轻松实现。

3. 如何用synchronized实现互斥锁？

   • 在下面这个图里，左边有一个等待队列，同一时刻，只允许一个线程进入synchronized保护的临界区（这个临界区可以看作大夫的诊室），当有一个线程进入临界区后，其他线程就只能进入图中左边的等待队列里等待（相当于患者分诊等待）。这个等待队列和互斥锁是一对一的关系，每个互斥锁都有自己独立的等待队列。
     
   • 在并发程序中，当一个线程进入临界区后，由于某些条件不满足，需要进入等待状态，Java 对象的 wait() 方法就能够满足这种需求。如上图所示，当调用 wait() 方法后，当前线程就会被阻塞，并且进入到右边的等待队列中，这个等待队列也是互斥锁的等待队列。线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。
     
   • 那线程要求的条件满足时，如何通知这个等待的线程呢？
     就是 Java 对象的 notify()和notifyAll()方法。下图大致描述了这个过程，当条件满足时调用notify()，会通知等待队列（互斥锁的等待队列）中的线程，告诉它条件曾经满足过。
     
   • 为什么说是曾经满足过呢？
     注意：notify()只能保证在通知时间点，条件是满足的。而被通知线程的执行时间点和通知的时间点基本上不会重合，所以当线程执行的时候，很可能条件已经不满足了（保不齐有其他线程插队）。
   • 还需注意：被通知的线程要想重新执行，仍然需要获取到互斥锁（因为曾经获取的锁在调用 wait() 时已经释放了）。

4. 使用wait()、notify()、notifyAll()方法？

   • synchronized 锁定的是this，那么对应的一定是this.wait()、this.notify()、this.notifyAll()；
   • synchronized 锁定的是target，那么对应的一定是target.wait()、target.notify()、target.notifyAll() 。
   • wait()、notify()、notifyAll()这三个方法能够被调用的前提是已经获取了相应的互斥锁，所以我们会发现 wait()、notify()、notifyAll() 都是在
     synchronized{}内部被调用的。如果在 synchronized{}外部调用，或者锁定的 this，而用target.wait() 调用的话，JVM 会抛出一个运行时异常：
     java.lang.IllegalMonitorStateException。

5. 一个更好地资源分配器：如何解决一次性申请转出账户和转入账户的问题？

   • 这个等待-通知机制中，需要考虑以下四个要素。
     1）互斥锁：上一部分死锁中的Allocator需要是单例的，所以可以用this作为互斥锁。
     2）线程要求的条件：转出账户和转入账户都没有被分配过。
     3）何时等待：线程要求的条件不满足就等待。
     4）何时通知：当有线程释放账户时就通知。
   • 考虑好上述几个问题，完成下面的代码：
     

     while(条件不满足) {
         wait();
      }
      ```
     * 利用这种范式可以解决上面提到的条件曾经满足过这个问题。因为当 wait() 返回时，有可能条件已经发生变化了，曾经条件满足，但是现在已经不满足了，所以要重新检验条件是否满足。范式，意味着是经典做法，所以没有特殊理由不要尝试换个写法。
     ``` java
     class Allocator {
         private List<Object> als;
         // 一次性申请所有资源
         synchronized void apply(
                 Object from, Object to){
             // 经典写法
             while(als.contains(from) ||
                     als.contains(to)){
                 try{
                     wait();
                 }catch(Exception e){
                 }
             }
             als.add(from);
             als.add(to);
         }
         // 归还资源
         synchronized void free(
                 Object from, Object to){
             als.remove(from);
             als.remove(to);
             notifyAll();
         }
     }

6. 尽量使用 notifyAll()？

   • 上述使用notifyAll()来实现通知机制，为什么不使用notify()呢？
   • 这二者是有区别的，notify() 是会随机地通知等待队列中的一个线程，而 notifyAll() 会通知等待队列中的所有线程。从感觉上来讲，应该是 notify() 更好一些，因为即便通知所有线程，也只有一个线程能够进入临界区。实际上使用notify()也很有风险，它的风险在于可能导致某些线程永远不会被通知到。
   • 假设我们有资源 A、B、C、D，线程 1 申请到了 AB，线程 2 申请到了 CD，此时线程 3 申请AB，会进入等待队列（AB 分配给线程 1，线程 3 要求的条件不满足），线程 4 申请 CD 也会进入等待队列。我们再假设之后线程 1 归还了资源 AB，如果使用notify()来通知等待队列中的线程，有可能被通知的是线程 4，但线程 4 申请的是 CD，所以此时线程 4 还是会继续等待，而真
     正该唤醒的线程 3 就再也没有机会被唤醒了。
   • 所以除非经过深思熟虑，否则尽量使用 notifyAll()。

7. 总结

   • 等待-通知机制是一种非常普遍的线程间协作的方式。工作中经常看到有同学使用轮询的方式来等待某个状态，其实很多情况下都可以用今天我们介绍的等待-通知机制来优化。
   • Java语言内置的synchronized配合wait()、notify()、notifyAll()这三个方法可以快速实现这种机制，但是它们的使用看上去还是有点复杂，所以你需要认真理解等待队列和 wait()、notify()、notifyAll()的关系。

3-Java线程

1-生命周期

1. 通用的线程生命周期？
通用的线程生命周期基本上可以用下图这个“五态模型”来描述。这五态分别是：初始状态、可运行状态、运行状态、休眠状态和终止状态。

1. 这“五态模型”的详细情况如下所示？
   1）初始状态，指的是线程已经被创建，但是还不允许分配CPU执行。这个状态属于编程语言特有的，不过这里所谓的被创建，仅仅是在编程语言层面被创建，而在操作系统层面，真正的线程还没有创建。
   2）可运行状态，指的是线程可以分配CPU执行。在这种状态下，真正的操作系统线程已经被成功创建了，所以可以分配CPU执行。
   3）当有空闲的CPU时，操作系统会将其分配给一个处于可运行状态的线程，被分配到CPU的线程的状态就转换成了运行状态。
   4）运行状态的线程如果调用一个阻塞的API（例如以阻塞方式读文件）或者等待某个事件（例如条件变量），那么线程的状态就会转换到休眠状态，同时释放CPU使用权，休眠状态的线程永远没有机会获得CPU使用权。当等待的事件出现了，线程就会从休眠状态转换到可运行状态。
   5）线程执行完或者出现异常就会进入终止状态，终止状态的线程不会切换到其他任何状态，进入终止状态也就意味着线程的生命周期结束了。

2. 五种状态的定义？

   • 参考：
     https://my.oschina.net/payzheng/blog/692635
     评论存疑：https://blog.csdn.net/woshiyigeliangliang/article/details/81116872
   • 定义：
     -- NEW：一个被创建的线程，但是还没有调用start方法
     -- RUNNABLE：一个正在被执行的线程的状态
     -- BLOCKED：一个线程因为等待临界区的锁被阻塞产生的状态
     -- WAITING：一个线程进入了锁，但是需要等待其他线程执行某些操作。时间不确定
     -- TIMED_WAITING：一个线程进入了锁，但是需要等待其他线程执行某些操作。时间确定
     -- TERMINATED：通过sleep或wait timeout方法进入的限期等待的状态)

3. 这五种状态在不同编程语言里会有简化合并？

   • 简化合并，如：
     -- C语言的POSIX Threads规范，就把初始状态和可运行状态合并了；
     -- Java语言里则把可运行状态和运行状态合并了，这两个状态在操作系统调度层面有用，而JVM层面不关心这两个状态，因为JVM把线程调度交给操作系统处理了。
   • 细化，如，
     -- Java语言里就细化了休眠状态。

4. Java中线程的生命周期？

   • Java语言中线程共有六种状态，分别是：
     1）NEW（初始化状态）
     2）RUNNABLE（可运行 / 运行状态）
     3）BLOCKED（阻塞状态）
     4）WAITING（无时限等待）
     5）TIMED_WAITING（有时限等待）
     6）TERMINATED（终止状态）
   • 在操作系统层面，Java线程中的BLOCKED、WAITING、TIMED_WAITING是一种状态，即前面提到的休眠状态。即Java线程处于这三种状态之一，那么这个线程就永远没有CPU的使用权。
   • 所以Java线程的生命周期可以简化为下图：
     
   • 其中，BLOCKED、WAITING、TIMED_WAITING可以理解为线程导致休眠状态的三种原因。

具体是哪些情形会导致线程从RUNNABLE状态转换到这三种状态呢？而这三种状态又是何时转换回RUNNABLE的呢？以及 NEW、TERMINATED 和 RUNNABLE 状态是如何转换的？

1. RUNNABLE与BLOCKED的状态转换？

   • RUNNABLE转BLOCKED
     只有一种场景会触发这种转换，就是线程等待synchronized的隐式锁。synchronized 修饰的方法、代码块同一时刻只允许一个线程执行，其他线程只能等待，这种情况下，等待的线程就会从RUNNABLE转换到BLOCKED状态。
   • BLOCKED转RUNNABLE
     当等待的线程获得synchronized隐式锁时，就又会从BLOCKED转换到RUNNABLE状态。
   • 在操作系统线程的生命周期，线程调用阻塞式API时，是否会转换到BLOCKED状态？
     在操作系统层面，线程是会转换到休眠状态的，但是在JVM层面，Java线程的状态不会发生变化，也就是说Java线程的状态会依然保持RUNNABLE状态。JVM层面并不关心操作系统调度相关的状态，因为在JVM看来，等待CPU使用权（操作系统层面此时处于可执行状态）与等待I/O（操作系统层面此时处于休眠状态）没有区别，都是在等待某个资源，所以都归入了 RUNNABLE 状态。而我们平时所谓的Java在调用阻塞式API时，线程会阻塞，指的是操作系统线程的状态，并不是Java线程的状态。

2. RUNNABLE与WAITING的状态转换？

   • 总体，三种场景会触发这种转换：
     ① 获得synchronized隐式锁的线程，调用无参数的 Object.wait() 方法。
     ② 调用无参数的Thread.join()方法。其中的join()是一种线程同步方法，例如有一个线程对象threadA，当调用A.join()的时候，执行这条语句的线程会等待threadA执行完，而等待中的这个线程，其状态会从 RUNNABLE 转换到 WAITING。当线程 thread A 执行完，原来等待它的线程又会从 WAITING 状态转换到 RUNNABLE。
     ③ 调用 LockSupport.park() 方法。其中的 LockSupport 对象，其
     实 Java 并发包中的锁，都是基于它实现的（ReentrentLock.lock()底层调用的是LockSupport.park()，因此ReentrentLock.lock()进入的是WAITING状态。）。调用 LockSupport.park()方法，当前线程会阻塞，线程的状态会从 RUNNABLE 转换到 WAITING。调用 LockSupport.unpark(Thread thread)可唤醒目标线程，目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

3. RUNNABLE与TIMED_WAITING的状态转换？
   有五种场景会触发这种转换：
   1）调用带超时参数的 Thread.sleep(long millis) 方法；
   2）获得synchronized 隐式锁的线程，调用带超时参数的 Object.wait(long timeout) 方法；
   3）调用带超时参数的 Thread.join(long millis) 方法；
   4）调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法；
   5）调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

   • TIMED_WAITING 和 WAITING状态的区别，仅仅是触发条件多了超时参数。

4. NEW到RUNNABLE状态？

   • Java刚创建出来的Thread对象就是NEW状态。
   • NEW状态的线程，不会被操作系统调度，因此不会执行。Java线程要执行，就必须转换到RUNNABLE 状态。
   • 从NEW状态转换到RUNNABLE状态，只要调用线程对象的start()方法就可以
   • 示例代码如下：
     

     MyThread myThread = new MyThread();
     // 从 NEW 状态转换到 RUNNABLE 状态
     myThread.start()；

5. 从RUNNABLE到TERMINATED状态？

   • 线程执行完run()方法后，会自动转换到TERMINATED状态，当然如果执行run()方法的时候异常抛出，也会导致线程终止。
   • 有时候我们需要强制中断run()方法的执行，例如run()方法访问一个很慢的网络，我们等不下去了，想终止怎么办呢？
     Java 的 Thread 类里面倒是有个stop()方法，不过已经标记为@Deprecated，所以不建议使用了。正确的姿势其实是调用 interrupt()方法。

6. stop() 和 interrupt() 方法的主要区别是什么呢？

   • stop() 方法会真的杀死线程，不给线程喘息的机会，如果线程持有 synchronized 隐式锁，也不会释放，那其他线程就再也没机会获得synchronized隐式锁，这实在是太危险了。所以该方法就不建议使用了，类似的方法还有 suspend() 和 resume() 方法，这两个方法同样也都不建议使用了。
   • interrupt() 方法就温柔多了，interrupt()方法仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。

7. 被interrupt的线程，是怎么收到通知的呢？

   • 一种是异常，另一种是主动检测。
   • 主动检测一：
     当线程A处于WAITING、TIMED_WAITING状态时，如果其他线程调用线程A的interrupt()方法，会使线程A返回到RUNNABLE状态，同时线程A的代码会触发InterruptedException异常。
     上面我们提到转换到WAITING、TIMED_WAITING状态的触发条件，都是调用了类似wait()、join()、sleep()这样的方法，我们看这些方法的签名，发现都会throws InterruptedException这个异常。这个异常的触发条件就是：其他线程调用了该线程的
     interrupt() 方法。
   • 主动检测二：
     当线程 A 处于 RUNNABLE状态时，并且阻塞在java.nio.channels.InterruptibleChannel上时，如果其他线程调用线程A的interrupt()方法，线程A会触发java.nio.channels.ClosedByInterruptException这个异常；而阻塞在java.nio.channels.Selector上时，如果其他线程调用线程A的interrupt()方法，线程A的java.nio.channels.Selector 会立即返回。
   • 主动检测
     如果线程处于RUNNABLE状态，并且没有阻塞在某个I/O操作上，例如中断计算圆周率的线程 A，这时就得依赖线程 A 主动检测中断状态了。如果其他线程调用线程 A 的 interrupt() 方法，那么线程A可以通过isInterrupted()方法，检测是不是自己被中断了。

8. 总结

   • 多线程程序很难调试，出了 Bug基本上都是靠日志，靠线程dump来跟踪问题，分析线程 dump 的一个基本功就是分析线程状态，大部分的死锁、饥饿、活锁问题都需要跟踪分析线程的状态。
   • 可以通过 jstack 命令或者Java VisualVM这个可视化工具将JVM所有的线程栈信息导出来，完整的线程栈信息不仅包括线程的当前状态、调用栈，还包括了锁的信息。

9. 思考题

   • 下面代码的本意是当前线程被中断之后，退出while(true)，你觉得这段代码是否正确呢？

     Thread th = Thread.currentThread();
         while(true) {
              if(th.isInterrupted()) {
                 break;
              }
              // 省略业务代码无数
              try {
                  Thread.sleep(100);
              }catch (InterruptedException e){
                 e.printStackTrace();
          }
     }

   • 目的：注意InterruptedException 的处理方式。

   • 当你调用 Java 对象的 wait() 方法或者线程的 sleep()方法时，需要捕获并处理 InterruptedException 异常，如下所示，本意是通过 isInterrupted()检查线程是否被中断了，如果中断了就退出 while 循环。当其他线程通过调用th.interrupt().来中断 th 线程时，会设置th线程的中断标志位，从而使th.isInterrupted()返回 true，这样就能退出 while 循环了。
   • 问题：
     实际上却是几乎起不了作用。原因是这段代码在执行的时候，大部分时间都是阻塞在 sleep(100) 上，当其他线程通过调用th.interrupt().来中断 th 线程时，大概率地会触发 InterruptedException 异常，在触发 InterruptedException 异常的同时，JVM 会同时把线程的中断标志位清除，所以这个时候th.isInterrupted()返回的是 false。
   • 解决：
     正确的处理方式应该是捕获异常之后重新设置中断标志位
     

     try {
          Thread.sleep(100);
         }catch(InterruptedException e){
              // 重新设置中断标志位
              th.interrupt();
     }

2-创建合适线程数

1. 各种线程池的线程数量调整成多少是合适的？/Tomcat的线程数、Jdbc连接池的连接数是多少？等等。
2. 如何设置合适的线程数呢？
2. 分析多线程的应用场景有哪些？

1. 如何度量性能？

   • 度量性能的指标有很多，两个最核心的指标是延迟和吞吐量。
   • 延迟指的是发出请求到收到响应这个过程的时间；延迟越短，意味着程序执行得越快，性能也就越好。
   • 吞吐量指的是在单位时间内能处理请求的数量；吞吐量越大，意味着程序能处理的请求越多，性能也就越好。
   • 两个指标内部有一定的联系（同等条件下，延迟越短，吞吐量越大），但是由于它们隶属不同的维度（一个是时间维度，一个是空间维度），并不能互相转换。

2. 分析为什么要使用多线程？

   • 使用多线程，本质上就是提升程序性能。
   • 所谓提升性能，从度量的角度，主要是降低延迟，提高吞吐量。这也是使用多线程的主要目的。

3. 怎么降低延迟，提高吞吐量呢？

   • 要想“降低延迟，提高吞吐量”，基本上有两个方向，一个方向是优化算法，另一个方向是将硬件的性能发挥到极致。前者属于算法范畴，后者则是和并发编程息息相关了。
   • 那计算机主要有哪些硬件呢？主要是两类：一个是I/O，一个是CPU。
   • 简言之，在并发编程领域，提升性能本质上就是提升硬件的利用率，再具体点来说，就是提升 I/O 的利用率和 CPU 的利用率。
   • 操作系统不是已经解决了硬件的利用率问题了吗？
     -- 但是操作系统解决硬件利用率问题的对象往往是单一的硬件设备。例如操作系统已经解决了磁盘和网卡的利用率问题，利用中断机制还能避免 CPU 轮询 I/O 状态，也提升了CPU的利用率。
     -- 而并发程序，往往需要CPU和I/O设备相互配合工作，也就是说，需要解决CPU和I/O设备综合利用率的问题。关于这个综合利用率的问题，操作系统虽然没有办法完美解决，但是却给我们提供了方案，那就是：多线程。

4. 多线程的应用场景？
   示例说明：如何利用多线程来提升 CPU 和 I/O 设备的利用率？

   • 假设程序按照 CPU 计算和 I/O 操作交叉执行的方式运行，而且 CPU 计算和 I/O 操作的耗时是 1:1。
     如下，如果只有一个线程，执行 CPU 计算的时候，I/O 设备空闲；执行 I/O 操作的时候，CPU 空闲，所以 CPU 的利用率和 I/O 设备的利用率都是 50%。
     
   • 如果有两个线程，如下图所示，当线程 A 执行 CPU 计算的时候，线程 B 执行 I/O 操作；当线程A 执行 I/O 操作的时候，线程 B 执行 CPU 计算，这样 CPU 的利用率和 I/O 设备的利用率就都达到了 100%。
     
   • 将 CPU 的利用率和I/O设备的利用率都提升到了100%，会对性能产生了哪些影响呢？
     通上图：单位时间处理的请求数量翻了一番，也就是说吞吐量提高了 1 倍。
     此时可以逆向思维一下，如果CPU和I/O设备的利用率都很低，那么可以尝试通过增加线程来提高吞吐量。

5. 在单核时代，多线程主要就是用来平衡CPU和I/O设备的。如果程序只有CPU计算，而没有I/O 操作的话，多线程不但不会提升性能，还会使性能变得更差，原因是增加了线程切换的成本。但是在多核时代，这种纯计算型的程序也可以利用多线程来提升性能。为什么呢？

   • 因为利用多核可以降低响应时间。
   • 例子说明一下：计算 1+2+… … +100 亿的值，如果在 4 核的
     CPU 上利用 4 个线程执行，线程 A 计算 [1，25 亿)，线程 B 计算 [25 亿，50 亿)，线程 C 计算[50，75 亿)，线程 D 计算 [75 亿，100 亿]，之后汇总，那么理论上应该比一个线程计算 [1，100 亿] 快将近 4倍，响应时间能够降到 25%。一个线程，对于 4 核的 CPU，CPU 的利用率只
     有 25%，而 4 个线程，则能够将 CPU 的利用率提高到 100%。
     

6. I/O 密集型计算、CPU 密集型计算？

   • I/O 密集型计算：
     程序一般都是 CPU 计算和 I/O 操作交叉执行的，由于 I/O 设备的速度相对于 CPU 来说都很慢，所以大部分情况下，I/O 操作执行的时间相对于CPU计算来说都非常长，这种场景一般都称为 I/O 密集型计算；
   • CPU 密集型计算
     和 I/O 密集型计算相对的就是 CPU 密集型计算了，CPU 密集型计算大部分场景下都是纯 CPU 计算。

7. 创建多少线程合适？

   • 创建多少线程合适，要看多线程具体的应用场景。
   • I/O 密集型程序和 CPU 密集型程序，计算最佳线程数的方法是不同的。
   • CPU 密集型计算：
     -- 多线程本质上是提升多核 CPU 的利用率，所以对于一个 4 核的CPU，每个核一个线程，理论上创建4个线程就可以了，再多创建线程也只是增加线程切换的成本。所以，对于 CPU 密集型的计算场景，理论上“线程的数量=CPU核数”就是最合适的。
     -- 工程上，线程的数量一般会设置为“CPU核数+1”，这样，当线程因为偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程可以顶上，从而保证 CPU 的利用率。
   • I/O 密集型的计算场：
     -- 如前面我们的例子中，如果 CPU 计算和 I/O 操作的耗时是1:1，那么 2个线程是最合适的。如果 CPU 计算和 I/O 操作的耗时是 1:2，那多少个线程合适
     呢？是 3 个线程，如下图所示：CPU 在 A、B、C 三个线程之间切换，对于线程 A，当 CPU 从B、C 切换回来时，线程 A 正好执行完 I/O 操作。这样 CPU 和 I/O设备的利用率都达到了100%。
     
     -- 对于 I/O 密集型计算场景，最佳的线程数是与程序中 CPU 计算和 I/O 操作的耗时比相关的，我们可以总结出这样一个公式：
     【最佳线程数 =1 +（I/O 耗时 / CPU 耗时）】 -- 单核
     我们令 R=I/O 耗时 / CPU 耗时，综合上图，可以这样理解：当线程 A 执行 IO 操作时，另外 R个线程正好执行完各自的 CPU 计算。这样 CPU 的利用率就达到了 100%。
     多核 CPU，等比扩大，计算公式如下：
     【最佳线程数 =CPU 核数 * [ 1 +（I/O 耗时 / CPU 耗时）]】 -- 多核
     -- I/O 耗时和 CPU 耗时的比值是一个关键参数，这个参数是未知的，而且是动态变化的，所以工程上，要估算这个参数，然后做各种不同场景下的压测来验证估计。不过工程上，原则还是将硬件的性能发挥到极致，所以压测时，需要重点关注 CPU、I/O 设备的利用率和性能指标（响应时间、吞吐量）之间的关系。

8. 讨论题：
   有些同学对于最佳线程数的设置积累了一些经验值，认为对于 I/O密集型应用，最佳线程数应该为：2 * CPU 的核数 + 1，你觉得这个经验值合理吗？

   • 理论上，这个经验值一定是靠不住的。
   • 但是经验值对于很多“I/O 耗时 / CPU 耗时”不太容易确定的系统来说，却是一个很好到初始值。
   • 最佳线程数最终还是靠压测来确定的，实际工作中大家面临的系统，“I/O 耗时 /
     CPU 耗时”往往都大于 1，所以基本上都是在这个初始值的基础上增加。增加的过程中，应关注线程数是如何影响吞吐量和延迟的。一般来讲，随着线程数的增加，吞吐量会增加，延迟也会缓慢增加；但是当线程数增加到一定程度，吞吐量就会开始下降，延迟会迅速增加。这个时候基本上就是线程能够设置的最大值了。
   • 实际工作中，不同的 I/O 模型对最佳线程数的影响非常大，例如大名鼎鼎的 Nginx 用的是非阻塞 I/O，采用的是多进程单线程结构，Nginx 本来是一个 I/O 密集型系统，但是最佳进程数设置的却是 CPU 的核数，完全参考的是 CPU密集型的算法。

3-局部变量是线程安全

11|Java线程（下）：为什么局部变量是线程安全的？

1. Java 语言里，是不是所有变量都是共享变量呢？

   • 不是，局部变量

2. Java 方法里面的局部变量是否存在并发问题呢？
   下面我们就先结合一个例子剖析下这个问题。
   比如，下面代码里的 fibonacci() 这个方法，会根据传入的参数 n ，返回 1 到 n 的斐波那契数
   列，斐波那契数列类似这样： 1、1、2、3、5、8、13、21、34……第 1 项和第 2 项是 1，从第
   3 项开始，每一项都等于前两项之和。在这个方法里面，有个局部变量：数组 r 用来保存数列的
   结果，每次计算完一项，都会更新数组 r 对应位置中的值。你可以思考这样一个问题，当多个线
   程调用 fibonacci() 这个方法的时候，数组 r 是否存在数据竞争（Data Race）呢？

2. 并发工具类

1. 两个同步原语：管程和信号量
   
   • 两个同步原语中任何一个都可以解决所有的并发问题。

1-管程：Lock&Condition

1. lock

1. Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。

2. Java 语言本身提供的 synchronized 也是管程的一种实现，既然 Java 从语言层面已经实现了管程了，那为什么还要在SDK里提供另外一种实现呢？

   • 发展：
     例如在Java的1.5版本中，synchronized 性能不如SDK 里面的 Lock，但 1.6 版本之后，synchronized做了很多优化，将性能追了上来，所以1.6之后的版本又有人推荐使用synchronized了。
   • 为解决的问题：
     死锁问题中，破坏不可抢占条件方案，但是这个方案synchronized没有办法解决。原因是synchronized申请资源的时候，如果申请不到，线程直接进入阻塞状态了，而线程进入阻塞状态，也释放不了线程已经占有的资源。但我们希望的是：
     

     对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申
     请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。

3. 如果我们重新设计一把互斥锁去解决这个问题，那该怎么设计呢？

   • 应该有三种方案。
     1）能够响应中断。
     synchronized 的问题是，持有锁 A 后，如果尝试获取锁B失败，那么线程就进入阻塞状态，一旦发生死锁，就没有任何机会来唤醒阻塞的线程。但如果阻塞状态的线程能够响应中断信号，也就是说当我们给阻塞的线程发送中断信号的时候，能够唤醒它，那它就有机会释放曾经持有的锁 A。这样就破坏了不可抢占条件了。
     2）支持超时。
     如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
     3）非阻塞地获取锁。如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
   • 这三种方案可以全面弥补synchronized的问题。这三个方案体现在API上，就是 Lock 接口的三个方法。如下：
     

     // 支持中断的 API
     void lockInterruptibly()
      throws InterruptedException;
     // 支持超时的 API
     boolean tryLock(long time, TimeUnit unit)
      throws InterruptedException;
     // 支持非阻塞获取锁的 API
     boolean tryLock();

4. 如何保证可见性？

   • Java SDK 里面 Lock 的使用，有一个经典的范例，就是try{}finally{}
     ，需要重点关注的是在finally里面释放锁。
   • 可见性是怎么保证的？
     -- Java 里多线程的可见性是通过 Happens-Before 规则保证的，
     -- synchronized 之所以能够保证可见性，也是因为有一条 synchronized相关的规则：synchronized 的解锁 Happens-Before于后续对这个锁的加锁。
     -- Java SDK 里面 Lock 靠什么保证可见性呢？例如在下面的代码中，线程 T1 对 value 进行了 +=1 操作，那后续的线程 T2 能够看到 value的正确结果吗？
     

     class X {
          private final Lock rtl = new ReentrantLock();
          int value;
          public void addOne() {
              // 获取锁
              rtl.lock();
              try {
              value+=1;
              } finally {
              // 保证锁能释放
              rtl.unlock();
              }
          }
     }

   答案必须是肯定的。Java SDK里面锁原理简述：利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的ReentrantLock，内部持有一个 volatile 的成员变量 state，获取锁的时候，会读写 state 的值；解锁的时候，也会读写 state的值（简化后的代码如下面所示）。也就是说，在执行 value+=1
   之前，程序先读写了一次 volatile 变量 state，在执行 value+=1 之后，又读写了一次 volatile变量 state。根据相关的 Happens-Before 规则：
   1）顺序性规则：对于线程 T1，value+=1 Happens-Before 释放锁的操作 unlock()；
   2）volatile 变量规则：由于 state = 1 会先读取 state，所以线程 T1 的 unlock() 操作Happens-Before 线程 T2 的 lock() 操作；
   3）传递性规则：线程 T2 的 lock() 操作 Happens-Before 线程 T1 的 value+=1 。

   class SampleLock {
        volatile int state;
        // 加锁
        lock() {
            // 省略代码无数
            state = 1;
        }
        // 解锁
        unlock() {
            // 省略代码无数
            state = 0;
        }
   }

   所以说，后续线程 T2 能够看到 value 的正确结果

5. 什么是可重入锁？

   • ReentrantLock，这个翻译叫可重入锁。所谓可重入锁，顾名思义，指的是线程可以重复获取同一把锁。
     例如下面代码中，当线程 T1 执行到 ①处时，已经获取到了锁 rtl ，当在 ① 处调用get() 方法时，会在 ② 再次对锁 rtl执行加锁操作。
     此时，如果锁 rtl 是可重入的，那么线程T1可以再次加锁成功；如果锁 rtl 是不可重入的，那么线程 T1 此时会被阻塞。
     

     class X {
          private final Lock rtl = new ReentrantLock();
          int value;
          public int get() {
              // 获取锁
              rtl.lock(); ②
              try {
                 return value;
              } finally {
                  // 保证锁能释放
                  rtl.unlock();
              }
          }
          public void addOne() {
              // 获取锁
              rtl.lock();
              try {
                 value = 1 + get(); ①
              } finally {
                  // 保证锁能释放
                  rtl.unlock();
              }
          }
     }

6. 可重入函数？

   • 可重入函数怎么理解呢？指的是线程可以重复调用？
     显然不是，所谓可重入函数，指的是多个线程可以同时调用该函数，每个线程都能得到正确结果；同时在一个线程内支持线程切换，无论被切换多少次，结果都是正确的。多线程可以同时执行，还支持线程切换，这意味着什么呢？线程安全啊。所以，可重入函数是线程安全的。

7. 公平锁与非公平锁?

   • ReentrantLock这个类有两个构造函数，一个是无参构造函数，一个是传入 fair 参数的构造函数。fair参数代表的是锁的公平策略，如果传入 true就表示需要构造一个公平锁，反之则表示要构造一个非公平锁。

// 无参构造函数：默认非公平锁
public ReentrantLock() {
    sync = new NonfairSync();
}
// 根据公平策略参数创建锁
public ReentrantLock(boolean fair){
    sync = fair ? new FairSync() : new NonfairSync();
}

• 在入口等待队列，锁都对应着一个等待队列，如果一个线程没有获得锁，就会进入等待队列，当有线程释放锁的时候，就需要从等待队列中唤醒一个等待的线程。
  -- 如果是公平锁，唤醒的策略就是谁等待的时间长，就唤醒谁，很公平；
  -- 如果是非公平锁，则不提供这个公平保证，有可能等待时间短的线程反而先被唤醒。

  1. 用锁的最佳实践？
• 用锁虽然能解决很多并发问题，但是可能会导致死锁，也可能影
  响性能。
• 推荐的是并发大师Doug Lea《Java并发编程：设计原则与模式》一书中，推荐的三个用锁的最佳实践，分别是：
  1）永远只在更新对象的成员变量时加锁
  2）永远只在访问可变的成员变量时加锁
  3）永远不在调用其他对象的方法时加锁

• 这三条规则，前两条估计你一定会认同，最后一条你可能会觉得过于严苛。但是我还是倾向于你去遵守，因为调用其他对象的方法，实在是太不安全了，也许“其他”方法里面有线程sleep()的调用，也可能会有奇慢无比的 I/O 操作，这些都会严重影响性能。更可怕的是，“其他”类的方法可能也会加锁，然后双重加锁就可能导致死锁。
  并发问题，本来就难以诊断，所以你一定要让你的代码尽量安全，尽量简单，哪怕有一点可能会出问题，都要努力避免。

  1. 总结
     Java SDK 并发包里的 Lock 接口里面的每个方法，你可以感受到，都是经过深思熟虑的。除了支持类似 synchronized 隐式加锁的 lock() 方法外，还支持超时、非阻塞、可中断的方式获取锁，这三种方式为我们编写更加安全、健壮的并发程序提供了很大的便利。希望你以后在使用锁的时候，一定要仔细斟酌。
     除了并发大师 Doug Lea推荐的三个最佳实践外，你也可以参考一些诸如：减少锁的持有时间、减小锁的粒度等业界广为人知的规则，其实本质上它们都是相通的，不过是在该加锁的地方加锁而已。

  2. 课后思考？
     你已经知道 tryLock()支持非阻塞方式获取锁，下面这段关于转账的程序就使用到了 tryLock()，是否存在死锁问题呢？

class Account {
     private int balance;
     private final Lock lock = new ReentrantLock();
     // 转账
     void transfer(Account tar, int amt){
         while (true) {
             if(this.lock.tryLock()) {
                 try {
                     if (tar.lock.tryLock()) {
                         try {
                             this.balance -= amt;
                             tar.balance += amt;
                             } finally {
                             tar.lock.unlock();
                             }
                     }//if
                 } finally {
                    this.lock.unlock();
                 }
             }//if
         }//while
     }//transfer
}

• 本意是通过破坏不可抢占条件来避免死锁问题，但是它的实现中有一个致命的问题，那就是：while(true)没有break条件，从而导致了死循环。
  除此之外，这个实现虽然不存在死锁问题，但还是存在活锁问题的，解决活锁问题很简单，只需要随机等待一小段时间就可以了。

• 修复后的代码如下所示，我仅仅修改了两个地方，一处是转账成功之后break，另一处是在while循环体结束前增加了Thread.sleep(随机时间)。

  class Account {
      private int balance;
      private final Lock lock = new ReentrantLock();
      //  转账
      void transfer(Account tar, int amt) {
          while (true) {
              if (this.lock.tryLock()) {
                  try {
                      if (tar.lock.tryLock()) {
                          try {
                              this.balance -= amt;
                              tar.balance += amt;
                              //新增：退出循环
                              break;
                          } finally {
                              tar.lock.unlock();
                          }
                      }//if
                  } finally {
                      this.lock.unlock();
                  }
              }//if
              //新增：sleep⼀个随机时间避免活锁
              Thread.sleep(随机时间);
          }//while
      }//transfer
  }

• 这个思考题里面的while(true)问题还是比较容易看出来的，但不是所有的while(true)问题都这么显而易见的，很多都隐藏得比较深。

2 Condition

1. Java SDK 并发包里的Lock有别于synchronized隐式锁的三个特性：能够响应中断、支持超时和非阻塞地获取锁。

2. Java SDK 并发包里的 Condition

   • Condition实现了管程模型里面的条件变量。
   • 管程中提到 Java 语言内置的管程里只有一个条件变量，而 Lock&Condition实现的管程是支持多个条件变量的，这是二者的一个重要区别。
   • 很多并发场景下，支持多个条件变量能够让并发程序可读性更好，实现起来也更容易。
   • 例如，实现一个阻塞队列，就需要两个条件变量。

3. 如何利用两个条件变量快速实现阻塞队列呢？
   一个阻塞队列，需要两个条件变量，一个是队列不空（空队列不允许出队），另一个是队列不满（队列已满不允许入队）。相
   关的代码，重新列出。

   public class BlockedQueue<T>{
        final Lock lock = new ReentrantLock();
        // 条件变量：队列不满
        final Condition notFull = lock.newCondition();
        // 条件变量：队列不空
        final Condition notEmpty = lock.newCondition();
        // 入队
        void enq(T x) {
            lock.lock();
            try {
                while (队列已满){
                    // 等待队列不满
                    notFull.await();
                }
                // 省略入队操作...
                // 入队后, 通知可出队
                notEmpty.signal();
            }finally {
               lock.unlock();
            }
        }
        // 出队
        void deq(){
            lock.lock();
            try {
                while (队列已空){
                    // 等待队列不空
                    notEmpty.await();
                }
                // 省略出队操作...
                // 出队后，通知可入队
                notFull.signal();
                }finally {
                   lock.unlock();
            }
        }
   }

   • 注意：
     -- Lock 和 Condition实现的管程，线程等待和通知需要调用await()、signal()、signalAll()，语义和wait()、notify()、notifyAll()是相同的。
     -- 区别是，Lock&Condition实现的管程里只能使用前面的await()、signal()、signalAll()，而后面的wait()、notify()、notifyAll() 只有在 synchronized实现的管程里才能使用。
     -- 如果一不小心在Lock&Condition实现的管程里调用了wait()、notify()、notifyAll()，那程序可就彻底玩儿完了。

4. 同步和异步？

   • 那同步和异步的区别到底是什么呢？
     通俗点来讲就是调用方是否需要等待结果，如果需要等待结果，就是同步；如果不需要等待结果，就是异步。
   • 比如在下面的代码里，有一个计算圆周率小数点后 100万位的方法pai1M()，这个方法可能需要执行俩礼拜，如果调用pai1M()之后，线程一直等着计算结果，等俩礼拜之后结果返回，就可以执行 printf("hello world")了，这个属于同步；如果调用pai1M()之后，线程不用等待计算结果，立刻就可以执行 printf("hello world")，这个就属于异步。
     

     // 计算圆周率小说点后 100 万位
     String pai1M() {
         // 省略代码无数
     }
     pai1M()
     printf("hello world")

5. 异步实现的两种方式？

   • 同步，是 Java代码默认的处理方式。异步实现的两种方式：
     1）调用方创建一个子线程，在子线程中执行方法调用，这种调用称为异步调用；
     2）方法实现的时候，创建一个新的线程执行主要逻辑，主线程直接 return，这种方法一般称为异步方法。

6. 在项目Dubbo中，Lock和Condition是怎么用的？

   • Dubbo 源码分析
   • 编程领域的异步的场景，比如TCP协议本身就是异步的，经常用到的 RPC 调用，在 TCP 协议层面，发送完 RPC 请求后，线程是不会等待 RPC 的响应结果的。
   • RPC调用大多数都是同步的啊？内部实现了异步转同步。

   • RPC框架Dubbo内部做了异步转同步，如何实现？分析一下相关源码。
     对于下面一个简单的RPC调用，默认情况下sayHello()方法，是个同步方法，也就是说，执行service.sayHello(“dubbo”)的时候，线程会停下来等结果。

     DemoService service = 初始化部分省略
     String message =
      service.sayHello("dubbo");
     System.out.println(message);

   • 如果此时你将调用线程dump出来的话，会是下图这个样子，你会发现调用线程阻塞了，线程状态是TIMED_WAITING。本来发送请求是异步的，但是调用线程却阻塞了，说明Dubbo帮我们做了异步转同步的事情。通过调用栈，你能看到线程是阻塞在DefaultFuture.get()方法上，所以可以推断：Dubbo 异步转同步的功能应该是通过 DefaultFuture这个类实现的。
     

7. 不过为了理清前后关系，还是有必要分析一下调用DefaultFuture.get() 之前发生了什么。DubboInvoker 的108行调用了DefaultFuture.get()，这一行很关键，我稍微修改了一下列在了下面。这一行先调用了 request(inv, timeout)方法，这个方法其实就是发送 RPC 请求，之后通过调用 get() 方法等待 RPC 返回结果。

   public class DubboInvoker{
       Result doInvoke(Invocation inv){
           // 下面这行就是源码中 108 行
           // 为了便于展示，做了修改
           return currentClient
                   .request(inv, timeout)
                   .get();
       }
   }

   • DefaultFuture 这个类是很关键，我把相关的代码精简之后，列到了下面。不过在看代码之前，你还是有必要重复一下我们的需求：当 RPC 返回结果之前，阻塞调用线程，让调用线程等待；当 RPC 返回结果后，唤醒调用线程，让调用线程重新执行。不知道你有没有似曾相识的感觉，这不就是经典的等待-通知机制吗？这个时候想必你的脑海里应该能够浮现出管程的解决方案了。有了自己的方案之后，我们再来看看 Dubbo 是怎么实现的。

         // 创建锁与条件变量
         private final Lock lock
                 = new ReentrantLock();
         private final Condition done
                 = lock.newCondition();
         // 调用方通过该方法等待结果
         Object get(int timeout){
             long start = System.nanoTime();
             lock.lock();
             try {
                 while (!isDone()) {
                     done.await(timeout);
                     long cur=System.nanoTime();
                     if (isDone() ||
                             cur-start > timeout){
                         break;
                     }
                 }
             } finally {
                 lock.unlock();
             }
             if (!isDone()) {
                 throw new TimeoutException();
             }
             return returnFromResponse();
         }
         // RPC 结果是否已经返回
         boolean isDone() {
             return response != null;
         }
         // RPC 结果返回时调用该方法
         private void doReceived(Response res) {
             lock.lock();
             try {
                 response = res;
                 if (done != null) {
                     done.signal();
                 }
             } finally {
                 lock.unlock();
             }
         }

   • 调用线程通过调用 get() 方法等待 RPC返回结果，这个方法里面，你看到的都是熟悉的“面孔”：调用 lock() 获取锁，在 finally 里面调用unlock()释放锁；获取锁后，通过经典的在循环中调用 await() 方法来实现等待。当 RPC 结果返回时，会调用 doReceived() 方法，这个方法里面，调用 lock() 获取锁，在finally 里面调用 unlock() 释放锁，获取锁后通过调用 signal()来通知调用线程，结果已经返回，不用继续等待了。

   • 至此，Dubbo 里面的异步转同步的源码就分析完了，有没有觉得还挺简单的？最近这几年，工作中需要异步处理的越来越多了，其中有一个主要原因就是有些 API 本身就是异步 API。例如websocket 也是一个异步的通信协议，如果基于这个协议实现一个简单的RPC，你也会遇到异步转同步的问题。现在很多公有云的 API本身也是异步的，例如创建云主机，就是一个异步的API，调用虽然成功了，但是云主机并没有创建成功，你需要调用另外一个API去轮询云主机的状态。如果你需要在项目内部封装创建云主机的API，你也会面临异步转同步的问题，因为同步的 API 更易用。

8. 课后思考:efaultFuture 里面唤醒等待的线程，用的是 signal()，而不是 signalAll()，你来分析一下，这样做是否合理呢？

   • Dubbo最近已经把signal()改成signalAll()了，我觉得用signal()也不能说错，但的确是用signalAll()会更安全。我个人也倾向于使用signalAll()，因为我们写程序，不是做数学题，而是在搞工程，工程中会有很多
     不稳定的因素，更有很多你预料不到的情况发生，所以不要让你的代码铤而走险，尽量使用更稳妥的方案和设计。Dubbo修改后的相关代码如下所示：
     

     private void doReceived(Response res) {
             lock.lock();
             try {
                 response = res;
                 done.signalAll();
             } finally {
                 lock.unlock();
             }
         }

2-Semaphore限流器

1. Semaphore简介？

   • 概念：
     Semaphore，现在普遍翻译为“信号量”，以前也曾被翻译成“信号灯”，因为类似现实生活里的红绿灯，车辆能不能通行，要看是不是绿灯。同样，在编程世界里，线程能不能执行，也要看信号量是不是允许。
   • 发展：
     信号量是由大名鼎鼎的计算机科学家迪杰斯特拉（Dijkstra）于1965年提出，在这之后的15年，信号量一直都是并发编程领域的终结者，直到1980年管程被提出来，才有了第二选择。目前几乎所有支持并发编程的语言都支持信号量机制。
   • Semaphore的功能
     -- 互斥锁功能。
     -- Semaphore 可以允许多个线程访问一个临界区。

2. 信号量模型？

   • 简单概括为：一个计数器，一个等待队列，三个方法。
   • 信号量模型中计数器和等待队列对外是透明的，所以只能通过信号量模型提供的三个方法来访问它们，这三个方法分别是：init()、down() 和up()。
     
   • init()：设置计数器的初始值。
     down()：计数器的值减 1；如果此时计数器的值小于 0，则当前线程将被阻塞，否则当前线程可以继续执行。
     up()：计数器的值加1；如果此时计数器的值小于或者等于0，则唤醒等待队列中的一个线程，并将其从等待队列中移除。

3. 信号量模型的代码化？

   • init()、down() 和 up()三个方法都是原子性的，并且这个原子性是由信号量模型的实现方保证的。
   • Java SDK里面，信号量模型是由java.util.concurrent.Semaphore实现的，Semaphore这个类能够保证这三个方法都是原子操作。
   • 如下，代码化的信号量模型。

class Semaphore{
    // 计数器
    int count;
    // 等待队列
    Queue queue;
    // 初始化操作
    Semaphore(int c){
        this.count=c;
    }
    //
    void down(){
        this.count--;
        if(this.count<0){
            // 将当前线程插入等待队列
            // 阻塞当前线程
        }
    }
    void up(){
        this.count++;
        if(this.count<=0) {
            // 移除等待队列中的某个线程 T
            // 唤醒线程 T
        }
    }
}

1. PV原语？

   • 信号量模型里面，down()、up()这两个操作历史上最早称为 P 操作和 V操作，所以信号量模型也被称为PV原语。
   • 另外，还有些人喜欢用 semWait() 和 semSignal() 来称呼它们，虽然叫法不同，但是语义都是相同的。在 Java SDK 并发包里，down() 和 up()对应的则是acquire() 和 release()。

2. 如何使用信号量？

   • 互斥锁
   • 限流器

3. 累加器中的互斥？

   • 红绿灯控制交通的一个关键规则：车辆在通过路口前必须先检查是否是绿灯，只有绿灯才能通行。
   • 累加器的例子--说明信号量的使用。
   • 信号量实现了一个最简单的互斥锁功能。
   • 在累加器的例子里面，count+=1操作是个临界区，只允许一个线程执行，也就是说要保证互斥。那这种情况用信号量怎么控制呢？
   • 其实很简单，就像用互斥锁一样，只需要在进入临界区之前执行一下down()操作，退出临界区之前执行一下 up() 操作就可以了。

   • 如下，acquire() 就是信号量里的down()操作，release() 就是信号量里的 up() 操作。

         static int count;
         // 初始化信号量
         static final Semaphore s = new Semaphore(1);
         // 用信号量保证互斥
         static void addOne() {
             s.acquire();
             try {
                 count+=1;
             } finally {
                 s.release();
             }
         }

   • 信号量的计数器，设置成了1，这个1表示只允许一个线程进入临界区。

4. 分析信号量是如何保证互斥的？

   • 假设两个线程T1、T2同时访问addOne()方法，当它们同时调用acquire()的时候，由于acquire()是一个原子操作，所以只能有一个线程（假设T1）把信号量里的计数器减为0，另外一个线程（T2）则是将计数器减为 -1。
   • 对于线程 T1，信号量里面的计数器的值是0，大于等于 0，所以线程 T1 会继续执行；对于线程T2，信
     号量里面的计数器的值是-1，小于0，按照信号量模型里对 down()操作的描述，线程T2将被阻塞。所以此时只有线程 T1会进入临界区执行count+=1；。
   • 当线程 T1 执行 release() 操作，也就是 up() 操作的时候，信号量里计数器的值是 -1，加 1 之后
     的值是 0，小于等于 0，按照信号量模型里对 up() 操作的描述，此时等待队列中的T2将会被唤醒。于是T2在T1执行完临界区代码之后才获得了进入临界区执行的机会，从而保证了互斥性。

5. 既然Java SDK提供了Lock，为啥还要提供一个Semaphore？

   • 信号量实现互斥锁功能，仅仅是Semaphore的部分功能；
   • Semaphore 还有一个功能是 Lock不容易实现的，那就是：Semaphore 可以允许多个线程访问一个临界区。

6. 限流器的应用？

   • 比较常见的需求就是我们工作中遇到的各种池化资源，例如连接池、对象池、线程池等等。
   • 其中，你可能最熟悉数据库连接池，在同一时刻，一定是允许多个线程同时使用连接池的，当然，每个连接在被释放前，是不允许其他线程使用的。

7. 快速实现一个限流器？

   • 对象池需求：
     -- 对象池，指的是一次性创建出N个对象，之后所有的线程重复利用这N个对象，当然对象在被释放前，也是不允许其他线程使用的。
     -- 对象池，可以用List保存实例对象，很简单。
     -- 关键是限流器的设计，这里的限流，指的是不允许多于 N 个线程同时进入临界区。
   • 如何快速实现一个这样的限流器呢？
   • 计数器的值设置成对象池里对象的个数N，就能完美解决对象池的限流问题了。

   • 对象池的示例代码：

     class ObjPool<T, R> {
         final List<T> pool;
         // 用信号量实现限流器
         final Semaphore sem;
         // 构造函数
         ObjPool(int size, T t){
             pool = new Vector<T>(){};
             for(int i=0; i<size; i++){
                 pool.add(t);
             }
             sem = new Semaphore(size);
         }
         // 利用对象池的对象，调用 func
         R exec(Function<T,R> func) {
             T t = null;
             sem.acquire();
             try {
                 t = pool.remove(0);
                 return func.apply(t);
             } finally {
                 pool.add(t);
                 sem.release();
             }
         }
     }
     // 创建对象池
     ObjPool<Long, String> pool = new ObjPool<Long, String>(10, 2);
     // 通过对象池获取 t，之后执行
     pool.exec(t -> {
             System.out.println(t);
             return t.toString();
             });

   • 用一个 List来保存对象实例，用 Semaphore 实现限流器。关键的代码是 ObjPool 里面的
     exec() 方法，这个方法里面实现了限流的功能。在这个方法里面，首先调用 acquire() 方法（与之匹配的是在 finally 里面调用 release() 方法），假设对象池的大小是10，信号量的计数器初始化为 10，那么前 10 个线程调用 acquire() 方法，都能继续执行，相当于通过了信号灯，而其他线程则会阻塞在 acquire()方法上。对于通过信号灯的线程，我们为每个线程分配了一个对象 t（这个分配工作是通过 pool.remove(0)实现的），分配完之后会执行一个回调函数func，而函数的参数正是前面分配的对象 t ；执行完回调函数之后，它们就会释放对象（这个释
     放工作是通过 pool.add(t)实现的），同时调用release()方法来更新信号量的计数器。如果此时信号量里计数器的值小于等于 0，那么说明有线程在等待，此时会自动唤醒等待的线程。

8. 思考题：在上面对象池的例子中，对象保存在了Vector中，Vector是Java提供的线程安全的容器，如果我们把Vector换成ArrayList，是否可以呢？

   • Semaphore可以允许多个线程访问一个临界区，那就意味着可能存在多个线程同时访问ArrayList，而ArrayList不是线程安全的，所以对象池的例子中是不能够将Vector换成ArrayList的。
   • Semaphore允许多个线程访问一个临界区，这也是一把双刃剑，当多个线程进入临界区时，如果需要访问共享变量就会存在并发问题，所以必须加锁，也就是说Semaphore需要锁中锁。

3-ReadWriteLock读写锁

1. 总结

   • 读写锁允许多个线程同时读共享变量，适用于读多写少的场景

2. Java SDK并发包里为什么还有很多其他的工具类呢？

   • 现象：
     管程和信号量这两个同步原语理论上用任何一个都可以解决所有的并发问题。
   • 其他工具类存在的原因：
     分场景优化性能，提升易用性。

3. 并发场景：读多写少场景 的分析？

   • 典型的读多写少应用场景：为了优化性能，会使用缓存，例如缓存元数据、缓存基础数据等。
   • 缓存提升性能，一个重要的条件就是缓存的数据一定是读多写少的，例如元数据和基础数据基本上不会发生变化（写少），但是使用它们的地方却很多（读多）。
   • 针对读多写少这种并发场景，Java SDK并发包提供了读写锁——ReadWriteLock，易使用，且性能很好。

4. 那什么是读写锁呢？

   • 读写锁，非Java语言特有的，而是一个广为使用的通用技术，所有的读写锁都遵守以下三条基本原则：
     1）允许多个线程同时读共享变量；
     2）只允许一个线程写共享变量；
     3）如果一个写线程正在执行写操作，此时禁止读线程读共享变量。
   • 读写锁类似于ReentrantLock，也支持公平模式和非公平模式。
   • 读锁和写锁都实现了java.util.concurrent.locks.Lock 接口，所以除了支持lock()方法外，tryLock()、lockInterruptibly() 等方法也都是支持的。
   • ReadWriteLock是一个接口，它的实现类是ReentrantReadWriteLock，通过名字判断出来，它是支持可重入的。
   • 但是有一点需要注意，那就是只有写锁支持条件变量，读锁是不支持条件变量的，读锁调用newCondition()会抛出UnsupportedOperationException异常。

5. 读写锁与互斥锁的重要区别？

   • 一个重要区别：读写锁允许多个线程同时读共享变量，而互斥锁是不允许的，这是读写锁在读多写少场景下性能优于互斥锁的关键。但读写锁的写操作是互斥的，当一个线程在写共享变量的时候，是不允许其他线程执行写操作和读操作。

6. 如何快速实现一个缓存？
   用 ReadWriteLock快速实现一个通用的缓存工具类:

   • 代码中，声明了一个Cache类，其中类型参数 K 代表缓存里 key 的类型，V代表缓存里 value的类型。
   • 缓存的数据保存在 Cache 类内部的 HashMap 里面，HashMap不是线程安全的，这里使用读写锁 ReadWriteLock 来保证其线程安全。
   • ReadWriteLock 是一个接口，它的实现类是 ReentrantReadWriteLock，通过名字判断出来，它是支持可重入的。
   • 通过 rwl创建了一把读锁和一把写锁。
   • Cache 这个工具类，我们提供了两个方法，一个是读缓存方法 get()，另一个是写缓存方法put()。读缓存需要用到读锁，读锁的使用和前面我们介绍的Lock 的使用是相同的，都是try{}finally{}这个编程范式。写缓存则需要用到写锁，写锁的使用和读锁是类似的。
     

     class Cache<K,V> {
         final Map<K, V> m = new HashMap<>();
         final ReadWriteLock rwl = new ReentrantReadWriteLock();
         // 读锁
         final Lock r = rwl.readLock();
         // 写锁
         final Lock w = rwl.writeLock();
         // 读缓存
         V get(K key) {
             r.lock();
             try { return m.get(key); }
             finally { r.unlock(); }
         }
         // 写缓存
         V put(String key, Data v) {
             w.lock();
             try { return m.put(key, v); }
             finally { w.unlock(); }
         }
     }

7. 处理缓存数据的初始化问题？

   • 缓存首先要解决缓存数据的初始化问题。
   • 缓存数据的初始化，可以采用一次性加载的方式，也可以使用按需加载的方式。
   • 小数据量：
     如果源头数据的数据量不大，就可以采用一次性加载的方式，这种方式最简单（可参考下图），只需在应用启动的时候把源头数据查询出来，依次调用类似上面示例代码中的 put() 方法就可以了。
     
   • 大数据量：
     -- 源头数据量非常大，就需要按需加载了；
     -- 按需加载也叫懒加载，指的是只有当应用查询缓存，并且数据不在缓存里的时候，才触发加载源头相关数据进缓存的操作。
     -- 下面你可以结合文中示意图看看如何利用ReadWriteLock 来实现缓存的按需加载。
     

8. 实现缓存的按需加载？

   • 假设缓存的源头是数据库。
   • 注意：
     -- 如果缓存中没有缓存目标对象，那么就需要从数据库中加载，然后写入缓存，写缓存需要用到写锁，所以在代码中的⑤处，调用了 w.lock()来获取写锁。
     -- 在获取写锁之后，并没有直接去查询数据库，而是在代码⑥⑦处，重新验证了一次缓存中是否存在，再次验证如果还是不存在，我们才去查询数据库并更新本地缓存。
     

     //按需加载的功能
     class Cache<K,V> {
         final Map<K, V> m = new HashMap<>();
         final ReadWriteLock rwl = new ReentrantReadWriteLock();
         final Lock r = rwl.readLock();
         final Lock w = rwl.writeLock();
         V get(K key) {
             V v = null;
             // 读缓存
             r.lock(); //①
             try {
                 v = m.get(key); //②
             } finally{
                 r.unlock(); //③
             }
             // 缓存中存在，返回
             if(v != null) { //④
                 return v;
             }
             // 缓存中不存在，查询数据库
             w.lock(); //⑤
             try {
                 // 再次验证
                 // 其他线程可能已经查询过数据库
                 v = m.get(key); //⑥
                 if(v == null){ //⑦
                     // 查询数据库
                     v= 省略代码⽆数
                     m.put(key, v);
                 }
             } finally{
                 w.unlock();
             }
             return v;
         }
     }

9. 为什么我们要再次验证呢？

   • 高并发的场景下，有可能会有多线程竞争写锁。假设缓存是空的，没有缓存任何东西，如果此时有三个线程 T1、T2 和 T3 同时调用 get()方法，并且参数 key 也是相同的。那么它们会同时执行到代码⑤处，但此时只有一个线程能够获得写锁，假设是线程 T1，线程 T1 获取写锁之后查询数据库并更新缓存，最终释放写锁。此时线程T2和T3会再有一个线程能够获取写锁，假设是T2，如果不采用再次验证的方式，此时 T2 会再次查询数据库。T2 释放写锁之后，T3 也会再次查询一次数据库。而实际上线程 T1 已经把缓存的值设置好了，T2、T3完全没有必要再次查询数据库。
   • 所以，再次验证的方式，能够避免高并发场景下重复查询数据的问题。

10. 上述缓存方案的问题？

    • 问题：
      用ReadWriteLock实现了一个简单的缓存，这个缓存虽然解决了缓存的初始化问题，但是没有解决缓存数据与源头数据的同步问题，这里的数据同步指的是保证缓存数据和源头数据的一致性。
    • 解决：
      -- 解决数据同步问题的一个最简单的方案就是超时机制。
      -- 超时机制：指的是加载进缓存的数据不是长久有效的，而是有时效的，当缓存的数据超过时效，也就是超时之后，这条数据在缓存中就失效了。
      -- 访问缓存中失效的数据，会触发缓存重新从源头把数据加载进缓存。当然也可以在源头数据发生变化时，快速反馈给缓存，具体采用哪种方案，还是要看应用的场景。
      例如MySQL 作为数据源头，可以通过近实时地解析 binlog 来识别数据是否发生了变化，如果发生了
      变化就将最新的数据推送给缓存。另外，还有一些方案采取的是数据库和缓存的双写方案。

11. 读写锁的升级与降级?
    上面按需加载的示例代码中，在①处获取读锁，在③处释放读锁，那是否可以在②处的下面增加验证缓存并更新缓存的逻辑呢？

    // 读缓存
    r.lock(); ①
    try {
         v = m.get(key); ②
         if (v == null) {
             w.lock();
             try {
                 // 再次验证并更新缓存
                 // 省略详细代码
             } finally{
                 w.unlock();
             }
         }
    } finally{
        r.unlock(); ③
    }

    • 这样看上去好像是没有问题的，先是获取读锁，然后再升级为写锁，对此还有个专业的名字，叫锁的升级。
    • ReadWriteLock并不支持这种升级。在上面的代码示例中，读锁还没有释放，此时获取写锁，会导致写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。
    • 锁的升级是不允许的，但是锁的降级却是允许的。

12. 锁降级？

    • 以下代码来源自ReentrantReadWriteLock 的官方示例，略做了改动。
    • 在代码①处，获取读锁的时候线程还是持有写锁的，这种锁的降级是支持的。
      

      class CachedData {
          Object data;
          volatile boolean cacheValid;
          final ReadWriteLock rwl = new ReentrantReadWriteLock();
          // 读锁
          final Lock r = rwl.readLock();
          // 写锁
          final Lock w = rwl.writeLock();
          void processCachedData() {
              // 获取读锁
              r.lock();
              if (!cacheValid) {
                  // 释放读锁，因为不允许读锁的升级
                  r.unlock();
                  // 获取写锁
                  w.lock();
                  try {
                      // 再次检查状态
                      if (!cacheValid) {
                          data = ...
                          cacheValid = true;
                      }
                      // 释放写锁前，降级为读锁
                      // 降级是可以的
                      r.lock();  // ①
                  } finally {
                      // 释放写锁
                      w.unlock();
                  }
              }
              // 此处仍然持有读锁
              try {use(data);}
              finally {r.unlock();}
          }
      }

13. 课后思考
    有同学反映线上系统停止响应了，CPU 利用率很低，你怀疑有同学一不小心写出了读锁升级写锁的方案，那你该如何验证自己的怀疑呢？

    • 本质上都是定位线上并发问题，方案很简单，就是通过查看线程栈来定位问题。
    • 重点是查看线程状态，分析线程进入该状态的原因是否合理。
    • 为了便于分析定位线程问题，你需要给线程赋予一个有意义的名字，对于线程池可以通过自定义ThreadFactory来给线程池中的线程赋予有意义的名字，也可以在执行run()方法时通过Thread.currentThread().setName();来给线程赋予一个更贴近业务的名字。

4-StampedLock

1. 总结

   • Java1.8提供了一种叫StampedLock的锁，它的性能就比读写锁还要好。

2. StampedLock 和ReadWriteLock 有哪些区别？

   • ReadWriteLock支持两种模式：一种是读锁，
   • StampedLock支持三种模式，分别是：写锁、悲观读锁和乐观读。
     -- 同：写锁、悲观读锁的语义和 ReadWriteLock 的写锁、读锁的
     语义非常类似，允许多个线程同时获取悲观读锁，但是只允许一个线程获取写锁，写锁和悲观读锁是互斥的。
     -- 异：StampedLock 里的写锁和悲观读锁加锁成功之后，都会返回一个
     stamp；然后解锁的时候，需要传入这个 stamp。
   • 相关的示例代码如下。
     

         final StampedLock sl =new StampedLock();
         // 获取 / 释放悲观读锁⽰意代码
         long stamp = sl.readLock();
         try {
                 // 省略业务相关代码
             } finally {
                 sl.unlockRead(stamp);
             }
         // 获取 / 释放写锁⽰意代码
         long stamp = sl.writeLock();
         try {
             // 省略业务相关代码
         } finally {
             sl.unlockWrite(stamp);
         }

3. StampedLock 的性能优于ReadWriteLock的原因？

   • 关键是 StampedLock 支持乐观读的方式。
   • ReadWriteLock 支持多个线程同时读，但是当多个线程同时读的时候，所有的写操作会被阻塞；而StampedLock提供的乐观读，多个线程同时读的时候，是允许一个线程获取写锁的，也就是说不是所有的写操作都被阻塞。
   • 注意：“乐观读”不是“乐观读锁”，乐观读这个操作是无锁的，所以相比较ReadWriteLock 的读锁，乐观读的性能更好一些。

4. 乐观读悲观读的使用示例？

   • 代码出自Java SDK官方示例，略做了修改。

   • distanceFromOrigin()方法中，首先通过调用tryOptimisticRead()获取了一个 stamp，这里的tryOptimisticRead()就是乐观读。之后将共享变量x和y读入方法的局部变量中，不过需要注意的是，由于tryOptimisticRead()是无锁的，所以共享变量x和y读入方法局部变量时，x和y有可能被其他线程修改了。因此最后读完之后，还需要再次验证一下是否存在写操作，验证操作通过调用validate(stamp)来实现的。

     class Point {
         private int x, y;
         final StampedLock sl = new StampedLock();
         // 计算到原点的距离
         int distanceFromOrigin() {
             // 乐观读
             long stamp = sl.tryOptimisticRead();
             // 读⼊局部变量，读的过程数据可能被修改
             int curX = x, curY = y;
             // 判断执⾏读操作期间，是否存在写操作，如果存在，则sl.validate返回false
             if (!sl.validate(stamp)){
                 // 升级为悲观读锁
                 stamp = sl.readLock();
                 try {
                     curX = x;
                     curY = y;
                 } finally {
                     // 释放悲观读锁
                     sl.unlockRead(stamp);
                 }
             }
             return Math.sqrt(curX * curX + curY * curY);
         }
     }

   • 代码中，如果执行乐观读操作的期间，存在写操作，会把乐观读升级为悲观读锁。

   • 合理操作，否则你就需要在一个循环里反复执行乐观读，直到执行乐观读操作的期
     间没有写操作（只有这样才能保证x和y的正确性和一致性），而循环读会浪费大量的CPU。升级为悲观读锁，代码简练且不易出错，建议你在具体实践时也采用这样的方法。

5. 进一步理解乐观读--介绍一下数据库里的乐观锁？

   • 数据库乐观锁的场景例子：
     在 ERP 的生产模块里，会有多个人通过ERP系统提供的UI同时修改同一条生产订单，那如何保证生产订单数据是并发安全的呢？我采用的方案就是乐观锁。
   • 实现：
     在生产订单的表product_doc 里增加了一个数值型版本号字段 version，每次更新product_doc这个表的时候，都将version字段加1。生产订单的UI在展示的时候，需要查询数据库，此时将这个version字段和其他业务字段一起返回给生产订单UI。
   • 例子
     -- 假设用户查询的生产订单的id=777，那么 SQL 语句类似下面这样：
     

     select id，... ，version
     from product_doc
     where id=777

   -- 用户在生产订单UI执行保存操作的时候，后台利用下面的SQL语句更新生产订单，此处我们假设该条生产订单的version=9。

   update product_doc
   set version=version+1，...
   where id=777 and version=9

   -- 如果这条 SQL 语句执行成功并且返回的条数等于1，那么说明从生产订单 UI 执行查询操作到执行保存操作期间，没有其他人修改过这条数据。因为如果这期间其他人修改过这条数据，那么版本号字段一定会大于 9。

6. 进一步理解乐观读--StampedLock的乐观读？

   • StampedLock的乐观读和数据库的乐观锁有异曲同工之妙。
   • 数据库里的乐观锁，查询的时候需要把version字段查出来，更新的时候要利用version字段做验证。这个 version 字段就类似于 StampedLock 里面的 stamp。

7. StampedLock 使用注意事项？

   • 对于读多写少的场景StampedLock性能很好，简单的应用场景基本上可以替代 ReadWriteLock；
   • 但是StampedLock的功能仅仅是ReadWriteLock的子集，在使用的时候，需要注意几个问题：
     ① StampedLock 命名上没有增加Reentrant，事实上，StampedLock不支持重入。
     ② StampedLock的悲观读锁、写锁都不支持条件变量；
     ③ 如果线程阻塞在 StampedLock的readLock()或者writeLock()上时，此时调用该阻塞线程的interrupt()方法，会导致CPU飙升。
     -- 所以，使用 StampedLock一定不要调用中断操作，如果需要支持中断功能，一定使用可中断的悲观读锁readLockInterruptibly()和写锁writeLockInterruptibly()。
     -- 如下，线程T1获取写锁之后将自己阻塞，线程T2尝试获取悲观读锁，也会阻塞；如果此时调用线程T2的interrupt() 方法来中断线程 T2 的话，线程 T2 所在 CPU会飙升到100%。
     

         final StampedLock lock = new StampedLock();
         Thread T1 = new Thread(() -> {
             // 获取写锁
             lock.writeLock();
             // 永远阻塞在此处，不释放写锁
             LockSupport.park();
         });
         T1.start();
         // 保证 T1 获取写锁
         Thread.sleep(100);
         Thread T2 = new Thread(() ->
                 // 阻塞在悲观读锁
                 lock.readLock()
         );
         T2.start();
         // 保证 T2 阻塞在读锁
         Thread.sleep(100);
         // 中断线程 T2
         // 会导致线程 T2 所在 CPU 飙升
         T2.interrupt();
         T2.join();

8. 工程使用？

   • 把 Java 官方示例精简后，形成下面的代码模板，建议你在实际工作中尽量按照这个模板来使用StampedLock。

   • StampedLock读模板：

     final StampedLock sl = new StampedLock();
     // 乐观读
     long stamp = sl.tryOptimisticRead();
     // 读⼊⽅法局部变量
     ......
     // 校验 stamp
     if (!sl.validate(stamp)){
          // 升级为悲观读锁
          stamp = sl.readLock();
          try {
              // 读⼊⽅法局部变量
             .....
          } finally {
              // 释放悲观读锁
              sl.unlockRead(stamp);
          }
     }
     // 使⽤⽅法局部变量执⾏业务操作
     ......

   • StampedLock 写模板：

     long stamp = sl.writeLock();
     try {
          // 写共享变量
          ......
     } finally {
          sl.unlockWrite(stamp);
     }

9. 锁升级降级？

   • StampedLock 支持锁的降级（通过 tryConvertToReadLock() 方法实现）和升级（通过tryConvertToWriteLock()方法实现），但是建议你要慎重使用。下面的代码也源自Java的官方示例，仅仅做了一点修改，但隐藏了一个 Bug。

     private double x, y;
     final StampedLock sl = new StampedLock();
     // 存在问题的⽅法
     void moveIfAtOrigin(double newX, double newY){
          long stamp = sl.readLock();
          try {
              while(x == 0.0 && y == 0.0){
                  long ws = sl.tryConvertToWriteLock(stamp);
                  if (ws != 0L) {
                      x = newX;
                      y = newY;
                      break;
                  } else {
                      sl.unlockRead(stamp);
                      stamp = sl.writeLock();
                  }
              }
          } finally {
             sl.unlock(stamp);
         }
     }

   • Bug出在没有正确地释放锁。

   • 锁的申请和释放要成对出现，对此我们有一个最佳实践，就是使用try{}finally{}，但是try{}finally{}并不能解决所有锁的释放问题。比如示例代码中，锁的升级会生成新的stamp，而finally中释放锁用的是锁升级前的stamp，本质上这也属于锁的申请和释放没有成对出现，只是它隐藏得有点深。解决这个问题倒也很简单，只需要对stamp重新赋值就可以了，修复后的代码如下所示：
     

     private double x, y;
     final StampedLock sl = new StampedLock();
     // 存在问题的⽅法
     void moveIfAtOrigin(double newX, double newY){
          long stamp = sl.readLock();
          try {
              while(x == 0.0 && y == 0.0){
                  long ws = sl.tryConvertToWriteLock(stamp);
                  if (ws != 0L) {
                     stamp = ws; //① 问题在于没对stamp重新赋值，增加赋值
                      x = newX;
                      y = newY;
                      break;
                  } else {
                      sl.unlockRead(stamp);
                      stamp = sl.writeLock();
                  }
              }
          } finally {
             sl.unlock(stamp);
             s1.unlock(stamp);//②此处unlock的是stamp
         }
     }