AQS同步队列、条件队列源码解析

前言

在分析 Java 并发包 java.util.concurrent 源码的时候，少不了需要了解 AbstractQueuedSynchronizer（以下简写AQS）这个抽象类，因为它是 Java 并发包的基础工具类，是实现 ReentrantLock、CountDownLatch、Semaphore、FutureTask 等类的基础。

AQS几个重要的内部属性

字段

//共享变量，使用volatile修饰保证线程可见性
private volatile int state;

// 头结点，你直接把它当做 当前持有锁的线程 可能是最好理解的
private transient volatile Node head;

// 阻塞的尾节点，每个新的节点进来，都插入到最后，也就形成了一个链表
private transient volatile Node tail;

// 代表当前持有独占锁的线程，举个最重要的使用例子，因为锁可以重入
// reentrantLock.lock()可以嵌套调用多次，所以每次用这个来判断当前线程是否已经拥有了锁
// if (currentThread == getExclusiveOwnerThread()) {state++}
private transient Thread exclusiveOwnerThread; //继承自AbstractOwnableSynchronizer

state 是用来记录同步状态的一个重要属性。在不同的AQS实现类上，往往有不同的含义。但是，总体有那么两种作用。

• 共享锁：state的值代表着该临界资源的数量。如 ：打印机的数量是2，state =2,那么最多允许同时打印两份文件。换算到线程中，就意味着，最多有 state 个线程同时进入。
• 独占锁：对于独占锁而言，以state的初始值并不是1，而是0。这是因为在独占锁中，这个值的含义代表着重入次数，每重入一次加一，但值为0时，意味着这个这个临界资源并未被抢占。

内部类 Node

static final class Node {
   
   
    // 标识节点当前在共享模式下
    static final Node SHARED = new Node();
    // 标识节点当前在独占模式下
    static final Node EXCLUSIVE = null;

    // ======== 下面的几个int常量是给waitStatus用的 ===========
    /** waitStatus value to indicate thread has cancelled */
    // 代码此线程取消了争抢这个锁
    static final int CANCELLED =  1;
    /** waitStatus value to indicate successor's thread needs unparking */
    // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒或者说可以被唤醒
    static final int SIGNAL    = -1;
    /** waitStatus value to indicate thread is waiting on condition */
    // 条件队列标识
    static final int CONDITION = -2;
    /**
     * waitStatus value to indicate the next acquireShared should
     * unconditionally propagate
     */
    // 同样的不分析，略过吧
    static final int PROPAGATE = -3;
    // =====================================================


    // 取值为上面的1、-1、-2、-3，或者0(以后会讲到)
    // 这么理解，暂时只需要知道如果这个值 大于0 代表此线程取消了等待，
    //    ps: 半天抢不到锁，不抢了，ReentrantLock是可以指定timeouot的。。。
    volatile int waitStatus;
    // 前驱节点的引用
    volatile Node prev;
    // 后继节点的引用
    volatile Node next;
    // 这个就是线程本尊
    volatile Thread thread;
    //链接到等待条件或特殊值SHARED的下一个节点。即为，用于链接条件队列的指针
	Node nextWaiter;

}

Node 的数据结构其实也挺简单的，就是 thread + waitStatus + pre + next + nextWaiter 五个属性而已，大家先要有这个概念在心里。

同步队列 | 阻塞队列

在多个线程竞争有限资源的情况下，一定会出现部分线程 得不到资源，即陷入阻塞状态。那么对于这些阻塞的线程，AQS会使用一个队列组织起来，用于后续线程的唤醒。这个队列就是CLH队列（Craig,Landin,and Hagersten），一个虚拟的双向链表（这个为什么形容为虚拟的有兴趣可以自己去了解一下），而队列的每一个节点就是一个Node节点,记录了阻塞线程的信息。

阻塞队列不包含 head 节点, head这个节点在逻辑上代表着 占有锁的这个节点

等待队列 | 条件队列

如何说同步队列是线程想要获取锁失败而入队的，那么条件队列就是已经获取到锁，但是没有满足某种条件而主动阻塞的。而这种情况的阻塞不是因为竞争锁而导致的，那么放在同步队列就不合适了。于是，引申出了条件队列，条件队列是一个单向链表
Condition 经常可以用在生产者-消费者的场景中,这里以 ReentrantLock 举例.

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

class BoundedBuffer {
   
   
   final Lock lock = new ReentrantLock();
   // condition 依赖于 lock 来产生
   final Condition notFull = lock.newCondition();
   final Condition notEmpty = lock.newCondition();

   final Object[] items = new Object[100];
   int putptr, takeptr, count;

   // 生产
   public void put(Object x) throws InterruptedException {
   
   
       lock.lock();
       try {
   
   
           while (count == items.length)
               notFull.await();  // 队列已满，等待，直到 not full 才能继续生产
           items[putptr] = x;
           if (++putptr == items.length) putptr = 0;
           ++count;
           notEmpty.signal(); // 生产成功，队列已经 not empty 了，发个通知出去
       } finally {
   
   
           lock.unlock();
       }
   }

   // 消费
   public Object take() throws InterruptedException {
   
   
       lock.lock();
       try {
   
   
           while (count == 0)
               notEmpty.await(); // 队列为空，等待，直到队列 not empty，才能继续消费
           Object x = items[takeptr];
           if (++takeptr == items.length) takeptr = 0;
           --count;
           notFull.signal(); // 被我消费掉一个，队列 not full 了，发个通知出去
           return x;
       } finally {
   
   
           lock.unlock();
       }
   }
}

await() 方法会释放锁

是的，有一条线指向了同步队列，这是因为，当条件队列的条件满足时，线程理论上就可以继续执行了，但是需要重新获取锁。

condition 是依赖于 ReentrantLock 的，不管是调用 await 进入等待还是 signal 唤醒，都必须获取到锁才能进行操作。

重要方法执行链

同步队列的获取、阻塞、唤醒

ReentrantLock 在内部用了内部类 Sync 来管理锁，所以真正的获取锁和释放锁是由 Sync 的实现类来控制的。Sync 有两个实现，分别为 NonfairSync（非公平锁）和 FairSync（公平锁），我们看 FairSync 部分。

加锁代码流程

static final class FairSync extends Sync {
   
   
    private static final long serialVersionUID = -3000897897090466540L;
      // 争锁
    final void lock() {
   
   
        acquire(1);
    }
      // 来自父类AQS，我直接贴过来这边，下面分析的时候同样会这样做，不会给读者带来阅读压力
    // 我们看到，这个方法，如果tryAcquire(arg) 返回true, 也就结束了。
    // 否则，acquireQueued方法会将线程压到队列中
    public final void acquire(int arg) {
   
    // 此时 arg == 1
        // 首先调用tryAcquire(1)一下，名字上就知道，这个只是试一试
        // 因为有可能直接就成功了呢，也就不需要进队列排队了，
        // 对于公平锁的语义就是：本来就没人持有锁，根本没必要进队列等待(又是挂起，又是等待被唤醒的)
        if (!tryAcquire(arg) &&
            // tryAcquire(arg)没有成功，这个时候需要把当前线程挂起，放到阻塞队列中。
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
   
   
              selfInterrupt();
        }
    }

    /**
     * Fair version of tryAcquire.  Don't grant access unless
     * recursive call or no waiters or is first.
     */
    // 尝试直接获取锁，返回值是boolean，代表是否获取到锁
    // 返回true：1.没有线程在等待锁；2.重入锁，线程本来就持有锁，也就可以理所当然可以直接获取
    protected final boolean tryAcquire(int acquires) {
   
   
        final Thread current = Thread.currentThread();
        int c = getState();
        // state == 0 此时此刻没有线程持有锁
        if (c == 0) {
   
   
            // 虽然此时此刻锁是可以用的，但是这是公平锁，既然是公平，就得讲究先来后到，
            // 看看有没有别人在队列中等了半天了
            if (!hasQueuedPredecessors() &&
                // 如果没有线程在等待，那就用CAS尝试一下，成功了就获取到锁了，
                // 不成功的话，只能说明一个问题，就在刚刚几乎同一时刻有个线程抢先了 =_=
                // 因为刚刚还没人的，我判断过了
                compareAndSetState(0, acquires)) {
   
   

                // 到这里就是获取到锁了，标记一下，告诉大家，现在是我占用了锁
                setExclusiveOwnerThread(current);
                return true;
            }
        }
          // 会进入这个else if分支，说明是重入了，需要操作：state=st