学习JUC源码（3）——Condition等待队列（源码分析结合图文理解）
前言
在Java多线程中的wait/notify通信模式结尾就已经介绍过，Java线程之间有两种种等待/通知模式，在那篇博文中是利用Object监视器的方法（wait()，notify()、notifyAll()）实现的，然而在实际生产环境中不推荐使用此方法，建议使用condition的等待通知模式，JUC包中很多核心实现也确实证实了这点，所以这必然是学习JUC包源码的基础。
如果之前阅读过前不久介绍同步队列的博文学习JUC源码（1）——AQS同步队列（源码分析结合图文理解），就能更好理解Condition等待队列了，都是基于AQS.Node实现的队列，两者是同步器实现的核心所在！
主要参考资料《Java并发编程艺术》（有需要的小伙伴可以找我，我这里只有电子PDF）同时结合ReentranLock、AQS、ArrayBlockingQueue等源码。
一、Condition等待队列介绍
1、对比Object监视器方法与Condition方法
以下对比图来源于《Java并发编程艺术》，可以清楚看到Condition比Object监视器更加灵活，支持中断响应等。
2、Condition方法使用介绍
我们先看下阻塞队列ArrayBlockingQueue中关于condition的经典应用，这里使用就是condition的等待通知模式实现有界阻塞队列，即简单总结：当队列满时，阻塞插入线程，队列空时，获取元素的线程等待。
/** Condition for waiting takes */ private final Condition notEmpty; /** Condition for waiting puts */ private final Condition notFull; public void put(E e) throws InterruptedException { checkNotNull(e); final ReentrantLock lock = this.lock; lock.lockInterruptibly(); try { // 队列满时等待 while (count == items.length) notFull.await(); enqueue(e); } finally { lock.unlock(); } } public E take() throws InterruptedException { final ReentrantLock lock = this.lock; lock.lockInterruptibly(); try { // 队列空时进入Condition等待队列等待 while (count == 0) notEmpty.await(); return dequeue(); } finally { lock.unlock(); } }
从中我们看出两点：
- Condition要结合Lock对象实现，两者是同时存在的。准确来说先有Lock对象，然后再创建Condition对象
- 线程调用这些方法时候，需要提前获取到Condition对象关联的锁，Condition对象是由Lock对象（Lock.newConditoin()）创建出来的，也就是说Condition是依赖Lock对象的。
同样地，我们可以从中抽取出等待-通知模式，然后编写Demo如下，其中标红的可以理解为通用的等待/通知模式
public class ConditionDemo { ReentrantLock lock = new ReentrantLock(); // 一般Condition都是作为成员变量 Condition condition = lock.newCondition(); public void waitCondition() throws InterruptedException { lock.lock(); try { // 当前线程等待 // 调用signal方法后返回 System.out.println(Thread.currentThread()+" is waiting..., now: "+new Date()); Thread.sleep(2000); condition.await(); // 注意这里是await,而不是wait System.out.println(Thread.currentThread()+" return..., now: "+new Date()); } finally { lock.unlock(); } } public void signalCondition() throws InterruptedException { lock.lock(); try { // 唤醒获得condition上的等待锁 System.out.println(Thread.currentThread()+" is signaling..., now: "+new Date()); condition.signal(); } finally { lock.unlock(); } } public static void main(String[] args) { ConditionDemo condition = new ConditionDemo(); new Thread(()->{ try { condition.waitCondition(); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); new Thread(()->{ try { condition.signalCondition(); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); } }
运行Demo，可以看到等待线程确实等待了2s之后从await()方法返回。
Thread[Thread-0,5,main] is waiting..., now: Wed Dec 23 21:35:53 CST 2020 Thread[Thread-1,5,main] is signaling..., now: Wed Dec 23 21:35:55 CST 2020 Thread[Thread-0,5,main] return..., now: Wed Dec 23 21:35:55 CST 2020
接下来就是深入源码理解Condition等待队列是如何实现的
二、Condition等待队列的实现分析（源码分析）
1、Condition等待队列介绍
（1）概念认识
先引出简单的认识，其实对比同步队列来说，很好理解，实际上更加简单
- 等待队列是一个单向FIFO队列，队列每个节点都包含了一个线程引用，该线程是在Condition对象上等待的线程；
- 实际上这里的等待队列和AQS中的同步队列，都是采用AQS.Node静态内部类；
- 一个ConditionObject拥有首节点(fisrtWaiter)和尾节点(lastWaiter)；
- 如果一个线程调用了Condition.await()方法，那么该线程将会释放锁（从同步队列中移除），构造成节点加入等待队列，等待被唤醒；
- 如果一个线程调用了Condition.signal()方法，那么该线程将会被唤醒（从等待队列中移除），构造成节点加入同步队列，尝试重新获取同步状态；
（2）等待队列结构图
实际上，Condition的实现是在AQS中内部类ConditionObject实现Condition具体实现的：
等待队列的结构图如下图，相比较同步队列而言：
- 等待队列来说更加简单，是单向FIFO队列；
- Condition拥有首尾节点引用，新增节点直接nextWaiter指向即可，这个过程不需要CAS保证，因为调用Condition.await()方法肯定是获取了锁的线程，也就是说该过程是来保证线程安全的。
实际上，AQS同步器只拥有一个同步队列，但却有多个Condition等待队列，如下图。
2、await()方法实现解析
当调用await()方法时，相当于同步队列的首节点（获取了锁的节点）移动到了Condition的等待队列中。
更具体来说是首先调用await()方法之前肯定是能获取到同步状态的线程，也就是同步队列中首节点，之后调用await()方法由将释放锁，进入等待队列。
分析源码（重点部分都已经注释，结合图应该更好理解）：
1）调用await()方法，通过addConditionWaiter()方法加入等待线程，然后释放全部同步状态
2）进入while循环，判断是否已经移动到同步队列中，如果已经被移动到同步队列中则说明线程已经被唤醒（signal）；
3）接下来尝试获取竞争同步状态，即调用acquireQueue方法
public final void await() throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); // addConditionWaiter()方法当前线程加入等待队列 Node node = addConditionWaiter(); // 调用await()方法后释放锁（同步状态） int savedState = fullyRelease(node); int interruptMode = 0; // 检查node是否在同步队列中，不是的话说明已经获取到锁 // LockSupport.unpark唤醒线程后，从这里返回，此时已经在SyncQueue同步队列中，退出循环 // 从这里也可以看出，也是经典的等待/通知模式 while (!isOnSyncQueue(node)) { // 阻塞当前线程 LockSupport.park(this); // 在调用signal前抛出中断异常，或者调用之后中断，都退出循环 // THROW_IE if interrupted before signalled, REINTERRUPT if after signalled if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break; } // 被唤醒后的线程重新尝试竞争获取同步状态 if (acquireQueued(node, savedState) && interruptMode != THROW_IE) interruptMode = REINTERRUPT; if (node.nextWaiter != null) // clean up if cancelled unlinkCancelledWaiters(); if (interruptMode != 0) reportInterruptAfterWait(interruptMode); }
结构流程如下图：
3、signal()方法实现解析
调用signal方法将会唤醒等待队列中等待时间最长的节点（首节点），在唤醒节点之前，会将节点移动到同步队列中
具体来说当前线程获取到了锁，接着获取等待队列的首节点，将其移动到同步队列中，并且唤醒节点中的线程。
分析源码（重点部分都已经注释，结合图应该更好理解）：
1）进入signal()方法，调用doSignal(Node node)方法移动到同步队列中，并唤醒节点中线程
public final void signal() { // 判断当前线程是否持有获得锁 if (!isHeldExclusively()) throw new IllegalMonitorStateException(); Node first = firstWaiter; if (first != null) // 移动到同步队列中，并且唤醒节点中的线程 doSignal(first); } private void doSignal(Node first) { do { // 如果等待队列中只有一个节点（即首节点），则唤醒首节点后lastWaiter置空 if ( (firstWaiter = first.nextWaiter) == null) lastWaiter = null; // 否则获取等待队列中的首节点，即next域断开置空 first.nextWaiter = null; } while (!transferForSignal(first) && (first = firstWaiter) != null); }
2）doSignal(Node node)方法中调用transferForSignal(Node node)，通过调用enq(Node node)方法(这里其实就是同步队列的入队enq(Node node)方法)，等待队列中的头结点线程安全地移动到同步队列，当节点移动到同步队列后，当前线程将会被唤醒（LockSupport.unpark(node.thread)）。
final boolean transferForSignal(Node node) { /* * If cannot change waitStatus, the node has been cancelled. */ // 如果没有正确设置等待状态为初始状态准备加入同步队列中，则返回，当前节点状态为Node.CONDITION if (!compareAndSetWaitStatus(node, Node.CONDITION, 0)) return false; // 将等待队列中的头结点移动到同步队列中, 返回已经加入的当前node在同步队列中前节点 Node p = enq(node); int ws = p.waitStatus; if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL)) // 唤醒当前node线程，返回while(isOnSynQueue(Node node))处，退出循环 LockSupport.unpark(node.thread); return true; }
流程结构如下图：
