前几篇：
Java多线程编程--Java中的队列同步器AQS和ReentrantLock锁原理简要分析
Java多线程编程--读写锁ReentrantReadWriteLock深入分析
Condition接口简介
在上述两篇文章中讲解AQS的时候，我们已经知道了同步队列AQS的内部类ConditionObject实现了Condition接口，使用ReentrantLock和ReentrantReadWriteLock的内部类Sync我们可以通过newCondition()方法创建一个或多个ConditionObject对象。
在使用synchronized作为同步的时候，可以使用任意的Java对象作为锁，这是因为任意的一个Java对象，都拥有一组监视器方法，这些监视器方法是定义在超类Object中的，主要包括：wait、notify、notifyAll这些方法，这些方法与synchronized关键字配合实现等待/通知模式。
Condition接口也提供了类似object的监视器方法，与Lock配合使用也可以实现等待/通知模式，虽然如此，但是两者在使用方式以及功能功能上还是有些许差别的，主要差别如下：
Condition接口定义：
可以看到基本和Object超类中定义的差不多。
各接口的含义如下：
Condition接口使用案例
示例代码如下:
public class MyService {
private Lock lock = new ReentrantLock();
public Condition condition = lock.newCondition();
public void await() {
try {
lock.lock();
System.out.println(' await时间为 ' + System.currentTimeMillis());
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public void signal() {
try {
lock.lock();
System.out.println('signal时间为 ' + System.currentTimeMillis());
condition.signal();
} finally {
lock.unlock();
}
}
}测试代码如下：
public class Run {
public static void main(String[] args) throws InterruptedException {
MyService service = new MyService();
new ThreadA(service).start();
Thread.sleep(3000);
service.signal();
}
}执行结果：
看过《Java多线程编程--线程间通信机制的介绍与使用》这篇文章的小伙伴都应该还记得，我们使用wait和notify实现了一个阻塞队列，现在我们使用Condition对象搞一些事情，使用Condition把这个阻塞队列重写一下，代码如下：
public class MyQueue {
//1、需要一个承装元素的集合
private final LinkedListCondition接口实现原理
ConditionObject实现了Condition接口，是AQS的内部类，因为Condition的操作需要获取相关联的锁，所以作为同步器的内部类是一个比较合理的方式。每一个Condition对象都包含一个等待队列，该队列是Condition实现等待通知机制的关键。
和synchronized一样，在调用wait和notify等方法之前都必须要先获取锁，同样使用Condition对象的await和signal方法的时候也是要先获取到锁！
等待队列
等待队列是一个FIFO的队列，在队列中的每一个节点都包含一个线程的引用，该线程就是在Condition对象上等待的线程，如果一个线程调用了Conditioawait()方法，那么该线程将会释放锁，构造成节点加入等待队列并进入等待状态。这里的节点Node使用的是AQS中定义的Node。也就是说AQS中的同步队列和Condition的等待队列使用的节点类型都是AQS中定义的Node内部类。
一个Condition对象包含一个等待队列，Condition拥有首节点和尾节点。当前线程调用Conditioawait()方法，将会以当前线程构造节点，并将该节点从尾部加入到等待队列，等待队列的基本结构如下：
如上可知，Condition拥有首尾节点的引用，而新增节点只需要将原有的尾节点nextWaiter指向它，并且更新尾节点即可。上述节点引用更新的过程并没有使用到CAS保证，这是因为当前线程调用await方法的时候必定是获取了锁的线程，也就是说该过程是由锁来保证线程安全的。
我们知道在使用synchronized的时候，是使用的对象监视器模型的，即在Object的监视器模型上，一个对象拥有一个同步队列和等待队列，而Lock可以拥有一个同步队列和多个等待队列，这是因为通过locnewCondition()可以创建多个Condition条件，而这多个Condition对象都是在同一个锁的基础上创建的，在同一时刻也只能由一个线程获取到该锁。
Lock模式下同步队列和等待队列的对应关系如下：
又因为Condition的实现是AQS的内部类，因此每个Condition对象都可以访问AQS同步器提供的方法，相当于每个Condition都拥有所属同步器AQS的引用。
等待的实现
当前线程调用Conditioawait()方法的时候，相当于将当前线程从同步队列的首节点移动到Condition的等待队列中，并释放锁，同时线程变为等待状态。
当前线程加入到等待队列的过程如下：
可以看出同步队列的首节点并不是直接加入到等待队列的尾节点，而是封装成等待队列的节点才插入到等待队列的尾部的。
通知的实现
调用当前线程的Conditiosignal()方法，将会唤醒在等待队列中等待时间最长的节点也就是首节点，在唤醒节点之前，会将该节点移到同步队列中。
节点从等待队列加入到同步队列的过程如下：
通过调用同步器的方法将等待队列中的头结点线程安全的移到同步队列的尾节点，当前线程在使用LockSupport唤醒该节点的线程。
被唤醒后的线程，将会从await方法中的while循环中退出，进而调用同步器的方法加入到获取同步状态的竞争中。
成功获取同步状态之后，被唤醒的线程从先前调用的await饭发个返回，此时该线程已经成功的获取了锁。
Condition的signalAll()方法，相当于对等待队列中的每一个节点均执行一次signal方法，效果就是将等待队列中的所有节点全部移到同步队列中，并唤醒每个节点的线程。
参考文章：
部分内容和截来自《Java并发编程的艺术》
文章为作者独立观点，不代表股票交易接口观点
股民评论