通过前面三篇的分析, 我们深入了解了 AbstractQueuedSynchronizer 的内部结构和一些设计理念, 知道了 AbstractQueuedSynchronizer 内部维护了一个同步状态和两个排队区, 这两个排队区分别是同步队列和条件队列我们还是拿公共厕所做比喻, 同步队列是主要的排队区, 如果公共厕所没开放, 所有想要进入厕所的人都得在这里排队而条件队列主要是为条件等待设置的, 我们想象一下如果一个人通过排队终于成功获取锁进入了厕所, 但在方便之前发现自己没带手纸, 碰到这种情况虽然很无奈, 但是它也必须接受这个事实, 这时它只好乖乖的出去先准备好手纸 (进入条件队列等待), 当然在出去之前还得把锁给释放了好让其他人能够进来, 在准备好了手纸(条件满足) 之后它又得重新回到同步队列中去排队当然进入房间的人并不都是因为没带手纸, 可能还有其他一些原因必须中断操作先去条件队列中去排队, 所以条件队列可以有多个, 依不同的等待条件而设置不同的条件队列条件队列是一条单向链表, Condition 接口定义了条件队列中的所有操作, AbstractQueuedSynchronizer 内部的 ConditionObject 类实现了 Condition 接口, 下面我们看看 Condition 接口都定义了哪些操作
- public interface Condition {
- // 响应线程中断的条件等待
- void await() throws InterruptedException;
- // 不响应线程中断的条件等待
- void awaitUninterruptibly();
- // 设置相对时间的条件等待(不进行自旋)
- long awaitNanos(long nanosTimeout) throws InterruptedException;
- // 设置相对时间的条件等待(进行自旋)
- boolean await(long time, TimeUnit unit) throws InterruptedException;
- // 设置绝对时间的条件等待
- boolean awaitUntil(Date deadline) throws InterruptedException;
- // 唤醒条件队列中的头结点
- void signal();
- // 唤醒条件队列的所有结点
- void signalAll();
- }
Condition 接口虽然定义了这么多方法, 但总共就分为两类, 以 await 开头的是线程进入条件队列等待的方法, 以 signal 开头的是将条件队列中的线程唤醒的方法这里要注意的是, 调用 signal 方法可能唤醒线程也可能不会唤醒线程, 什么时候会唤醒线程这得看情况, 后面会讲到, 但是调用 signal 方法一定会将线程从条件队列中移到同步队列尾部这里为了叙述方便, 我们先暂时不纠结这么多, 统一称 signal 方法为唤醒条件队列线程的操作大家注意看一下, await 方法分为 5 种, 分别是响应线程中断等待, 不响应线程中断等待, 设置相对时间不自旋等待, 设置相对时间自旋等待, 设置绝对时间等待; signal 方法只有 2 种, 分别是只唤醒条件队列头结点和唤醒条件队列所有结点的操作同一类的方法基本上是相通的, 由于篇幅所限, 我们不可能也不需要将这些方法全部仔细的讲到, 只需要将一个代表方法搞懂了再看其他方法就能够触类旁通所以在本文中我只会细讲 await 方法和 signal 方法, 其他方法不细讲但会贴出源码来以供大家参考
1. 响应线程中断的条件等待
- // 响应线程中断的条件等待
- public final void await() throws InterruptedException {
- // 如果线程被中断则抛出异常
- if (Thread.interrupted()) {
- throw new InterruptedException();
- }
- // 将当前线程添加到条件队列尾部
- Node node = addConditionWaiter();
- // 在进入条件等待之前先完全释放锁
- int savedState = fullyRelease(node);
- int interruptMode = 0;
- // 线程一直在 while 循环里进行条件等待
- while (!isOnSyncQueue(node)) {
- // 进行条件等待的线程都在这里被挂起, 线程被唤醒的情况有以下几种:
- //1. 同步队列的前继结点已取消
- //2. 设置同步队列的前继结点的状态为 SIGNAL 失败
- //3. 前继结点释放锁后唤醒当前结点
- //4. 由于 LockSupport.park(this)能够响应中断, 所以线程中断后也会醒来
- LockSupport.park(this);
- // 当前线程醒来后立马检查是否被中断, 如果是则代表结点取消条件等待, 此时需要将结点移出条件队列
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) {
- break;
- }
- }
- // 线程醒来后就会以独占模式获取锁
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE) {
- interruptMode = REINTERRUPT;
- }
- // 这步操作主要为防止线程在 signal 之前中断而导致没与条件队列断绝联系
- if (node.nextWaiter != null) {
- unlinkCancelledWaiters();
- }
- // 根据中断模式进行响应的中断处理
- if (interruptMode != 0) {
- reportInterruptAfterWait(interruptMode);
- }
- }
await 方法是经常使用到的方法, 调用该方法会将当前线程阻塞到条件队列中, 直到等待的条件满足后才会被唤醒, 在调用 signal 方法唤醒前, 这整个过程是可以响应线程中断的, 如果线程收到中断请求就会立刻结束 while 循环接下来我们详细的分析整个的流程
第一步: 添加结点到条件队列
- // 添加结点到条件队列尾部
- private Node addConditionWaiter() {
- // 获取条件队列的尾结点的引用
- Node t = lastWaiter;
- // 检查条件队列中是否存在已取消的结点
- if (t != null && t.waitStatus != Node.CONDITION) {
- // 清除条件队列中所有取消条件等待的结点
- unlinkCancelledWaiters();
- t = lastWaiter;
- }
- // 将当前线程包装成结点, 等待状态设置为 CONDITION
- Node node = new Node(Thread.currentThread(), Node.CONDITION);
- // 将新的结点添加到条件队列尾部
- if (t == null) {
- firstWaiter = node;
- } else {
- t.nextWaiter = node;
- }
- // 更新尾结点引用
- lastWaiter = node;
- return node;
- }
- // 清除条件队列中所有取消条件等待的结点
- private void unlinkCancelledWaiters() {
- Node t = firstWaiter;
- Node trail = null;
- // 从前向后遍历条件队列
- while (t != null) {
- Node next = t.nextWaiter;
- // 如果等待状态不是 CONDITION
- if (t.waitStatus != Node.CONDITION) {
- //1. 将当前结点的后继结点引用置空
- t.nextWaiter = null;
- if (trail == null) {
- //2. 前继结点的后继结点指向当前结点的后继结点
- firstWaiter = next;
- } else {
- //2. 前继结点的后继结点指向当前结点的后继结点
- trail.nextWaiter = next;
- }
- // 这里表明已经到达了尾结点
- if (next == null) {
- // 更新尾结点引用
- lastWaiter = trail;
- }
- } else {
- // 如果状态为 CONDITION 就更新追踪结点的引用
- trail = t;
- }
- // 指向下一个结点
- t = next;
- }
- }
当线程调用 await 方法的时候, 首先会将当前线程包装成 node 结点放入条件队列尾部在 addConditionWaiter 方法中, 如果发现条件队列尾结点已取消就会调用 unlinkCancelledWaiters 方法将条件队列所有的已取消结点清空这步操作是插入结点的准备工作, 那么确保了尾结点的状态也是 CONDITION 之后, 就会新建一个 node 结点将当前线程包装起来然后放入条件队列尾部注意, 这个过程只是将结点添加到同步队列尾部而没有挂起线程哦
第二步: 完全将锁释放
- // 完全释放锁
- final int fullyRelease(Node node) {
- boolean failed = true;
- try {
- // 获取当前的同步状态
- int savedState = getState();
- // 使用当前的同步状态去释放锁
- if (release(savedState)) {
- failed = false;
- // 如果释放锁成功就返回当前同步状态
- return savedState;
- } else {
- // 如果释放锁失败就抛出运行时异常
- throw new IllegalMonitorStateException();
- }
- } finally {
- // 保证没有成功释放锁就将该结点设置为取消状态
- if (failed) {
- node.waitStatus = Node.CANCELLED;
- }
- }
- }
将当前线程包装成结点添加到条件队列尾部后, 紧接着就调用 fullyRelease 方法释放锁注意, 方法名为 fullyRelease 也就这步操作会完全的释放锁, 因为锁是可重入的, 所以在进行条件等待前需要将锁全部释放了, 不然的话别人就获取不了锁了如果释放锁失败的话就会抛出一个运行时异常, 如果成功释放了锁的话就返回之前的同步状态
第三步: 进行条件等待
- // 线程一直在 while 循环里进行条件等待
- while (!isOnSyncQueue(node)) {
- // 进行条件等待的线程都在这里被挂起, 线程被唤醒的情况有以下几种:
- //1. 同步队列的前继结点已取消
- //2. 设置同步队列的前继结点的状态为 SIGNAL 失败
- //3. 前继结点释放锁后唤醒当前结点
- //4. 由于 LockSupport.park(this)能够响应中断, 所以线程中断后也会醒来
- LockSupport.park(this);
- // 当前线程醒来后立马检查是否被中断, 如果是则代表结点取消条件等待, 此时需要将结点移出条件队列
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) {
- break;
- }
- }
- // 检查条件等待时的线程中断情况
- private int checkInterruptWhileWaiting(Node node) {
- // 中断请求在 signal 操作之前: THROW_IE
- // 中断请求在 signal 操作之后: REINTERRUPT
- // 期间没有收到任何中断请求: 0
- return Thread.interrupted() ? (transferAfterCancelledWait(node) ? THROW_IE: REINTERRUPT) : 0;
- }
- // 将取消条件等待的结点从条件队列转移到同步队列中
- final boolean transferAfterCancelledWait(Node node) {
- // 如果这步 CAS 操作成功的话就表明中断发生在 signal 方法之前
- if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
- // 状态修改成功后就将该结点放入同步队列尾部
- enq(node);
- return true;
- }
- // 到这里表明 CAS 操作失败, 说明中断发生在 signal 方法之后
- while (!isOnSyncQueue(node)) {
- // 如果 sinal 方法还没有将结点转移到同步队列, 就通过自旋等待一下
- Thread.yield();
- }
- return false;
- }
在以上两个操作完成了之后就会进入 while 循环, 可以看到 while 循环里面首先调用 LockSupport.park(this)将线程挂起了, 所以线程就会一直在这里阻塞在调用 signal 方法后仅仅只是将结点从条件队列转移到同步队列中去, 至于会不会唤醒线程需要看情况如果转移结点时发现同步队列中的前继结点已取消, 或者是更新前继结点的状态为 SIGNAL 失败, 这两种情况都会立即唤醒线程, 否则的话在 signal 方法结束时就不会去唤醒已在同步队列中的线程, 而是等到它的前继结点来唤醒当然, 线程阻塞在这里除了可以调用 signal 方法唤醒之外, 线程还可以响应中断, 如果线程在这里收到中断请求就会继续往下执行可以看到线程醒来后会马上检查是否是由于中断唤醒的还是通过 signal 方法唤醒的, 如果是因为中断唤醒的同样会将这个结点转移到同步队列中去, 只不过是通过调用 transferAfterCancelledWait 方法来实现的最后执行完这一步之后就会返回中断情况并跳出 while 循环
第四步: 结点移出条件队列后的操作
- // 线程醒来后就会以独占模式获取锁
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE) {
- interruptMode = REINTERRUPT;
- }
- // 这步操作主要为防止线程在 signal 之前中断而导致没与条件队列断绝联系
- if (node.nextWaiter != null) {
- unlinkCancelledWaiters();
- }
- // 根据中断模式进行响应的中断处理
- if (interruptMode != 0) {
- reportInterruptAfterWait(interruptMode);
- }
- // 结束条件等待后根据中断情况做出相应处理
- private void reportInterruptAfterWait(int interruptMode) throws InterruptedException {
- // 如果中断模式是 THROW_IE 就抛出异常
- if (interruptMode == THROW_IE) {
- throw new InterruptedException();
- // 如果中断模式是 REINTERRUPT 就自己挂起
- } else if (interruptMode == REINTERRUPT) {
- selfInterrupt();
- }
- }
当线程终止了 while 循环也就是条件等待后, 就会回到同步队列中不管是因为调用 signal 方法回去的还是因为线程中断导致的, 结点最终都会在同步队列中这时就会调用 acquireQueued 方法执行在同步队列中获取锁的操作, 这个方法我们在独占模式这一篇已经详细的讲过也就是说, 结点从条件队列出来后又是乖乖的走独占模式下获取锁的那一套, 等这个结点再次获得锁之后, 就会调用 reportInterruptAfterWait 方法来根据这期间的中断情况做出相应的响应如果中断发生在 signal 方法之前, interruptMode 就为 THROW_IE, 再次获得锁后就抛出异常; 如果中断发生在 signal 方法之后, interruptMode 就为 REINTERRUPT, 再次获得锁后就重新中断
2. 不响应线程中断的条件等待
- // 不响应线程中断的条件等待
- public final void awaitUninterruptibly() {
- // 将当前线程添加到条件队列尾部
- Node node = addConditionWaiter();
- // 完全释放锁并返回当前同步状态
- int savedState = fullyRelease(node);
- boolean interrupted = false;
- // 结点一直在 while 循环里进行条件等待
- while (!isOnSyncQueue(node)) {
- // 条件队列中所有的线程都在这里被挂起
- LockSupport.park(this);
- // 线程醒来发现中断并不会马上去响应
- if (Thread.interrupted()) {
- interrupted = true;
- }
- }
- if (acquireQueued(node, savedState) || interrupted) {
- // 在这里响应所有中断请求, 满足以下两个条件之一就会将自己挂起
- //1. 线程在条件等待时收到中断请求
- //2. 线程在 acquireQueued 方法里收到中断请求
- selfInterrupt();
- }
- }
3. 设置相对时间的条件等待(不进行自旋)
- // 设置定时条件等待(相对时间), 不进行自旋等待
- public final long awaitNanos(long nanosTimeout) throws InterruptedException {
- // 如果线程被中断则抛出异常
- if (Thread.interrupted()) {
- throw new InterruptedException();
- }
- // 将当前线程添加到条件队列尾部
- Node node = addConditionWaiter();
- // 在进入条件等待之前先完全释放锁
- int savedState = fullyRelease(node);
- long lastTime = System.nanoTime();
- int interruptMode = 0;
- while (!isOnSyncQueue(node)) {
- // 判断超时时间是否用完了
- if (nanosTimeout <= 0L) {
- // 如果已超时就需要执行取消条件等待操作
- transferAfterCancelledWait(node);
- break;
- }
- // 将当前线程挂起一段时间, 线程在这期间可能被唤醒, 也可能自己醒来
- LockSupport.parkNanos(this, nanosTimeout);
- // 线程醒来后先检查中断信息
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) {
- break;
- }
- long now = System.nanoTime();
- // 超时时间每次减去条件等待的时间
- nanosTimeout -= now - lastTime;
- lastTime = now;
- }
- // 线程醒来后就会以独占模式获取锁
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE) {
- interruptMode = REINTERRUPT;
- }
- // 由于 transferAfterCancelledWait 方法没有把 nextWaiter 置空, 所有这里要再清理一遍
- if (node.nextWaiter != null) {
- unlinkCancelledWaiters();
- }
- // 根据中断模式进行响应的中断处理
- if (interruptMode != 0) {
- reportInterruptAfterWait(interruptMode);
- }
- // 返回剩余时间
- return nanosTimeout - (System.nanoTime() - lastTime);
- }
4. 设置相对时间的条件等待(进行自旋)
- // 设置定时条件等待(相对时间), 进行自旋等待
- public final boolean await(long time, TimeUnit unit) throws InterruptedException {
- if (unit == null) {
- throw new NullPointerException();
- }
- // 获取超时时间的毫秒数
- long nanosTimeout = unit.toNanos(time);
- // 如果线程被中断则抛出异常
- if (Thread.interrupted()) {
- throw new InterruptedException();
- }
- // 将当前线程添加条件队列尾部
- Node node = addConditionWaiter();
- // 在进入条件等待之前先完全释放锁
- int savedState = fullyRelease(node);
- // 获取当前时间的毫秒数
- long lastTime = System.nanoTime();
- boolean timedout = false;
- int interruptMode = 0;
- while (!isOnSyncQueue(node)) {
- // 如果超时就需要执行取消条件等待操作
- if (nanosTimeout <= 0L) {
- timedout = transferAfterCancelledWait(node);
- break;
- }
- // 如果超时时间大于自旋时间, 就将线程挂起一段时间
- if (nanosTimeout >= spinForTimeoutThreshold) {
- LockSupport.parkNanos(this, nanosTimeout);
- }
- // 线程醒来后先检查中断信息
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) {
- break;
- }
- long now = System.nanoTime();
- // 超时时间每次减去条件等待的时间
- nanosTimeout -= now - lastTime;
- lastTime = now;
- }
- // 线程醒来后就会以独占模式获取锁
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE) {
- interruptMode = REINTERRUPT;
- }
- // 由于 transferAfterCancelledWait 方法没有把 nextWaiter 置空, 所有这里要再清理一遍
- if (node.nextWaiter != null) {
- unlinkCancelledWaiters();
- }
- // 根据中断模式进行响应的中断处理
- if (interruptMode != 0) {
- reportInterruptAfterWait(interruptMode);
- }
- // 返回是否超时标志
- return ! timedout;
- }
5. 设置绝对时间的条件等待
- // 设置定时条件等待(绝对时间)
- public final boolean awaitUntil(Date deadline) throws InterruptedException {
- if (deadline == null) {
- throw new NullPointerException();
- }
- // 获取绝对时间的毫秒数
- long abstime = deadline.getTime();
- // 如果线程被中断则抛出异常
- if (Thread.interrupted()) {
- throw new InterruptedException();
- }
- // 将当前线程添加到条件队列尾部
- Node node = addConditionWaiter();
- // 在进入条件等待之前先完全释放锁
- int savedState = fullyRelease(node);
- boolean timedout = false;
- int interruptMode = 0;
- while (!isOnSyncQueue(node)) {
- // 如果超时就需要执行取消条件等待操作
- if (System.currentTimeMillis() > abstime) {
- timedout = transferAfterCancelledWait(node);
- break;
- }
- // 将线程挂起一段时间, 期间线程可能被唤醒, 也可能到了点自己醒来
- LockSupport.parkUntil(this, abstime);
- // 线程醒来后先检查中断信息
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) {
- break;
- }
- }
- // 线程醒来后就会以独占模式获取锁
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE) {
- interruptMode = REINTERRUPT;
- }
- // 由于 transferAfterCancelledWait 方法没有把 nextWaiter 置空, 所有这里要再清理一遍
- if (node.nextWaiter != null) {
- unlinkCancelledWaiters();
- }
- // 根据中断模式进行响应的中断处理
- if (interruptMode != 0) {
- reportInterruptAfterWait(interruptMode);
- }
- // 返回是否超时标志
- return ! timedout;
- }
6. 唤醒条件队列中的头结点
- // 唤醒条件队列中的下一个结点
- public final void signal() {
- // 判断当前线程是否持有锁
- if (!isHeldExclusively()) {
- throw new IllegalMonitorStateException();
- }
- Node first = firstWaiter;
- // 如果条件队列中有排队者
- if (first != null) {
- // 唤醒条件队列中的头结点
- doSignal(first);
- }
- }
- // 唤醒条件队列中的头结点
- private void doSignal(Node first) {
- do {
- //1. 将 firstWaiter 引用向后移动一位
- if ((firstWaiter = first.nextWaiter) == null) {
- lastWaiter = null;
- }
- //2. 将头结点的后继结点引用置空
- first.nextWaiter = null;
- //3. 将头结点转移到同步队列, 转移完成后有可能唤醒线程
- //4. 如果 transferForSignal 操作失败就去唤醒下一个结点
- } while (! transferForSignal ( first ) && (first = firstWaiter) != null);
- }
- // 将指定结点从条件队列转移到同步队列中
- final boolean transferForSignal(Node node) {
- // 将等待状态从 CONDITION 设置为 0
- if (!compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
- // 如果更新状态的操作失败就直接返回 false
- // 可能是 transferAfterCancelledWait 方法先将状态改变了, 导致这步 CAS 操作失败
- return false;
- }
- // 将该结点添加到同步队列尾部
- Node p = enq(node);
- int ws = p.waitStatus;
- if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL)) {
- // 出现以下情况就会唤醒当前线程
- //1. 前继结点是取消状态
- //2. 更新前继结点的状态为 SIGNAL 操作失败
- LockSupport.unpark(node.thread);
- }
- return true;
- }
可以看到 signal 方法最终的核心就是去调用 transferForSignal 方法, 在 transferForSignal 方法中首先会用 CAS 操作将结点的状态从 CONDITION 设置为 0, 然后再调用 enq 方法将该结点添加到同步队列尾部我们再看到接下来的 if 判断语句, 这个判断语句主要是用来判断什么时候会去唤醒线程, 出现这两种情况就会立即唤醒线程, 一种是当发现前继结点的状态是取消状态时, 还有一种是更新前继结点的状态失败时这两种情况都会马上去唤醒线程, 否则的话就仅仅只是将结点从条件队列中转移到同步队列中就完了, 而不会立马去唤醒结点中的线程 signalAll 方法也大致类似, 只不过它是去循环遍历条件队列中的所有结点, 并将它们转移到同步队列, 转移结点的方法也还是调用 transferForSignal 方法
7. 唤醒条件队列的所有结点
- // 唤醒条件队列后面的全部结点
- public final void signalAll() {
- // 判断当前线程是否持有锁
- if (!isHeldExclusively()) {
- throw new IllegalMonitorStateException();
- }
- // 获取条件队列头结点
- Node first = firstWaiter;
- if (first != null) {
- // 唤醒条件队列的所有结点
- doSignalAll(first);
- }
- }
- // 唤醒条件队列的所有结点
- private void doSignalAll(Node first) {
- // 先把头结点和尾结点的引用置空
- lastWaiter = firstWaiter = null;
- do {
- // 先获取后继结点的引用
- Node next = first.nextWaiter;
- // 把即将转移的结点的后继引用置空
- first.nextWaiter = null;
- // 将结点从条件队列转移到同步队列
- transferForSignal(first);
- // 将引用指向下一个结点
- first = next;
- } while ( first != null );
- }
至此, 我们整个的 AbstractQueuedSynchronizer 源码分析就结束了, 相信通过这四篇的分析, 大家能更好的掌握并理解 AQS 这个类确实很重要, 因为它是其他很多同步类的基石, 由于笔者水平和表达能力有限, 如果哪些地方没有表述清楚的, 或者理解不到位的, 还请广大读者们能够及时指正, 共同探讨学习可在下方留言阅读中所遇到的问题, 如果有需要 AQS 注释源码的也可联系笔者索取
注: 以上全部分析基于 JDK1.7, 不同版本间会有差异, 读者需要注意
来源: https://www.cnblogs.com/liuyun1995/p/8416340.html