java并发API：Condition与ReentrantLock

今天打算写一下ReentrantLock和Condition，ReentrantLock是jdk中concurrent包提供的一种独占锁的实现。主要实现是通过内部的三个内部类来实现，抽象类Sync以及其实现FairSync，NonfairSync，另外Sync继承了AbstractQueuedSynchronizer。

先来一个例子：

public class ConditionTest {
	final Lock lock = new ReentrantLock();
	final Condition notFull = lock.newCondition();
	final Condition notEmpty = lock.newCondition();

	final Object[] items = new Object[100];
	int putptr, takeptr, count;

	public void put(Object x) throws InterruptedException {
		lock.lock();
		try {
			while (count == items.length){
				System.out.println("count满了!");
				notFull.await();
			}
			System.out.println("count可以放入!");
			items[putptr] = x;
			if (++putptr == items.length)
				putptr = 0;
			++count;
			notEmpty.signal();
		} finally {
			lock.unlock();
		}
	}

	public Object take() throws InterruptedException {
		lock.lock();
		try {
			while (count == 0) {
				System.out.println("count空了!");
				notEmpty.await();
			}
			System.out.println("count可以取了!");
			Object x = items[takeptr];
			if (++takeptr == items.length)
				takeptr = 0;
			--count;
			notFull.signal();
			return x;
		} finally {
			lock.unlock();
		}
	}

	public static void main(String[] args) throws InterruptedException {
		final ConditionTest test = new ConditionTest();
		
		new Thread("take") {
			public void run() {
				try {
					System.out.println(test.take());
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			};
		}.start();
		
		new Thread("put") {
			public void run() {
				try {
					test.put("tiantian");
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			};
		}.start();
	}
}

结果：

count空了!
count可以放入!
count可以取了!
tiantian

解析：

当take线程执行到notEmpty.await()的时候，线程take将会以原子方式释放锁，并在等待返回前重新获取锁。然后put线程获取到锁，执行到notEmpty.signal()时候，唤醒take线程，然后take线程在await处恢复继续执行，打印"count可以 取了"，然后打印"tiantian"。

Condition 将 Object 监视器方法（wait、notify 和 notifyAll）分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set（wait-set）。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。 

条件（也称为条件队列 或条件变量）为线程提供了一个含义，以便在某个状态条件现在可能为 true 的另一个线程通知它之前，一直挂起该线程（即让其“等待”）。因为访问此共享状态信息发生在不同的线程中，所以它必须受保护，因此要将某种形式的锁与该条件相关联。等待提供一个条件的主要属性是：以原子方式 释放相关的锁，并挂起当前线程，就像 Object.wait 做的那样。

Condition 实例实质上被绑定到一个锁上。要为特定 Lock 实例获得 Condition 实例，请使用其 newCondition() 方法。  

如何实现的呢？

首先从创建开始，lock.newCondition()

public Condition newCondition() {
    return sync.newCondition();
}

因为创建的方法是：

final Lock lock = new ReentrantLock();

public ReentrantLock() {
    sync = new NonfairSync();
}

创建的Condition其实是：

final ConditionObject newCondition() {
    return new ConditionObject();
}

Condition内部维护了等待队列的头结点和尾节点，该队列的作用是存放等待signal信号的线程，该线程被封装为Node节点后存放于此。

        /** First node of condition queue. */
        private transient Node firstWaiter;
        /** Last node of condition queue. */
        private transient Node lastWaiter;

关键的就在于此，我们知道AQS自己维护的队列是当前等待资源的队列，AQS会在资源被释放后，依次唤醒队列中从前到后的所有节点，使他们对应的线程恢复执行。直到队列为空。


而Condition自己也维护了一个队列，该队列的作用是维护一个等待signal信号的队列，两个队列的作用是不同，事实上，每个线程也仅仅会同时存在以上两个队列中的一个，流程是这样的：


1. 线程1调用reentrantLock.lock时，线程被加入到AQS的等待队列中。


2. 线程1调用await方法被调用时，该线程从AQS中移除，对应操作是锁的释放。


3. 接着马上被加入到Condition的等待队列中，以为着该线程需要signal信号。


4. 线程2，因为线程1释放锁的关系，被唤醒，并判断可以获取锁，于是线程2获取锁，并被加入到AQS的等待队列中。


5.  线程2调用signal方法，这个时候Condition的等待队列中只有线程1一个节点，于是它被取出来，并被加入到AQS的等待队列中。  注意，这个时候，线程1 并没有被唤醒。


6. signal方法执行完毕，线程2调用reentrantLock.unLock()方法，释放锁。这个时候因为AQS中只有线程1，于是，AQS释放锁后按从头到尾的顺序唤醒线程时，线程1被唤醒，于是线程1回复执行。


7. 直到释放所整个过程执行完毕。


可以看到，整个协作过程是靠结点在AQS的等待队列和Condition的等待队列中来回移动实现的，Condition作为一个条件类，很好的自己维护了一个等待信号的队列，并在适时的时候将结点加入到AQS的等待队列中来实现的唤醒操作。


看到这里，signal方法的代码应该不难理解了。

现在来看一下主要的await方法和signal方法，其实调用的都是AbstractQueuedSynchronizer的方法

        public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            Node node = addConditionWaiter();  //添加到Condition自己维护的一个链表中
            int savedState = fullyRelease(node);//释放当前线程占有的锁，调用await前，当前线程是占有锁的
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) { //释放完毕后，遍历AQS的队列，看当前节点是否在队列中，不在 说明它还没有竞争锁的资格，所以继续将自己沉睡。直到它被加入到队列中，在singal的时候加入
                LockSupport.park(this);
                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);
        }

        public final void signal() {
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            Node first = firstWaiter;firstWaiter为condition自己维护的一个链表的头结点，取出第一个节点后开始唤醒操作
            if (first != null)
                doSignal(first);
        }

        private void doSignal(Node first) {
            do {
                if ( (firstWaiter = first.nextWaiter) == null)//修改头结点，完成旧头结点的移出工作
                    lastWaiter = null;
                first.nextWaiter = null;
            } while (!transferForSignal(first) &&   //将老的头结点，加入到AQS的等待队列中
                     (first = firstWaiter) != null);
        }

    final boolean transferForSignal(Node node) {
        /*
         * If cannot change waitStatus, the node has been cancelled.
         */
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
            return false;

        /*
         * Splice onto queue and try to set waitStatus of predecessor to
         * indicate that thread is (probably) waiting. If cancelled or
         * attempt to set waitStatus fails, wake up to resync (in which
         * case the waitStatus can be transiently and harmlessly wrong).
         */
        Node p = enq(node);
        int ws = p.waitStatus;
        if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL)) // 如果该结点的状态为cancel 或者修改waitStatus失败，则直接唤醒。
            LockSupport.unpark(node.thread);
        return true;
    }

可以看到，正常情况 ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL) 这个判断是不会为true的，所以，不会在这个时候唤醒该线程。


只有到发送signal信号的线程调用reentrantLock.unlock()后因为它已经被加到AQS的等待队列中，所以才会被唤醒。


总结：


     本文从代码的角度说明了Condition的实现方式，其中，涉及到了AQS的很多操作，比如AQS的等待队列实现独占锁功能，不过，这不是本文讨论的重点，等有机会再将AQS的实现单独分享出来。