今天打算写一下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的实现单独分享出来。