Condition 源码解析

文章目录

Condition 源码解析
- 一、Condition
- 二、Condition 源码解读
- - 2.1. lock.newCondition() 获取 Condition 对象
  - 2.2. condition.await() 阻塞过程
  - 2.3. condition.signal() 唤醒过程
  - 2.4. condition.await() 被唤醒后
- 三、总结

一、Condition

在并发情况下进行线程间的协调，如果是使用的 synchronized 锁，我们可以使用 wait()/notify() 进行唤醒，如果是使用的 Lock 锁的方式，则可以使用 Condition 进行针对性的阻塞和唤醒，相较于 wait()/notify() 使用起来更灵活。那么 Condition 是如何实现线程的等待和唤醒的呢，本文通过解析Condition 的源码进行理解。

在进行源码分析前，先通过一个案例看下 Condition 是如何使用的

public class Test {

    public synchronized static void main(String[] args) throws InterruptedException {
        Lock lock = new ReentrantLock();
        Condition condition = lock.newCondition();

        new Thread(() -> {
            lock.lock();
            System.out.println("线程1开始等待！");
            try {
                condition.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("线程1被唤醒继续执行结束！");
            lock.unlock();
        }, "1").start();

        new Thread(() -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            lock.lock();
            System.out.println("开始唤醒线程！");
            condition.signal();
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("线程2执行结束！");
            lock.unlock();
        }, "2").start();
    }
}

运行之后，可以看到下面日志：
在这里插入图片描述

由于在第一个线程中，使用的 condition.await() 因此当前线程会被阻塞挂起，而第二个线程，在 1s 后进行了 condition.signal() 操作，因此第一个线程会被唤醒继续执行。这里可以发现，第一个线程阻塞时锁并没有释放，而第二个线程在1s后也成功拿到锁了，所以表明在 condition.await() 时会自动释放当前锁，这点和 wait() 相同，在第二个线程进行了 condition.signal() 操作，第一个线程并没有继续向下执行，而是等待第二个线程处理完才会继续执行，由此可以表明被唤醒的线程会重新获取锁，成功获取锁后继续执行。

下面通过源码看下 Condition 是如何实现的等待唤醒。

二、Condition 源码解读

2.1. lock.newCondition() 获取 Condition 对象

首先看下在使用 lock.newCondition() 获取一个Condition 对象时，具体做了什么，这里以 ReentrantLock 为例，进入到 ReentrantLock 的 newCondition() 方法中，又执行了 Sync 的 newCondition() 方法，再进去就会发现其实是 new 了一个 ConditionObject 类对象：
在这里插入图片描述

下面点到这个类中，可以看到其实是 AQS 下的一个子类：
在这里插入图片描述

2.2. condition.await() 阻塞过程

了解到 Condition 的对象后，可以看到是 AQS 下的一个子类，那下面其他的方法也肯定依赖于 AQS ，下面看下 condition.await() 方法，点到 await() 方法中：

在这里插入图片描述

其中 addConditionWaiter() 则是将自己加入到 AQS的队列中，并获取到当前线程所在的 Node ，这里注意下 Node 的状态是 Node.CONDITION 也就是 -2，后面会依赖于该状态。

在这里插入图片描述

再回到 await() 方法继续向下看，接着使用了 fullyRelease() 方法传入了当前的 Node ，这里的 fullyRelease() 方法主要做了释放当前线程锁的操作，可以看到又调用了 AQS 的 release() 进行释放资源，也就是释放了当前所持有的锁。
在这里插入图片描述

回到 await() 方法中，当释放锁后，下面进入到了 while 循环中，通过查看 isOnSyncQueue() 方法，可以看到是符合while的条件也就可以进入到循环中：
在这里插入图片描述

在循环中可以明显的看到 LockSupport.park(this) ，将当前线程进行了阻塞。

2.3. condition.signal() 唤醒过程

上面已经看到线程被阻塞了，如果需要被唤醒则需要通过condition.signal()，这个方法是如何唤醒的呢？

下面来到 AbstractQueuedSynchronizer 类的 signal() 方法中：
在这里插入图片描述

主要执行了 doSignal() 方法，再点到 doSignal() 中，可以看到这里开启了一个循环，对链表的每一个元素都进行了 transferForSignal() 操作，这里也比较好理解，就是要唤醒等待中的线程。

在这里插入图片描述

下面点到 transferForSignal() 中，看下对每个 Node 都做了什么操作。点进去之后也比较好理解，如果状态是 Node.CONDITION 也就是 -2，刚才在解读 await() 方法时就提到这个状态了，这里正好形成了呼应，下面有个非常显眼的操作 LockSupport.unpark(node.thread) 直接唤醒了目标线程。也就是唤醒了 2.2 中的最后一步操作。

在这里插入图片描述