上篇博文，我们重点介绍阻塞队列BlockingQueue，并实现了生产者和消费者模式。这篇博文，我们重点介绍Condition的相关内容，我们会通过两篇博文来介绍Condition。这篇是对Condition的简介，与Object类的等待通知模式简单对比，Condition接口具体实现，以及等待队列原理解析。然后通过源码解读，看具体实现并使用Condition实现生产者和消费者模式。
Condition简介
Condition是在AQS中配合使用的线程通信协调工具类，我们可以称之为等待队列。Condition定义了等待/通知两种类型的方法，当前线程调用这些方法时，需要提前获取到Condition对象关联的锁。Condition对象是调用Lock对象的newCondition()方法创建出来的，换句话说，Condition是依赖Lock对象。
Object类的等待/通知模式，简单对比
在使用Lock之前，我们使用的最多的同步方式应该是synchronized关键字来实现同步方式。配合Object的wait()、notify()系列方法可以实现等待/通知模式。
我们知道，对于任何一个java对象都天然继承于Object类，在线程间实现通信的往往会应用到Object的几个方法，比如wait(),wait(long timeout),wait(long timeout, int nanos)与notify(),notifyAll()几个方法实现等待/通知机制。
从整体上来看Object的wait和notify/notify是与对象监视器配合完成线程间的等待/通知机制，而Condition与Lock配合完成等待通知机制，前者是java底层级别的，后者是语言级别的，具有更高的可控制性和扩展性。两者除了在使用方式上不同外，在功能特性上还是有很多的不同：
- Condition能够支持不响应中断，而通过使用Object方式不支持；
- Condition能够支持多个等待队列（new 多个Condition对象），而Object方式只能支持一个；
- Condition能够支持超时时间的设置，而Object不支持
Condition接口
参照Object的wait和notify/notifyAll方法，Condition也提供了同样的方法：
针对Object的wait方法
| 方法 | 描述 |
|---|---|
| void await() throws InterruptedException | 当前线程进入等待状态，如果其他线程调用condition的signal或者signalAll方法并且当前线程获取Lock从await方法返回，如果在等待状态中被中断会抛出被中断异常 |
| long awaitNanos(long nanosTimeout） | 造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。返回值表示剩余时间，如果在nanosTimesout之前唤醒，那么返回值 = nanosTimeout - 消耗时间，如果返回值 <= 0 ,则可以认定它已经超时了； |
| boolean await(long time, TimeUnit unit)throws InterruptedException | 同第二种，支持自定义时间单位 |
| boolean awaitUntil(Date deadline) throws InterruptedException | 造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。如果没有到指定时间就被通知，则返回true，否则表示到了指定时间，返回返回false |
| void awaitUninterruptibly() | 造成当前线程在接到信号之前一直处于等待状态。【注意：该方法对中断不敏感】 |
针对Object的notify/notifyAll方法
| 方法 | 描述 |
|---|---|
| void signal() | 唤醒一个等待在condition上的线程，将该线程从等待队列中转移到同步队列中，如果在同步队列中能够竞争到Lock则可以从等待方法中返回。 |
| void signalAll() | 与1的区别在于能够唤醒所有等待在condition上的线程 |
Condition的实现类
Condition 接口有 2 个实现类，一个是 AbstractQueuedSynchronizer.ConditionObject，还有一个是 AbstractQueuedLongSynchronizer.ConditionObject，都是 AQS 的内部类，该类结构如下：
condition内部维护了一个等待队列，所有调用condition.await方法的线程会加入到等待队列中，并且线程状态转换为等待状态。另外注意到ConditionObject中有两个成员变量，如上图红框内所示，这样我们就可以看出来ConditionObject是通过持有等待队列的头尾指针来管理等待队列。主要注意的是Node类复用了在AQS中的Node类，Node类有一个nextWaiter指向后继节点。
等待队列实现原理分析
等待队列，其实是一个单向队列或者说单向链表。每个Condition对象都包含一个队列(等待队列)。等待队列是一个FIFO的队列，在队列中的每个节点都包含了一个线程引用，该线程就是在Condition对象上等待的线程，如果一个线程调用了Condition.await()方法，那么该线程将会释放锁、构造成节点加入等待队列并进入等待状态。等待队列的基本结构如下所示。
等待队列分为首节点和尾节点。当一个线程调用Condition.await()方法，将会以当前线程构造节点，并将节点从尾部加入等待队列。新增节点就是将尾部节点指向新增的节点。节点引用更新本来就是在获取锁以后的操作，所以不需要CAS保证。同时也是线程安全的操作。
同时还有一点需要注意的是：我们可以多次调用lock.newCondition()方法创建多个condition对象，也就是一个lock可以持有多个等待队列。而在之前利用Object的方式实际上是指在对象Object对象监视器上只能拥有一个同步队列和一个等待队列，而并发包中的Lock拥有一个同步队列和多个等待队列。示意图如下：
如图所示，ConditionObject是AQS的内部类，因此每个ConditionObject能够访问到AQS提供的方法，相当于每个Condition都拥有所属同步器的引用。
总结
这篇博客，我们重点介绍什么是Condition，Condition与Lock结合实现等待、通知与Object的实现区别，并重点介绍了等待队列的原理分析。下篇博文，我们通过源码解析 Condition的两个核心接口await 和 signal。
转载：https://blog.csdn.net/jiuqiyuliang/article/details/102388323