面试必考AQS-共享锁的申请与释放，传播状态

引子

前文《面试必考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;
	}
}

这里要明确三点：

1. unparkSuccessor()方法的执行条件是ws==SIGNAL
2. compareAndSetWaitStatus(h, 0, Node.PROPAGATE)方法的执行条件是ws==0
3. 很关键的代码是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，

1. 如果为SIGNAL，则直接返回true
2. 如果为CANCEL，则清理同步队列
3. 剩下状态为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源码后，要全局的去理解它，分析每一个模块存在的意义，因为其中没有任何一行冗余代码。

推荐阅读：

面试必考AQS-AQS概览

面试必考AQS-AQS源码全局分析

面试必考AQS-排它锁的申请与释放

面试必考AQS-共享锁申请、释放及传播状态

面试必考AQS-await和signal的实现原理