引子
前文《面试必考AQS-AQS源码全局分析》已经对AQS中对于共享 锁的申请与释放流程进行了总结。而对于申请与释放,在AQS中提现的是与锁并无关系,而是针对同步队列的操作,向同步队列中添加、移除Node实例对象,操作Node中的线程对象。而我们日常使用的锁类,只是表象,何时可以加锁、解锁,达到何种条件才算加锁成功、解锁成功,这才是AQS锁实现的功能。接下来将从源码层面看一下,共享锁的申请与释放在AQS中具体是怎样实现的。
共享锁的申请
再看一次申请流程的大致方法调用:
public final void acquireShared(int arg) {...} // 获取共享锁的入口
# protected int tryAcquireShared(int arg); // 尝试获取共享锁
private void doAcquireShared(int arg) {...} // AQS中获取共享锁流程整合
private Node addWaiter(Node mode){...} // 将node加入到同步队列的尾部
# protected int tryAcquireShared(int arg); // 尝试获取共享锁
private void setHeadAndPropagate(Node node, int propagate) {...} // 设置 同步队列的head节点,以及触发"传播"操作
# private void doReleaseShared() {...} // 遍历同步队列,调整节点状态,唤醒待申请节点
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {...} // 如果获取锁失败,则整理队中节点状态,并判断是否要将线程挂起
private final boolean parkAndCheckInterrupt() {...} // 将线程挂起,并在挂起被唤醒后检查是否要中断线程(返回是否中断)
private void cancelAcquire(Node node) {...} // 取消当前节点获取排它锁,将其从同步队列中移除
从入口方法acquireShared()开始分析:
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
就两步,先让子类尝试获取共享锁,如果结果小于0,进入AQS逻辑。小于0应该就是获取锁失败,这里要注意,共享锁只有在当前存在排它锁时,才会申请失败,那么就要进入同步队列再找机会申请锁了。
private void doAcquireShared(int arg) {
final Node node = addWaiter(Node.SHARED); // addWaiter()前文有介绍,这里不展开,注意这里是SHARED类型的节点
boolean failed = true; // 同样一个状态标识,goto t1
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor(); // 获取前置节点
if (p == head) { // 如果为head节点
int r = tryAcquireShared(arg); // 尝试申请共享锁
if (r >= 0) { // 申请成功
setHeadAndPropagate(node, r); // goto t2
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed) // t1,是否操作取消节点
cancelAcquire(node);
}
}
// t2,设置节点nodde为head
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
// 这部分找时间详细分析
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
可以看到doAcquireShared()中的流程,与申请同步锁时的流程基本一致。值得注意的是,共享锁是允许在同一时刻多个线程同时持有的。而这个处理在AQS中并没有涉及到,因为AQS只负责同步队列的处理以达到同步的目的,因此应该是在子类中实现的。
共享锁的释放
再看一次释放流程的大致方法调用:
public final boolean releaseShared(int arg) {...} // 释放共享锁的入口
# protected boolean tryReleaseShared(int arg); // 尝试释放共享锁
private void doReleaseShared() {...} // 遍历同步队列,调整节点状态,唤醒待申请节点
还是从入口方法分析:
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
套路一样,先由子类尝试释放锁,如果成功了执行doReleaseShared();否则按释放失败处理。
private void doReleaseShared() {
for (;;) { // 循环
Node h = head;
if (h != null && h != tail) { // 如果head节点不为空并且不等于尾结点tail
int ws = h.waitStatus;
if (ws == Node.SIGNAL) { // 如果状态为SIGNAL,说明有后继节点等待被唤醒
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) // 将head节点状态重置为0
continue; // 如果重置失败,for(;;)再次尝试;t3
unparkSuccessor(h); // 唤醒h的后继节点,前文有分析
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE)) // 如果head状态已经为0,并且设置PROPAGATE失败,继续for(;;) t4
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
以上就是释放共享锁的流程,大致流程比较简单。
但注意,t3和t4位置,为何会CAS操作失败,只可能是有其他操作已经改变了节点状态,有可能head节点已经变化了,再次进行for(;;)校验状态及处理。
整个for(;;)结束的方式 ,只能是h==head(在执行整段逻辑后,head节点没有易主),这也是前面遇到各种CAS操作失败后,必须重新进入for(;;)的原因。
以上都是点心,下面才是主菜!
传播状态(PROPAGATE)
我们在t4位置,遇到了一个节点状态 PROPAGATE(传播),而上文在申请共享锁时,在某种条件下调用了doReleaseShared()方法,间接的也执行了t4位置的代码,为何申请锁也要调用释放锁的逻辑?doReleaseShared()方法有什么特别?
首先理解,为何申请锁的流程也要调用释放锁的逻辑:
在doReleaseShared()方法中,当head节点状态等于SIGNAL时,会唤醒后继节点,在释放共享锁场景下,前面释放后面唤醒很好理解,要注意的是,共享锁的特点是可以多个线程同时持有的。那么当一个线程申请共享锁成功后,必然是可以告知其他等待申请的线程,可以去申请了,那么主动调用一次doReleaseShared()很合理,也能让同步队列中的等待的节点尽快申请到锁。
doReleaseShared()方法有什么特别:
在doReleaseShared()方法中,涉及到PROPAGATE状态的设置compareAndSetWaitStatus(h, 0, Node.PROPAGATE);
在申请共享锁成功时,调用setHeadAndPropagate(Node node, int propagate)方法,如果满足if (s == null || s.isShared()),就会导致调用了在doReleaseShared(),也就间接设置了PROPAGATE状态。
PROPAGATE状态有什么特别:
在AQS中搜索PROPAGATE,一共涉及三个方法,分别是:doReleaseShared()、setHeadAndPropagate()以及shouldParkAfterFailedAcquire()。前两个方法已经介绍过了,最终调用的是doReleaseShared()中的compareAndSetWaitStatus(h, 0, Node.PROPAGATE),目的是将节点状态变更为PROPAGATE。
别急,再看一下doReleaseShared()方法:
private void doReleaseShared() {
for (;;) { // 循环
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
if (h == head)
break;
}
}
这里要明确三点:
- unparkSuccessor()方法的执行条件是ws==SIGNAL
- compareAndSetWaitStatus(h, 0, Node.PROPAGATE)方法的执行条件是ws==0
- 很关键的代码是if (h == head)break; 只有head没有发生变化,循环才会结束。
我们不要忘了,unparkSuccessor()的作用是让后继节点去申请锁,那么一旦申请成功,head就会发生变化;但是当这种情况下新的head产生后,又没有新node入队,那么新的head的状态ws==0就是成立的。
综上可得出一个临界状态,旧的head释放锁时,触发后继节点申请锁,并且申请成功,成为了新的head',并且此刻head'没有后继节点,head'==tail,此时可以执行到第2步。
那么!compareAndSetWaitStatus(h, 0, Node.PROPAGATE)成立的条件又是什么?自然是head'的状态ws!=0,什么时候不等于0,当然是又有新节点入队,改变ws为SIGNAL。
这样就会执行continue;继续下一次循环。而此时的head'状态又满足第1步,也就是会去唤醒后继节点。
是不是很晕,其实目的只有一个,找出一切可能的情况,去通知后继节点干活,去最大可能的尝试获取锁。
再结合上面设置PROPAGATE状态的位置,一是当申请到了共享锁,需要唤醒后面节点同样去申请;二是释放了锁,需要唤醒后面节点去申请。没错,的确是为了唤醒后继节点让它申请锁。
这就会产生一个问题,同一时刻,可能会有多个线程同时调用了doReleaseShared()方法,但是没关系doReleaseShared()方法中采用CAS操作去改变节点状态,不会有问题。
我们来看看另一个涉及到PROPAGATE状态的方法shouldParkAfterFailedAcquire()中做了哪些事情:
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL); // t5
}
return false;
}
在t5位置,看到将节点状态变更为SIGNAL,结合上面代码可知,节点状态ws,
- 如果为SIGNAL,则直接返回true
- 如果为CANCEL,则清理同步队列
- 剩下状态为0或PROPAGATE(CONDITION状态不在这里考虑),那么就是将0或PROPAGATE的状态设置为SIGNAL
前面doReleaseShared()->unparkSuccessor()的流程以及让节点状态ws==SIGNAL了,那么情况1的思路就清晰了:被唤醒的节点再次尝试申请锁失败后,经历ws==SIGNAL状态判断后,继续挂起。
但是情况3是在何种场景下被执行呢?
回看:
else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
前面分析,ws==0和!compareAndSetWaitStatus(h, 0, Node.PROPAGATE) 是两个矛盾的场景,只有当判断完ws==0后,立即有节点入队,才会导致后面compareAndSetWaitStatus(h, 0, Node.PROPAGATE)执行失败,但如果执行成功,就是说明没有新节点入队,这就会导致head节点的状态由0变更为PROPAGATE。
我们有提到过:
同一时刻,可能会有多个线程同时调用了doReleaseShared()方法
那么,在这个前提下,可能有一种情况是,一个线程在操作head释放锁,并执行compareAndSetWaitStatus(h, 0, Node.PROPAGATE) 成功了,节点状态变为了PROPAGATE;另一个线程在申请锁,并且pred==head,将会导致 pred.waitStatus==PROPAGATE,那么compareAndSetWaitStatus(pred, ws, Node.SIGNAL); 的含义就明白了,申请锁的线程申请失败,需要再次被挂起,那么需要恢复前置节点pred的状态为SIGNAL,标记为存在后继节点等待被唤醒!
这就是传播状态存在的意义。关键点临界状态的判定,以及最大限度的唤醒后继节点去申请锁。
尾声
在AQS中共享锁的申请与释放流程不难理解,难点在于共享锁申请与释放期间,“传播状态”存在的意义。为何要在节点状态中加入“传播”这个状态;在分析完AQS源码后,要全局的去理解它,分析每一个模块存在的意义,因为其中没有任何一行冗余代码。
推荐阅读: