Java并发编程

并发编程

CPU是天上一天，内存是地上一年；

内存是天上一天，I/O设备是地上十年；

CPU增加了缓存，以均衡与内存的速度差异；

操作系统增加了进程、线程，以分时复用CPU，进而均衡CPU与I/O设备的速度差异；

编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。

单核时代所有的线程都是在一颗CPU上执行，CPU缓存与内存的数据一致性容易解决。
因为所有线程都是操作同一个CPU的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。

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

多核时代，每颗CPU都有自己的缓存，这时CPU缓存与内存的数据一致性就没那么容易解决了。
当多个线程在不同的CPU上执行时，这些线程操作的是不同的CPU缓存。

线程A操作的是CPU-1上的缓存，而线程B操作的是CPU-2上的缓存；
很明显，这个时候线程A对变量V的操作对于线程B而言就不具备可见性了

在一个时间片内一个进程进行一个IO操作，进程会释放CPU的使用权；
待文件读进内存，操作系统会唤起进程获得CPU使用权。

进程在等待IO时会释放CPU使用权是为了让CPU在等待时间里可以做别的事情，CPU的使用率就提高了

这时如果有另外一个进程也读文件，读文件的操作就会排队；
磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样IO的使用率也上来了。

Java并发程序都是基于多线程的，自然也会涉及到任务切换，也许你想不到，任务切换竟然也是并发编程里诡异Bug的源头之一；

任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条CPU指令完成；

比如count+=1至少需要三条CPU指令
指令1：首先，需要把变量count从内存加载到CPU的寄存器；
指令2：之后，在寄存器中执行+1操作；
指令3：最后，将结果写入内存（缓存机制导致可能写入的是CPU缓存而不是内存）。

假设有两个线程A、B同时调用getInstance()方法，他们会同时发现instance==null，于是同时对Singleton.class加锁，
此时JVM保证只有一个线程能够加锁成功（假设是线程A），另外一个线程则会处于等待状态（假设是线程B）；

线程A会创建一个Singleton实例，之后释放锁，锁释放后，线程B被唤醒，线程B再次尝试加锁，此时是可以加锁成功的，
加锁成功后，线程B检查instance==null时会发现，已经创建过Singleton实例了，所以线程B不会再创建一个Singleton实例。

这看上去一切都很完美，无懈可击，但实际上这个getInstance()方法并不完美。问题出在哪里呢？
出在new操作上，我们以为的new操作应该是：

• 分配一块内存M；
• 在内存M上初始化Singleton对象；
• 然后M的地址赋值给instance变量。

但是实际上优化后的执行路径却是这样的：

• 分配一块内存M；
• 将M的地址赋值给instance变量；
• 最后在内存M上初始化Singleton对象。

那么，如何做到“按需禁用”呢？

所以，为了解决可见性和有序性问题，只需要提供给程序员按需禁用缓存和编译优化的方法即可。

三个关键字

六项Happens-Before规则

直觉上看，应该是42，那实际应该是多少呢？
这个要看Java的版本，如果在低于1.5版本上运行，x可能是42，也有可能是0；
如果在1.5以上的版本上运行，x就是等于42。

分析一下，为什么1.5以前的版本会出现x=0的情况呢？
我相信你一定想到了，变量x可能被CPU缓存而导致可见性问题。
这个问题在1.5版本已经被圆满解决了。Java内存模型在1.5版本对volatile语义进行了增强。
怎么增强的呢？答案是一项Happens-Before规则。

如果望文生义（很多网文也都爱按字面意思翻译成“先行发生”），那就南辕北辙了；

Happens-Before并不是说前面一个操作发生在后续操作的前面，它真正要表达的是：
前面一个操作的结果对后续操作是可见的。就像有心灵感应的两个人，虽然远隔千里，一个人心之所想，另一个人都看得到

Happens-Before规则就是要保证线程之间的这种“心灵感应”。

比较正式的说法是：Happens-Before约束了编译器的优化行为，虽允许编译器优化，但是要求编译器优化后一定遵守Happens-Before规则。

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

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

指对一个volatile变量的写操作，Happens-Before于后续对这个volatile变量的读操作。

这个就有点费解了，对一个volatile变量的写操作相对于后续对这个volatile变量的读操作可见，这怎么看都是禁用缓存。
貌似和1.5版本以前的语义没有变化啊？
如果单看这个规则，的确是这样，但是如果我们关联一下规则3.3，就有点不一样的感觉了。

这条规则是指如果AHappens-BeforeB，且BHappens-BeforeC，那么AHappens-BeforeC。

“x=42”Happens-Before写变量“v=true”，这是规则3.1的内容；
写变量“v=true”Happens-Before读变量“v=true”，这是规则3.2的内容。

再根据这个传递性规则，我们得到结果：“x=42”Happens-Before读变量“v=true”。这意味着什么呢？
如果线程B读到了“v=true”，那么线程A设置的“x=42”对线程B是可见的。
也就是说，线程B能看到“x==42”，有没有一种恍然大悟的感觉？

这就是1.5版本对volatile语义的增强，这个增强意义重大。
1.5版本的并发工具包（java.util.concurrent）就是靠volatile语义来搞定可见性的，这个在后面的内容中会详细介绍。

这条规则是指对一个锁的解锁Happens-Before于后续对这个锁的加锁。

要理解这个规则，就首先要了解“管程指的是什么”。

假设x的初始值是10，线程A执行完代码块后x的值会变成12（执行完自动释放锁），
线程B进入代码块时，能够看到线程A对x的写操作，也就是线程B能够看到x==12。完全符合我们直觉很容易理解

规则这条是关于线程启动的。它是指主线程A启动子线程B后，子线程B能够看到主线程在启动子线程B前的操作。

换句话说就是，如果线程A调用线程B的start()方法（即在线程A中启动线程B），那么该start()操作Happens-Before于线程B中的任意操作。

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

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

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

原子性问题的源头是线程切换，如果能够禁用线程切换那不就能解决这个问题了吗？
而操作系统做线程切换是依赖CPU中断的，所以禁止CPU发生中断就能够禁止线程切换。

单核CPU场景

多核CPU场景

“同一时刻只有一个线程执行”这个条件非常重要，我们称之为互斥。
如果我们能够保证对共享变量的修改是互斥的，那么，无论是单核CPU还是多核CPU，就都能保证原子性了。

互斥执行的代码叫做临界区。

错误理解例子

现实世界中

并发编程中

首先，我们要把临界区要保护的资源标注出来，如图中临界区里增加了一个元素：受保护的资源R；
其次，我们要保护资源R就得为它创建一把锁LR；
最后，针对这把锁LR，我们还需在进出临界区时添上加锁操作和解锁操作。

另外，在锁LR和受保护资源之间，我特地用一条线做了关联，这个关联关系非常重要。
很多并发Bug的出现都是因为把它忽略了，然后就出现了类似锁自家门来保护他家资产的事情，
这样的Bug非常不好诊断，因为潜意识里我们认为已经正确加锁了。

锁是一种通用的技术方案，Java语言提供的synchronized关键字，就是锁的一种实现。

synchronized关键字可以用来修饰方法，也可以用来修饰代码块

这个和我们上面提到的模型有点对不上号啊，加锁lock()和解锁unlock()在哪里呢？

那synchronized里的加锁lock()和解锁unlock()锁定的对象在哪里呢？

举例说明：用synchronized解决count+=1

受保护资源和锁之间的关联关系非常重要，他们的关系是怎样的呢？

如果你仔细观察，就会发现改动后的代码是用两个锁保护一个资源。这个受保护的资源就是静态变量value，两个锁分别是this和SafeCalc.class。

由于临界区get()和addOne()是用两个锁保护的，因此这两个临界区没有互斥关系，临界区addOne()对value的修改对临界区get()也没有可见性保证，这就导致并发问题了。

在现实世界里，球场的座位和电影院的座位就是没有关联关系的，
这种场景非常容易解决，那就是球赛有球赛的门票，电影院有电影院的门票，各自管理各的

同样这对应到编程领域，也很容易解决。
例如，银行业务中有针对账户余额（余额是一种资源）的取款操作，也有针对账户密码（密码也是一种资源）的更改操作，
我们可以为账户余额和账户密码分配不同的锁来解决并发问题，这个还是很简单的。

账户类Account有两个成员变量，分别是账户余额balance和账户密码password。
取款withdraw()和查看余额getBalance()操作会访问账户余额balance，我们创建一个final对象balLock作为锁（类比球赛门票）；
而更改密码updatePassword()和查看密码getPassword()操作会修改账户密码password，我们创建一个final对象pwLock作为锁（类比电影票）。
不同的资源用不同的锁保护，各自管各自的，很简单。

当然，我们也可以用一把互斥锁来保护多个资源，例如我们可以用this这一把锁来管理账户类里所有的资源：账户余额和用户密码。具体实现很简单，示例程序中所有的方法都增加同步关键字synchronized就可以了，这里我就不一一展示了。

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

如果多个资源是有关联关系的，那这个问题就有点复杂了。

。例如银行业务里面的转账操作，账户A减少100元，账户B增加100元。这两个账户就是有关联关系的。

那对于像转账这种有关联关系的操作，我们应该怎么去解决呢？先把这个问题代码化。我们声明了个账户类：
Account，该类有一个成员变量余额：balance，
还有一个用于转账的方法：transfer()，然后怎么保证转账操作transfer()没有并发问题呢？

相信你的直觉会告诉你这样的解决方案：
用户synchronized关键字修饰一下transfer()方法就可以了，
于是你很快就完成了相关的代码

用同一把锁来保护多个资源，也就是现实世界的“包场”，
那在编程领域应该怎么“包场”呢？

例子中this是对象级别的锁，所以A对象和B对象都有自己的锁，如何让A对象和B对象共享一把锁呢？

我们把Account默认构造函数变为private，同时增加一个带Objectlock参数的构造函数，
创建Account对象时，传入相同的lock，这样所有的Account对象都会共享这个lock了。

上面的方案缺乏实践的可行性，我们需要更好的方案。
还真有，就是用Account.class作为共享的锁。
Account.class是所有Account对象共享的，而且这个对象是Java虚拟机在加载Account类的时候创建的，
所以我们不用担心它的唯一性。
使用Account.class作为共享的锁，我们就无需在创建Account对象时传入了，代码更简单。

如果没有信息化，账户的存在形式真的就是一个账本，
而且每个账户都有一个账本，这些账本都统一存放在文件架上。

银行柜员在给我们做转账时，要去文件架上把转出账本和转入账本都拿到手，然后做转账。

在transfer()方法内部，我们首先尝试锁定转出账户this（先把转出账本拿到手），
然后尝试锁定转入账户target（再把转入账本拿到手），只有当两者都成功时，才执行转账操作。

经过这样的优化后，账户A转账户B和账户C转账户D这两个转账操作就可以并行了。

使用细粒度锁这么简单，有这样的好事，是不是也要付出点什么代价啊？

编写并发程序就需要这样时时刻刻保持谨慎。

的确，使用细粒度锁是有代价的，这个代价就是可能会导致死锁。

如果有客户找柜员张三做个转账业务：账户A转账户B100元，此时另一个客户找柜员李四也做个转账业务：
账户B转账户A100元，于是张三和李四同时都去文件架上拿账本，这时候有可能凑巧张三拿到了账本A，李四拿到了账本B。
张三拿到账本A后就等着账本B（账本B已经被李四拿走），
而李四拿到账本B后就等着账本A（账本A已经被张三拿走），他们要等多久呢？
他们会永远等待下去…因为张三不会把账本A送回去，李四也不会把账本B送回去。我们姑且称为死等吧。

上面转账的代码是怎么发生死锁的呢？
我们假设线程T1执行账户A转账户B的操作，账户A.transfer(账户B)；同时线程T2执行账户B转账户A的操作，账户B.transfer(账户A)。
当T1和T2同时执行完①处的代码时，T1获得了账户A的锁（对于T1，this是账户A），而T2获得了账户B的锁（对于T2，this是账户B）。
之后T1和T2在执行②处的代码时，T1试图获取账户B的锁时，发现账户B已经被锁定（被T2锁定），所以T1开始等待；
T2则试图获取账户A的锁时，发现账户A已经被锁定（被T1锁定），所以T2也开始等待。
于是T1和T2会无期限地等待下去，也就是我们所说的死锁了。

资源用方形节点表示，线程用圆形节点表示；
资源中的点指向线程的边表示线程已经获得该资源，线程指向资源的边则表示线程请求资源，但尚未得到。

从理论上讲，要破坏这个条件，可以一次性申请所有资源。

在现实世界里，就拿前面我们提到的转账操作来讲，它需要的资源有两个，一个是转出账户，
另一个是转入账户，当这两个账户同时被申请时，我们该怎么解决这个问题呢？

对应到编程领域，“同时申请”这个操作是一个临界区，我们也需要一个角色（Java里面的类）来管理这个临界区，
我们就把这个角色定为Allocator。它有两个重要功能，分别是：同时申请资源apply()和同时释放资源free()。

破坏不可抢占条件看上去很简单，核心是要能够主动释放它占有的资源，这一点synchronized是做不到的。

你可能会质疑，“Java作为排行榜第一的语言，这都解决不了？”你的怀疑很有道理，Java在语言层次确实没有解决这个问题，
不过在SDK层面还是解决了的，java.util.concurrent这个包下面提供的Lock是可以轻松解决这个问题的。

破坏这个条件，需要对资源进行排序，然后按序申请资源。

这个实现非常简单，我们假设每个账户都有不同的属性id，这个id可以作为排序字段，申请的时候，我们可以按照从小到大的顺序来申请。

比如下面代码中，①~⑥处的代码对转出账户（this）和转入账户（target）排序，然后按照序号从小到大的顺序锁定账户。这样就不存在“循环”等待了。

患者先去挂号，然后到就诊门口分诊，等待叫号；

当叫到自己的号时，患者就可以找大夫就诊了；

就诊过程中，大夫可能会让患者去做检查，同时叫下一位患者；

当患者做完检查后，拿检测报告重新分诊，等待叫号；

当大夫再次叫到自己的号时，患者再去找大夫就诊。

患者到就诊门口分诊，类似于线程要去获取互斥锁；当患者被叫到时，类似线程已经获取到锁了；

大夫让患者去做检查（缺乏检测报告不能诊断病因），类似于线程要求的条件没有满足；

患者去做检查，类似于线程进入等待状态；然后大夫叫下一个患者，这个步骤我们在前面的等待-通知机制中忽视了，
这个步骤对应到程序里，本质是线程释放持有的互斥锁；

患者做完检查，类似于线程要求的条件已经满足；
患者拿检测报告重新分诊，类似于线程需要重新获取互斥锁，这个步骤我们在前面的等待-通知机制中也忽视了。

线程首先获取互斥锁，当线程要求的条件不满足时，释放互斥锁，进入等待状态；当要求的条件满足时，通知等待的线程，重新获取互斥锁。

图中左边有一个等待队列，同一时刻，只允许一个线程进入synchronized保护的临界区（这个临界区可以看作大夫的诊室），
当有一个线程进入临界区后，其他线程就只能进入图中左边的等待队列里等待（相当于患者分诊等待）。
这个等待队列和互斥锁是一对一的关系，每个互斥锁都有自己独立的等待队列。

在并发程序中，当一个线程进入临界区后，由于某些条件不满足，需要进入等待状态，Java对象的wait()方法就能够满足这种需求。

如上图所示，当调用wait()方法后，当前线程就会被阻塞，并且进入到右边的等待队列中，这个等待队列也是互斥锁的等待队列。线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。

线程要求的条件满足时，该怎么通知这个等待的线程呢？很简单，就是Java对象的notify()和notifyAll()方法。

图里为你大致描述了这个过程，当条件满足时调用notify()，会通知等待队列（互斥锁的等待队列）中的线程，告诉它条件曾经满足过。

为什么说是曾经满足过呢？

互斥锁：上一篇文章我们提到Allocator需要是单例的，所以我们可以用this作为互斥锁。

线程要求的条件：转出账户和转入账户都没有被分配过。

何时等待：线程要求的条件不满足就等待。

何时通知：当有线程释放账户时就通知。

这二者是有区别的，notify()是会随机地通知等待队列中的一个线程，而notifyAll()会通知等待队列中的所有线程。

从感觉上来讲，应该是notify()更好一些，因为即便通知所有线程，也只有一个线程能够进入临界区。

但那所谓的感觉往往都蕴藏着风险，实际上使用notify()也很有风险，它的风险在于可能导致某些线程永远不会被通知到。

我们再假设之后线程1归还了资源AB，如果使用notify()来通知等待队列中的线程，有可能被通知的是线程4，
但线程4申请的是CD，所以此时线程4还是会继续等待，而真正该唤醒的线程3就再也没有机会被唤醒了。

因此，除非经过深思熟虑，否则尽量使用notifyAll()。

其实本质上就是正确性，而正确性的含义就是程序按照我们期望的执行，不要让我们感到意外。

理论上线程安全的程序，就要避免出现原子性问题、可见性问题和有序性问题。

当然不是，其实只有一种情况需要：存在共享数据并且该数据会发生变化，通俗地讲就是有多个线程会同时读写同一数据。

那如果能够做到不共享数据或者数据状态不发生变化，不就能够保证线程的安全性了嘛！

但是，现实生活中，必须共享会发生变化的数据，这样的应用场景还是很多的。

对于上面示例，我们稍作修改，增加两个被synchronized修饰的get()和set()方法，
add10K()方法里面通过get()和set()方法来访问value变量，修改后的代码如下所示。
对于修改后的代码，所有访问共享变量value的地方，我们都增加了互斥锁，此时是不存在数据竞争的。
但很显然修改后的add10K()方法并不是线程安全的。

假设count=0，当两个线程同时执行get()方法时，get()方法会返回相同的值0，两个线程执行get()+1操作，结果都是1，
之后两个线程再将结果1写入了内存。你本来期望的是2，而结果却是1。

例如上面的例子，如果两个线程完全同时执行，那么结果是1；如果两个线程是前后执行，那么结果就是2。

在并发环境里，线程的执行顺序是不确定的，如果程序存在竞态条件问题，那就意味着程序执行的结果是不确定的，而执行结果不确定这可是个大Bug。

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

其实这两类问题，都可以用互斥这个技术方案，而实现互斥的方案有很多，CPU提供了相关的互斥指令，操作系统、编程语言也会提供相关的API。

从逻辑上来看，我们可以统一归为：锁。

可以类比现实世界里的例子，路人甲从左手边出门，路人乙从右手边进门，两人为了不相撞，互相谦让，
路人甲让路走右手边，路人乙也让路走左手边，结果是两人又相撞了。
这种情况，基本上谦让几次就解决了，因为人会交流啊。
可是如果这种情况发生在编程世界了，就有可能会一直没完没了地“谦让”下去，成为没有发生阻塞但依然执行不下去的“活锁”。

解决“活锁”的方案很简单，谦让时，尝试等待一个随机的时间就可以了。

例如上面的那个例子，路人甲走左手边发现前面有人，并不是立刻换到右手边，而是等待一个随机的时间后，再换到右手边；
同样，路人乙也不是立刻切换路线，也是等待一个随机的时间再切换。
由于路人甲和路人乙等待的时间是随机的，所以同时相撞后再次相撞的概率就很低了。
“等待一个随机时间”的方案虽然很简单，却非常有效，Raft这样知名的分布式一致性算法中也用到了它。

所谓“饥饿”指的是线程因无法访问所需资源而无法执行下去的情况。

“不患寡，而患不均”，如果线程优先级“不均”，在CPU繁忙的情况下，优先级低的线程得到执行的机会很小，就可能发生线程“饥饿”；
持有锁的线程，如果执行的时间过长，也可能导致“饥饿”问题。

解决“饥饿”问题的方案很简单，有三种方案：一是保证资源充足，二是公平地分配资源，三就是避免持有锁的线程长时间执行。

这三个方案中，方案一和方案三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。
倒是方案二的适用场景相对来说更多一些。

在并发编程里，主要是使用公平锁。所谓公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

有个阿姆达尔（Amdahl）定律，代表了处理器并行运算之后效率提升的能力，它正好可以解决这个问题，具体公式如下：

公式里的n可以理解为CPU的核数，p可以理解为并行百分比，那（1-p）就是串行百分比了，也就是我们假设的5%。
我们再假设CPU的核数（也就是n）无穷大，那加速比S的极限就是20。
也就是说，如果我们的串行率是5%，那么我们无论采用什么技术，最高也就只能提高20倍的性能。

这个问题很复杂，JavaSDK并发包里之所以有那么多东西，有很大一部分原因就是要提升在某个特定领域的性能。

方案层面解决这个问题

吞吐量：指的是单位时间内能处理的请求数量。吞吐量越高，说明性能越好。

延迟：指的是从发出请求到收到响应的时间。延迟越小，说明性能越好。

并发量：指的是能同时处理的请求数量，一般来说随着并发量的增加、延迟也会增加。所以延迟这个指标，一般都会是基于并发量来说的。例如并发量是1000的时候，延迟是50毫秒。

我以为它会提供信号量这种编程原语，因为操作系统原理课程告诉我，用信号量能解决所有并发问题，结果我发现不是。

后来我找到了原因：Java采用的是管程技术，synchronized关键字及wait()、notify()、notifyAll()这三个方法都是管程的组成部分。

而管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。但是管程更容易使用，所以Java选择了管程。

现在广泛应用的是MESA模型，并且Java管程的实现参考的也是MESA模型

一个是互斥，即同一时刻只允许一个线程访问共享资源；

另一个是同步，即线程之间如何通信、协作。

假如我们要实现一个线程安全的阻塞队列，一个最直观的想法就是：
将线程不安全的队列封装起来，对外提供线程安全的操作方法，例如入队操作和出队操作。

管程X将共享变量queue这个线程不安全的队列和相关的操作入队操作enq()、出队操作deq()都封装起来了；
线程A和线程B如果想访问共享变量queue，只能通过调用管程提供的enq()、deq()方法来实现；enq()、deq()保证互斥性，只允许一个线程进入管程。

这个比较复杂不过可以借鉴一下我们曾经提到过的就医流程，它可以帮助你快速地理解这个问题。

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

管程里还引入了条件变量的概念，而且每个条件变量都对应有一个等待队列，条件变量A和条件变量B分别都有自己的等待队列。

其实就是解决线程同步问题。

如果线程T1进入管程后恰好发现阻塞队列是空的，那怎么办呢？等待啊，去哪里等呢？

wait()、notify()、notifyAll()这三个操作

下面的代码用管程实现了一个线程安全的阻塞队列。
阻塞队列有两个操作分别是入队和出队，这两个方法都是先获取互斥锁，类比管程模型中的入口。

Hasen模型里面：要求notify()放在代码的最后，这样T2通知完T1后，T2就结束了，然后T1再执行，这样就能保证同一时刻只有一个线程执行。

Hoare模型里面：T2通知完T1后，T2阻塞，T1马上执行；等T1执行完，再唤醒T2，也能保证同一时刻只有一个线程执行。
但是相比Hasen模型，T2多了一次阻塞唤醒操作。

MESA管程里面：T2通知完T1后，T2还是会接着执行，T1并不立即执行，仅仅是从条件变量的等待队列进到入口等待队列里面。
这样做的好处是notify()不用放到代码的最后，T2也没有多余的阻塞唤醒操作。
但是也有个副作用，就是当T1再次执行的时候，可能曾经满足的条件，现在已经不满足了，所以需要以循环方式检验条件变量。

所有等待线程拥有相同的等待条件；

所有等待线程被唤醒后，执行相同的操作；

只需要唤醒一个线程。

用的线程生命周期基本上可以用下图这个“五态模型”来描述

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

Java 语言中线程共有六种状态

但其实在操作系统层面，Java 线程中的 BLOCKED、WAITING、TIMED_WAITING 是一种状态，即前面我们提到的休眠状态。

1）RUNNABLE 与 BLOCKED 的状态转换

2）RUNNABLE 与 WAITING 的状态转换

3）RUNNABLE 与 TIMED_WAITING 的状态转换

4）从 NEW 到 RUNNABLE 状态

5）从 RUNNABLE 到 TERMINATED 状态

上面五个完美回答了下面的问题，BLOCKED、WAITING、TIMED_WAITING 可以理解为线程导致休眠状态的三种原因。
那具体是哪些情形会导致线程从 RUNNABLE 状态转换到这三种状态呢？
而这三种状态又是何时转换回 RUNNABLE 的呢？
以及 NEW、TERMINATED 和 RUNNABLE 状态是如何转换的？