手撕AQS之Condition

最新推荐文章于 2023-05-17 10:00:00 发布

荆轲刺秦

最新推荐文章于 2023-05-17 10:00:00 发布

阅读量196

点赞数

分类专栏：一知半解Java源码系列文章标签： java lock condition

本文链接：https://blog.csdn.net/ai_xao/article/details/106162988

版权

一知半解Java源码系列专栏收录该内容

17 篇文章 1 订阅

订阅专栏

Condition 的使用接触最多是在 ReentrantLock，讲 AQS 到这里应该就完结了，前两篇文章理了下 AQS 的共享锁模式和独立锁模式，这篇在理下其中 Condition 的原理。

我在第一篇手撕AQS之共享锁有提到同步操作的本质，大概遵循以下流程：

持有锁；
操作共享资源；
释放锁；

无论是使用共享或者独占锁，都无法在持有锁的中途将锁让出，并继续等待着获取锁。这就像使用 synchronized 同步对象一样，但 synchronized 可以利用被同步对象的 wait 方法让出锁，当该对象的 notify 被调用时，它又能重新竞争锁。所以，使用 ReentrantLock 怎样实现这个呢？AQS 中实现了 Condition 接口的 ConditionObject 类能够帮助我们做到。

整体思想：ConditionObject 维护了条件队列，当调用 await 时，将创建 node 并加入该条件队列，当 signal 时，node 会从条件队列取出，加入 CLH 队列（这在前两篇文章中有讲），这和之前的逻辑并无两样。那现在，我们来看看关键的 await 和 signal 。

await:

		public final void await() throws InterruptedException {
            // 首先检查线程是否中断
            if (Thread.interrupted())
                throw new InterruptedException();
            // 创建 node 节点，添加到队尾
            Node node = addConditionWaiter();
            // 1.释放状态值，并保存曾持有的状态值
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            // 2.该节点不处于非同步队列，暂停线程
            while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            // 3.请求入CLH 队列
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

释放状态值，并保存曾持有的状态值，目的是为了在重新获得锁后，恢复曾持有的状态值：

	final int fullyRelease(Node node) {
        boolean failed = true;
        try {
            int savedState = getState();
            // 真正的释放锁，会在方法内调用子类的实现
            if (release(savedState)) {
                failed = false;
                return savedState;
            } else {
                // 这就是为什么调用 await 方法必须要获取到锁的原因
                throw new IllegalMonitorStateException();
            }
        } finally {
            // 失败的话，通过该状态值，该节点能够从队列中移除
            if (failed)
                node.waitStatus = Node.CANCELLED;
        }
    }

该节点不处于同步队列（CLH 队列），暂停线程：

	final boolean isOnSyncQueue(Node node) {
        // 还是属于条件队列(prev可以是非空的，但不足以判断其在队列上，因为把它放在队列上的CAS可能会失败。)
        if (node.waitStatus == Node.CONDITION || node.prev == null)
            return false;
        // 进入同步队列，会为该成员赋值，条件队列是通过 `nextWaiter` 成员维护的
        if (node.next != null) // If has successor, it must be on queue
            return true;
        // 能到这里，这个节点基本在队列尾部
        return findNodeFromTail(node);
    }

	// 从同步队列循环查找该节点，如果存在，则返回 true
	private boolean findNodeFromTail(Node node) {
        Node t = tail;
        for (;;) {
            if (t == node)
                return true;
            if (t == null)
                return false;
            t = t.prev;
        }
    }

请求入CLH 队列，这就和手撕AQS之独占锁模式中的一样了。

signal:

		public final void signal() {
            // 调用该方法的线程必须持有锁
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            // 通知等待最长的节点
            Node first = firstWaiter;
            if (first != null)
                doSignal(first);
        }
		private void doSignal(Node first) {
            do {
                // 从队列中移除该节点，并将它的下一节点放置队头
                if ( (firstWaiter = first.nextWaiter) == null)
                    lastWaiter = null;
                first.nextWaiter = null;
            } while (!transferForSignal(first) &&
                     (first = firstWaiter) != null);
        }

transferForSignal 方法能够转变该节点的状态，并入同步队列：

	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))
            LockSupport.unpark(node.thread);
        return true;
    }

文档说的很清楚，我就保留了。需要解释的是为什么前继节点的 waitStatus 为取消或者将前继节点的 waitStatus 设置为 SIGNAL 失败，需要唤醒当前线程？成功的话，就将前继节点更新为 SIGNAL ，这是需要的，失败的话，会重新执行下面这个 await 方法中的循环：

			while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
			private int checkInterruptWhileWaiting(Node node) {
            	return Thread.interrupted() ?
                	(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
                	0;
        	}
			final boolean transferAfterCancelledWait(Node node) {
                // 上面这种情况这里会失败掉。
        		if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
            		enq(node);
            		return true;
        		}
        		/*
         		* If we lost out to a signal(), then we can't proceed
         		* until it finishes its enq().  Cancelling during an
         		* incomplete transfer is both rare and transient, so just
         		* spin.
         		*/
        		while (!isOnSyncQueue(node))
	            	Thread.yield();
    	    	return false;
    		}

在最后带来的影响也就是它跳出循环，进入竞争锁的阶段，在这个阶段，还是有可能被阻塞。

只要进入同步队列，就有机会被唤醒，然后在 await 方法中能够结束：

			// 3.请求入CLH 队列
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);

如果是在同步队列中唤醒该线程（与上面介绍的错误流程到这里是不同的），也会进入到这里，尝试再次请求（acquireQueued），成功的话，就可以结束了，之前的线程就能恢复执行了。

总结：

这里比较绕的一个点就是线程恢复执行的问题。举个列子，现在有线程A 调用 await 方法阻塞了，那么它 park 的位置在 await 方法里，如果线程 A 调用 lock 方法阻塞了，那么它最后的 park 位置在 acquireQueued 方法里调用的 parkAndCheckInterrupt 方法。而 await 被唤醒，会从 await 中结束掉，进入 acquireQueued方法，如果最后没有获取到锁，仍然会进入 parkAndCheckInterrupt 方法里 park。这是比较重要的一个点，需要理解清楚！

还有两个困惑点：

signal 中并没有释放锁的操作，那么在执行这个方法以后，await 方法还是不能结束的，因为它没有获取到锁。

这是对的，之前，我一直认为，signal 会附带释放锁的操作，这样 await 方法就能够获取到锁，然后执行了。其实，仔细想想，如果这样的话，那 signal 方法内是不是也需要 park，那不就也需要唤醒嘛，这不就陷入循环啦？
signal 是如何确保一定能够通知到 await 那个线程，并帮助它获得锁？

举个例子，a 线程调用了 signal 方法，它只是帮助调用 await 方法的 b 线程进入同步队列，至于 b 线程能不能获得锁，其实是和 a 线程的调用没有关系的！也就是说不能确认b线程在 a 线程最终释放了锁，就立刻能够获取锁，并执行，signal 方法只是帮助它进入同步队列，让它竞争锁，但不能保证一定是它。
await 的超时方法，在时间到期后，能够返回执行线程嘛？
还是不能的，时间到期以后，仍然需要入同步队列，获取到锁，才能正常返回；但可以通过返回值来判断到底有没有超时。

我与风来

认认真真学习，做思想的产出者，而不是文字的搬运工
错误之处，还望指出