大家好，我是易安！

如果有人问我学习并发并发编程，最外围的技术点是什么，我肯定会通知他，管程技术。Java语言在1.5之前，提供的惟一的并发原语就是管程，而且1.5之后提供的SDK并发包，也是以管程技术为根底的。除此之外，C/C++、C#等高级语言也都反对管程。

能够这么说，管程就是解决并发问题的基石。

什么是管程

不晓得你是否曾思考过这个问题：为什么Java在1.5之前仅仅提供了synchronized关键字及wait()、notify()、notifyAll()这三个看似从天而降的办法？在刚接触Java的时候，我认为它会提供信号量这种编程原语，因为操作系统原理课程通知我，用信号量能解决所有并发问题，后果我发现不是。起初我找到了起因：Java采纳的是管程技术，synchronized关键字及wait()、notify()、notifyAll()这三个办法都是管程的组成部分。而 管程和信号量是等价的，所谓等价指的是用管程可能实现信号量，也能用信号量实现管程。 然而管程更容易应用，所以Java抉择了管程。

管程，对应的英文是Monitor，很多Java畛域的同学都喜爱将其翻译成“监视器”，这是直译。操作系统畛域个别都翻译成“管程”，这个是意译，而我本人也更偏向于应用“管程”。

所谓 管程，指的是治理共享变量以及对共享变量的操作过程，让他们反对并发。翻译为Java畛域的语言，就是治理类的成员变量和成员办法，让这个类是线程平安的。那管程是怎么管的呢？

MESA模型

在管程的发展史上，先后呈现过三种不同的管程模型，别离是：Hasen模型、Hoare模型和MESA模型。其中，当初广泛应用的是MESA模型，并且Java管程的实现参考的也是MESA模型。所以明天咱们重点介绍一下MESA模型。

在并发编程畛域，有两大外围问题：一个是 互斥，即同一时刻只容许一个线程访问共享资源；另一个是 同步，即线程之间如何通信、合作。这两大问题，管程都是可能解决的。

咱们先来看看管程是如何解决 互斥 问题的。

管程解决互斥问题的思路很简略，就是将共享变量及其对共享变量的操作对立封装起来。如果咱们要实现一个线程平安的阻塞队列，一个最直观的想法就是：将线程不平安的队列封装起来，对外提供线程平安的操作方法，例如入队操作和出队操作。

利用管程，能够疾速实现这个直观的想法。在下图中，管程X将共享变量queue这个线程不平安的队列和相干的操作入队操作enq()、出队操作deq()都封装起来了；线程A和线程B如果想访问共享变量queue，只能通过调用管程提供的enq()、deq()办法来实现；enq()、deq()保障互斥性，只容许一个线程进入管程。

不知你有没有发现，管程模型和面向对象高度符合的。预计这也是Java抉择管程的起因吧。

那管程如何解决线程间的 同步 问题呢？

这个就比较复杂了，不过你能够借鉴一下咱们已经提到过的就医流程，它能够帮忙你疾速地了解这个问题。为进一步便于你了解，在上面，我展现了一幅MESA管程模型示意图，它详细描述了MESA模型的次要组成部分。

在管程模型里，共享变量和对共享变量的操作是被封装起来的，图中最外层的框就代表封装的意思。框的下面只有一个入口，并且在入口旁边还有一个入口期待队列。当多个线程同时试图进入管程外部时，只容许一个线程进入，其余线程则在入口期待队列中期待。这个过程相似就医流程的分诊，只容许一个患者就诊，其余患者都在门口期待。

管程里还引入了条件变量的概念，而且 每个条件变量都对应有一个期待队列， 如下图，条件变量A和条件变量B别离都有本人的期待队列。

那 条件变量 和 条件变量期待队列 的作用是什么呢？其实就是解决线程同步问题。你能够联合下面提到的阻塞队列的例子加深一下了解（阻塞队列的例子，是用管程来实现线程平安的阻塞队列，这个阻塞队列和管程外部的期待队列没有关系，本文中 肯定要留神阻塞队列和期待队列是不同的）。

假如有个线程T1执行阻塞队列的出队操作，执行出队操作，须要留神有个前提条件，就是阻塞队列不能是空的（空队列只能出Null值，是不容许的）， 阻塞队列不空 这个前提条件对应的就是管程里的条件变量。 如果线程T1进入管程后恰好发现阻塞队列是空的，那怎么办呢？期待啊，去哪里等呢？就去条件变量对应的 期待队列 外面等。此时线程T1就去“队列不空”这个条件变量的期待队列中期待。这个过程相似于大夫发现你要去验个血，于是给你开了个验血的单子，你呢就去验血的队伍里排队。线程T1进入条件变量的期待队列后，是容许其余线程进入管程的。这和你去验血的时候，医生能够给其余患者诊治，情理都是一样的。

再假如之后另外一个线程T2执行阻塞队列的入队操作，入队操作执行胜利之后， “阻塞队列不空”这个条件对于线程T1来说曾经满足了，此时线程T2要告诉T1，通知它须要的条件曾经满足了。当线程T1失去告诉后，会从期待队列 外面进去，然而进去之后不是马上执行，而是从新进入到 入口期待队列 外面。这个过程相似你验血完，回来找大夫，须要从新分诊。

条件变量及其期待队列咱们讲清楚了，上面再说说wait()、notify()、notifyAll()这三个操作。后面提到线程T1发现“阻塞队列不空”这个条件不满足，须要进到对应的 期待队列 里期待。这个过程就是通过调用wait()来实现的。如果咱们用对象A代表“阻塞队列不空”这个条件，那么线程T1须要调用A.wait()。同理当“阻塞队列不空”这个条件满足时，线程T2须要调用A.notify()来告诉A期待队列中的一个线程，此时这个期待队列外面只有线程T1。至于notifyAll()这个办法，它能够告诉期待队列中的所有线程。

这里我还是来一段代码再次阐明一下吧。上面的代码用管程实现了一个线程平安的阻塞队列（再次强调：这个阻塞队列和管程外部的期待队列没关系，示例代码只是用管程来实现阻塞队列，而不是解释管程外部期待队列的实现原理）。阻塞队列有两个操作别离是入队和出队，这两个办法都是先获取互斥锁，类比管程模型中的入口。

  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()语义是一样的。

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再次执行的时候，可能已经满足的条件，当初曾经不满足了，所以须要以循环形式测验条件变量。

notify()何时能够应用

还有一个须要留神的中央，就是notify()和notifyAll()的应用，后面章节，我已经介绍过， 除非通过三思而行，否则尽量应用notifyAll()。那什么时候能够应用notify()呢？须要满足以下三个条件：

  1. 所有期待线程领有雷同的期待条件；
  2. 所有期待线程被唤醒后，执行雷同的操作；
  3. 只须要唤醒一个线程。

比方下面阻塞队列的例子中，对于“阻塞队列不满”这个条件变量，其期待线程都是在期待“阻塞队列不满”这个条件，反映在代码里就是上面这3行代码。对所有期待线程来说，都是执行这3行代码， 重点是 while 外面的期待条件是完全相同的。

while (阻塞队列已满){  // 期待队列不满  notFull.await();}

所有期待线程被唤醒后执行的操作也是雷同的，都是上面这几行：

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

同时也满足第3条，只须要唤醒一个线程。所以下面阻塞队列的代码，应用signal()是能够的。

并发包中的管程

Java SDK并发包内容很丰盛，无所不包，然而我感觉最外围的还是其对管程的实现。因为实践上利用管程，你简直能够实现并发包里所有的工具类。在并发编程畛域，有两大外围问题：一个是 互斥，即同一时刻只容许一个线程访问共享资源；另一个是 同步，即线程之间如何通信、合作。这两大问题，管程都是可能解决的。 Java SDK并发包通过Lock和Condition两个接口来实现管程，其中Lock用于解决互斥问题，Condition用于解决同步问题。

你兴许听过，在Java的1.5版本中，synchronized性能不如SDK外面的Lock，但1.6版本之后，synchronized做了很多优化，将性能追了上来，所以1.6之后的版本又有人举荐应用synchronized了。那性能是否能够成为“反复造轮子”的理由呢？显然不能。因为性能问题优化一下就能够了，齐全没必要“反复造轮子”。

在解决死锁问题时，咱们有一个 毁坏不可抢占条件 计划，然而这个计划synchronized没有方法解决。起因是synchronized申请资源的时候，如果申请不到，线程间接进入阻塞状态了，而线程进入阻塞状态，啥都干不了，也开释不了线程曾经占有的资源。但咱们心愿的是：

对于“不可抢占”这个条件，占用局部资源的线程进一步申请其余资源时，如果申请不到，能够被动开释它占有的资源，这样不可抢占这个条件就毁坏掉了。

如果咱们从新设计一把互斥锁去解决这个问题，那该怎么设计呢？我感觉有三种计划。

  1. 可能响应中断。synchronized的问题是，持有锁A后，如果尝试获取锁B失败，那么线程就进入阻塞状态，一旦产生死锁，就没有任何机会来唤醒阻塞的线程。但如果阻塞状态的线程可能响应中断信号，也就是说当咱们给阻塞的线程发送中断信号的时候，可能唤醒它，那它就有机会开释已经持有的锁A。这样就毁坏了不可抢占条件了。
  2. 反对超时。如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个谬误，那这个线程也有机会开释已经持有的锁。这样也能毁坏不可抢占条件。
  3. 非阻塞地获取锁。如果尝试获取锁失败，并不进入阻塞状态，而是间接返回，那这个线程也有机会开释已经持有的锁。这样也能毁坏不可抢占条件。

这三种计划能够全面补救synchronized的问题。到这里置信你应该也能了解了，这三个计划就是“反复造轮子”的次要起因，体现在API上，就是Lock接口的三个办法。详情如下：

// 反对中断的APIvoid lockInterruptibly()  throws InterruptedException;// 反对超时的APIboolean tryLock(long time, TimeUnit unit)  throws InterruptedException;// 反对非阻塞获取锁的APIboolean tryLock();

如何保障可见性

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. 传递性规定：线程 T1的value+=1 Happens-Before 线程 T2 的 lock() 操作。
class SampleLock {  volatile int state;  // 加锁  lock() {    // 省略代码有数    state = 1;  }  // 解锁  unlock() {    // 省略代码有数    state = 0;  }}

可重入锁

如果你仔细察看，会发现咱们创立的锁的具体类名是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();    }  }}

偏心锁与非偏心锁

在应用ReentrantLock的时候，你会发现ReentrantLock这个类有两个构造函数，一个是无参构造函数，一个是传入fair参数的构造函数。fair参数代表的是锁的偏心策略，如果传入true就示意须要结构一个偏心锁，反之则示意要结构一个非偏心锁。

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

在后面咱们谈到入口期待队列，锁都对应着一个期待队列，如果一个线程没有取得锁，就会进入期待队列，当有线程开释锁的时候，就须要从期待队列中唤醒一个期待的线程。如果是偏心锁，唤醒的策略就是谁期待的工夫长，就唤醒谁，很偏心；如果是非偏心锁，则不提供这个偏心保障，有可能等待时间短的线程反而先被唤醒。

用锁的最佳实际

用锁尽管能解决很多并发问题，然而危险也是挺高的。可能会导致死锁，也可能影响性能。这方面有是否有相干的最佳实际呢？有，还很多。然而我感觉最值得举荐的是并发巨匠Doug Lea《Java并发编程：设计准则与模式》一书中，举荐的三个用锁的最佳实际，它们别离是：

  1. 永远只在更新对象的成员变量时加锁
  2. 永远只在拜访可变的成员变量时加锁
  3. 永远不在调用其余对象的办法时加锁

这三条规定，前两条预计你肯定会认同，最初一条你可能会感觉过于严苛。然而我还是偏向于你去恪守，因为调用其余对象的办法，切实是太不平安了，兴许“其余”办法外面有线程sleep()的调用，也可能会有奇慢无比的I/O操作，这些都会重大影响性能。更可怕的是，“其余”类的办法可能也会加锁，而后双重加锁就可能导致死锁。

并发问题，原本就难以诊断，所以你肯定要让你的代码尽量平安，尽量简略，哪怕有一点可能会出问题，都要致力防止。

上面咱们谈谈另外一个话题：Dubbo如何用管程实现异步转同步？

Java 语言内置的管程里只有一个条件变量，而Lock&Condition实现的管程是反对多个条件变量的，这是二者的一个重要区别。刚刚咱们讲了Java SDK并发包里的Lock有别于synchronized隐式锁的三个个性：可能响应中断、反对超时和非阻塞地获取锁。而Java SDK并发包里的Condition， 实现了管程模型外面的条件变量。

在很多并发场景下，反对多个条件变量可能让咱们的并发程序可读性更好，实现起来也更容易。例如，实现一个阻塞队列，就须要两个条件变量。

那如何利用两个条件变量疾速实现阻塞队列呢？

一个阻塞队列，须要两个条件变量，一个是队列不空（空队列不容许出队），另一个是队列不满（队列已满不容许入队）

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()，那程序可就彻底玩儿完了。

Java SDK并发包里的Lock和Condition不过就是管程的一种实现而已，管程你曾经很相熟了，那Lock和Condition的应用天然是小菜一碟。上面咱们就来看看在出名我的项目Dubbo中，Lock和Condition是怎么用的。不过在开始介绍源码之前，我还先要介绍两个概念：同步和异步。

同步与异步

什么时同步和异步？ 艰深点来讲就是调用方是否须要期待后果，如果须要期待后果，就是同步；如果不须要期待后果，就是异步。

比方在上面的代码里，有一个计算圆周率小数点后100万位的办法 pai1M()，这个办法可能须要执行俩礼拜，如果调用 pai1M() 之后，线程始终等着计算结果，等俩礼拜之后后果返回，就能够执行 printf("hello world") 了，这个属于同步；如果调用 pai1M() 之后，线程不必期待计算结果，立即就能够执行 printf("hello world")，这个就属于异步。

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

同步，是Java代码默认的解决形式。如果你想让你的程序反对异步，能够通过上面两种形式来实现：

  1. 调用方创立一个子线程，在子线程中执行办法调用，这种调用咱们称为异步调用；
  2. 办法实现的时候，创立一个新的线程执行次要逻辑，主线程间接return，这种办法咱们个别称为异步办法。

Dubbo源码剖析

其实在编程畛域，异步的场景还是挺多的，比方TCP协定自身就是异步的，咱们工作中常常用到的RPC调用， 在TCP协定层面，发送完RPC申请后，线程是不会期待RPC的响应后果的。可能你会感觉奇怪，平时工作中的RPC调用大多数都是同步的啊？这是怎么回事呢？

其实很简略，肯定是有人帮你做了异步转同步的事件。例如目前出名的RPC框架Dubbo就给咱们做了异步转同步的事件，那它是怎么做的呢？上面咱们就来剖析一下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这个类实现的。

调用栈信息

不过为了理清前后关系，还是有必要剖析一下调用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更易用。

总结

管程是一个解决并发问题的模型，你能够参考医院就医的流程来加深了解。了解这个模型的重点在于了解条件变量及其期待队列的工作原理。

Java参考了MESA模型，语言内置的管程（synchronized）对MESA模型进行了精简。MESA模型中，条件变量能够有多个，Java语言内置的管程里只有一个条件变量。具体如下图所示。

Java内置的管程计划（synchronized）应用简略，synchronized关键字润饰的代码块，在编译期会主动生成相干加锁和解锁的代码，然而仅反对一个条件变量；而Java SDK并发包实现的管程反对多个条件变量，不过并发包里的锁，须要开发人员本人进行加锁和解锁操作。

并发编程里两大外围问题——互斥和同步，都能够由管程来帮你解决。学好管程，实践上所有的并发问题你都能够解决，并且很多并发工具类底层都是管程实现的，所以学好管程，就是相当于把握了并发编程的基石。

Java SDK 并发包里的Lock接口外面的每个办法，你能够感触到，都是通过三思而行的。除了反对相似synchronized隐式加锁的lock()办法外，还反对超时、非阻塞、可中断的形式获取锁，这三种形式为咱们编写更加平安、强壮的并发程序提供了很大的便当。

除了并发巨匠Doug Lea举荐的三个最佳实际外，你也能够参考一些诸如：缩小锁的持有工夫、减小锁的粒度等业界广为人知的规定，其实实质上它们都是相通的，不过是在该加锁的中央加锁而已。

本文由mdnice多平台公布