Lock中的Condition源码解析

为什么要有condition及使用场景

查看condition接口里的方法有：
Lock中的Condition源码解析
而Object的方法有：

都说condition是对Object 的补充，那么到底是补充了什么？
Object的wait、notify是和synchronized关键字组合的，而condition是和Lock配合使用，不同的是同一个Lock可以有多个对应的condition来对线程做更细致的控制，而Object做不到这点，比如生产者和消费者的场景，以LinkedBlockingDueue双端阻塞队列为例，底层实现是一个ReentrantLock 和该锁对应的两个condition：
Lock中的Condition源码解析
生产线程往链表里放入元素后，会唤醒等待的消费线程，当消费线程从链表里消费元素时，同样会唤醒被阻塞的生产者线程。而如果使用Object是满足不了的。
综上总结一下，在对同一个共享资源（同一个锁）做竞争的线程里，如果这些线程有多个角色，并且又需要对多个角色的线程做更细致的控制，这时候就需要使用condition和Lock的组合。

关键API源码解析

这里重点看下condition的wait和signal方法：
我们使用最多的是AQS（如果不了解AQS是啥，可以看下我上一篇文章），所以这里以AQS里的实现源码来分析。首先还是了解下condition实现的思路，每个condition里维护了一个链表，用来存储等待的线程

public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
                //把当前线程包装成node，放到当前condition对象维护的链表尾部
            Node node = addConditionWaiter();
            //释放当前线程获得的锁，并唤醒等待的线程
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            //查看当前线程是否在同步队列里，如果在同步队列里，说明线程已经被阻塞，不在同步队列里的话，则需要阻塞线程
            //这里所说的同步队列就是当前condition实例所在的AQS实例的同步队列
            //如果一个线程获得了锁，那么这个线程会从同步队列里移除，代码见acquireQueued(final Node node, int arg)方法
            while (!isOnSyncQueue(node)) {
                //阻塞线程
                LockSupport.park(this);
                //检查node的waitStatus状态，如果线程在等待过程中被中断会抛出异常
                //因为正常被唤醒的Node的waitStatus为0，这个需要从AQS的release(int arg)的unparkSuccessor(Node node)里能看到
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            //当线程被唤醒 或者 线程本来就在同步队列里，则走到这里，会尝试竞争锁资源
            //线程走出acquireQueued()方法说明线程竞争到了锁，线程跳出阻塞状态的方式有两种，一种是被正常唤醒，一种是被打断。
            //acquireQueued方法返回true表明线程是被打断
            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;
            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);
        }
//主要逻辑就是把节点从condition的等待队列里拿出来放到lock的同步队列的尾部，让AQS来负责唤醒线程       
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;
    }

Lock中的Condition源码解析

为什么要有condition及使用场景

关键API源码解析

相关推荐