Condition实现原理和源码分析

在AQS中存在两个FIFO队列：同步队列 和 等待队列。本篇文章主要是讲condition实现原理(即等待队里)，同步队列实现原理看这篇文章：深入理解AQS实现原理和源码分析。等待队列是由Condition内部实现的，是一个虚拟的FIFO单向队列，在AQS中同步队列、等待队列组成关系如下图：

• (1)AQS中tail 和 head主要构成了一个FIFO双向的同步队列。

• (2)AQS中condition构成了一个FIFO单向等待队列。condition是AQS内部类，每个Condition对象中保存了firstWaiter和lastWaiter作为队列首节点和尾节点，每个节点使用Node.nextWaiter保存下一个节点的引用，因此等待队列是一个单向队列。

1.队列关系

在Object的监视器(monitor)模型上，一个对象拥有一个同步队列和一个等待队列；而并发包中的AQS上拥有一个同步队列和多个等待队列。两者的具体实现原理的有所不同，但在多线程下等待/唤醒 操作的思路有相同之处，Object的监视器模型 和 AQS对同步队列、等待队列对应关系如下图

（1）Object的监视器模型同步、等待队列对应关系图

多个线程并发访问某个对象监视器(Monitor对象)的时候，即多线程执行Synchonized处的代码时，monitor处理过程包括：

• (1)thread进入Synchonized代码时，会执行Monitor.Enter命令来获取monitor对象。如果命令执行成功获取Monitor对象成功，执行失败线程会进入synchronized同步队列中，线程处于BLOCKED，直到monitor对象被释放。

• (2)thread执行完Synchonized同步代码块后，会执行Monitor.exit命令来释放monitor对象，并通知同步队列会获取monitor对象。

• (3)如果线程执行object.wait()，线程会进入synchronized等待队列进行WAITING，直到其他线程线程执行notify()或notifyAll()方法，将等待队列中的一个或多个等待线程从等待队列中移到同步队列中，被移动的线程状态由WAITING变为BLOCKED。

（2）AQS中同步、等待队列对应关系图

当多线程并发访问AQS的lock()、await()、single()方法时，同步队列和等待队列变化处理过程包括：

• （1）多个形成执行lock()方法时，线程会竞争获取同步锁state，获取成功的线程占有锁state、获取失败的线程会封装成node加入到AQS的同步队列中，等待锁state的释放。
• （2）等获取了state锁的线程(同步队列中head节点)执行await()方法时，condition会将当前线程封装成一个新的node添加到condition等待队列的尾部，同时阻塞(waiting)，直到被唤醒。
• （3）等获取了state锁的线程(同步队列中head节点)single()方法时，condition会将等待队列首节点移动到同步队列的尾部，直到获取同步锁state才被唤醒。

2.Condition的实现

（1）等待的实现