【并发编程】三：深入理解AbstractQueuedSynchronizer-独占锁的获取和释放源码分析

前言

回到在 【并发编程】一：java中的并发基础概念 留下的问题：Lock-Condition是如何解决可见性问题的？
我们知道synchronized是通过 happens-before原则中的 管程原则：对一个锁的解锁happens-before随后对这个锁的加锁。 为理论基础。 加锁的线程一定能看到解锁线程之前的所有的共享变量。
那么Lock-Condition同样是实现了MESA管程模型的锁 它的理论依据是什么？你可能已经想到它就是volatile关键字。JMM happens-before原则到volatile内存语义 再到内存语义的实现。
我们知道：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量 有了这个理论基础，并发大师Doug Lea很快就实现了JUC下面非常重要的一个锁：Lock-Condition!
那么他是如何实现的？不要急，我们先从它的底层同步队列AbstractQueuedSynchronizer说起！因为要搞懂Lock-Condition 就必须要彻底搞定AQS！因为Lock-Condition属于Higher Api 供开发者使用的。需要说明的是 AQS不仅仅是Lock-Condition的内部实现，还是JUC包下面的很多工具类的底层实现！所以 甚至可以这么说 不懂AQS你就不会JUC，夸张了各位大胸弟见谅！

需要说明的是本文基于JDK1.8 分析的，不同版本的代码实现是不一样的，但差别不会很大。

AQS中的链表

通过【并发编程】一：java中的并发基础概念的管程模型可以知道 管程就是使用了几个队列来完成并发程序的两大难题：互斥和 同步！
通过MESA管程模型我们知道：互斥和同步都是通过队列来实现的。互斥是通过阻塞队列，同步是通过条件等待队列！而AQS就是对阻塞队列和条件等待队列的标准实现。

代码实现：

 static final  class Node {
    //共享锁 
    static final Node SHARED = new Node();
    //独占锁
    static final Node EXCLUSIVE = null;
    //等待状态 有下面CANCELLED，SIGNAL，CONDITION，PROPAGATE这几个值
    volatile int waitStatus;
    //前置节点
    volatile Node prev;
    //后置节点
    volatile Node next;
    //等待的线程
    volatile Thread thread;
    //下一个等待者
    Node nextWaiter;    
     /**
     * 由于在同步队列中等待的线程 等待超时或者被中断，需要从同步队列中取消等待 节点进入该状态将不会变化
     */
    static final int CANCELLED =  1;
    /**
     * 后续节点处在等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后继节点，使后继节点的线程得以运行
     */
    static final int SIGNAL    = -1;
    /**
     * 节点在等待队列中，节点线程等待在condition上，当其他线程对condition调用了 signal()方法后，该节点将会
     * 从等待队列中转移到同步队列中。加入到对同步状态的获取中。
     */
    static final int CONDITION = -2;
    /**
     * 表示下一次共享式同步状态的获取将会无条件的被传播下去
     */
    static final int PROPAGATE = -3;
  }   

上面的Node类是AQS里面的内部内，很明显 是一个双向队列，AQS拥有一个head和tail节点的引用。
值得说明的是：nextWaiter和next有什么区别？nextWaiter保存的是共享锁或者独占锁的对象，如果是独占锁 该值为null。next链表的下一个节点。两者没有任何关系，只不过名字起的有点鸡肋。

AQS 独占锁的获取

lock.lock();
write();
lock.unlock();

我们使用类似上述的代码就能保证临界资源的互斥访问。我们进入lock的lock()方法，会发现内部正是由 AQS的acquire()方法提供支持。
该方法主要逻辑在条件表达式里面。

 public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg)){
      selfInterrupt();
    }
  }

主要分为三个逻辑：一：尝试获取同步状态 二：获取失败加入阻塞队列 三：在阻塞队列中等待 分别对应 三个方法：tryAcquire，addWaiter和acquireQueued

尝试获取同步状态 tryAcquire

tryAcquire方法是子类必须要实现的方法。以ReentrantLock为例。为了

protected final boolean tryAcquire(int acquires) {
	final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
      //这里使用CAS设置同步状态是因为 在这个分支中会出现多个线程争抢设置同步状态
       if (!hasQueuedPredecessors() &&
           compareAndSetState(0, acquires)) {
           setExclusiveOwnerThread(current);
           return true;
       }
    }
    else if (current == getExclusiveOwnerThread()) {
       int nextc = c + acquires;
       if (nextc < 0)
           throw new Error("Maximum lock count exceeded");
      //这里直接设置 因为上面已经判断 当前线程已经获取了同步状态 所以这里是安全的     
       setState(nextc);
       return true;
    }
    return false;
 }

• 如果同步状态是0 说明是可以尝试获取的。获取之前需要满足一个条件 hasQueuedPredecessors() 为false。那么这个方法是干嘛的？稍后再说
• 如果同步状态不为0 说明已经有线程获取了同步状态 这种情况下 只需要判断 获取同步状态的线程是不是当前线程。
• 还要注意tryAcquire方法有对同步状态的获取和更改，同步状态是volatile修饰的。

hasQueuedPredecessors方法作用是判断前面有没有等待的线程。如果有等待的线程当前线程就不应该 再获取同步状态。如果没有 才可继续获取同步状态。

进入hasQueuedPredecessors方法：

 public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

上面这个方法看是很简单 没有几行代码 实则不然。

第一个条件 h != t 如果 条件成立 能说明以下问题：

• 队列不为空 至少有一个虚节点（这里的虚节点就是没有任何信息的节点 在文章下面可以看到）
• 如果只有一个虚节点没有后继节点 也就是 head 为虚节点 tail还没有值（这个情况可能是 有一个线程正在假如到阻塞队列 并且已经构建了一个虚节点 设置给head了 但是tail没有来得及设置）
• 队列除了虚节点 还有后继节点

再看第二个条件 (s = h.next) == null || s.thread != Thread.currentThread()

• (s = h.next) == null 如果成立 说明上面第一个条件的第二种情况存在。有一个线程正在构造节点 加如阻塞队列 那这个时候会返回true 代表前面已经有线程等待了。
• 相反 如果 条件(s = h.next) == null 不成立 条件s.thread != Thread.currentThread()成立，含义为头结点后面的节点 不是当前线程！那么也说明有人在前面排队返回true

获取同步状态失败的线程加入阻塞队列addWaiter

没有设置成功同步状态的线程就继续进入到addWaiter这个方法。

 //mode 是Node.EXCLUSIVE独占锁 这个是一个Null值。
 private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
      //将自己的前置节点 设置为 当前队列的尾节点
      node.prev = pred;
      //这里使用cas设置尾节点 如果有线程执行成功了 那么此时的 pred节点已经变化了 这里也就设置不成了。
      if (compareAndSetTail(pred, node)) {
        pred.next = node;
        return node;
      }
    }
    //走到这里 要么尾节点为null 要么cas没有成功
    enq(node);
    //更新尾节点成功返回 当前节点
    return node;
  }

跟进 enq方法

private Node enq(final Node node) {
    //因为竞争锁失败 所以使用死循环来保证 竞争失败就必须要加入到阻塞队列中 只有加入成功 才能从死循环中返回
    for (;;) {
      Node t = tail;
      if (t == null) { // Must initialize
        //尾节点为null  设置一个头结点 这个过程中可能CAS设置失败 失败就再来一次循环 直到成功
        if (compareAndSetHead(new Node())){
        //设置头结点成功 将尾节点赋值给头节点 因为此时队列中只有一个节点
        //可以试想一下这一步操作会不会有线程安全问题？假如CAS成功 别的线程同时更新了尾节点 
        //再把头结点的值赋值给尾节点会不会有问题？肯定是不会有问题的
          tail = head;
        }
      } else {
        //线程走到这个分支 有两种可能 
        //1，尾节点不为null  
        //2，下面的compareAndSetTail(t, node) 设置失败
        node.prev = t;
        //尝试使用cas更新 尾节点 如果更新失败继续循环更新
        if (compareAndSetTail(t, node)) {
          t.next = node;
          return t;
        }
      }
    }
  }

上面两个方法是将竞争同步状态失败的线程 放入AQS的过程！有很详细的注释。

上面提到 tail = head;这行代码为什么是合理的？有人会想就这样把head赋值给 tail了 那万一 tail和head变了怎么办？但是要注意的是 到这行代码 tail 目前还是null 如果有线程要改tail的值 那么这个线程肯定会进入CAS设置head的值，那么肯定会失败、再次进入循环、只要tail=head不复值完成 其余的线程就只能无效的死循环。

这样就把一个线程构造成一个节点加入了等待队列。

在阻塞队列中排队 acquireQueued

上图上 如果只是简单的将线程构造成一个队列的节点放入队列中 那么线程执行完 if的条件判断一定是会向下走的，这样就达不到互斥的目的了。所以acquireQueued方法一定是让节点中的线程自旋或者是休眠，才能阻塞住当前竞争失败的线程！
我们继续看acquireQueued方法

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
      boolean interrupted = false;
      //所以 进入同步队列的线程 一开始是在自旋 检查自己前面的节点是否是头节点 如果是 尝试获取同步状态
      for (;;) {
        //获取前置节点
        final Node p = node.predecessor();
        //如果前置节点是头结点 则尝试获取同步状态
        //为什么 自己的前驱节点是头结点要获取同步状态？每个线程都在自省 再死循环中自省
        //当头结点释放同步状态的时候 后续节点才能自然的醒过来。
        if (p == head && tryAcquire(arg)) {
          //如果获取成功 设置自己所在节点为 头节点 这里设置不存在线程安全问题 同一时刻只能有一个线程 能成功获取
          setHead(node);
          //头节点的next节点引用置空
          p.next = null;
          failed = false;
          //如果自旋获取了同步状态 介绍自旋 代码继续向下执行
          return interrupted;
        }
        //检查线程是否需要parking 
        //如果检查shouldParkAfterFailedAcquire需要停顿 那么parkAndCheckInterrupt 会执行park并且返回线程的是否被打断
        if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt()){
          //如果线程被中断并不会从同步队列中返回 
          //会再次尝试获取同步状态 还是和之前的流程是一样 只不过标记了当前线程是被中断了的。
          //以便acquire方法获取到同步状态之后 设置自己被中断selfInterrupt()
          interrupted = true;
        }
      }
    } finally {
      //这里的条件判断不注意会有点想不明白 failed字段只有在获取同步状态的时候才会被设置为false 并且也之后获取到同步状态之后
      //那么是不是走到这里的代码是不是就永远不可能为null？不见得
      //想来想去 只有异常才能到达这里 例如我们在predecessor节点的时候 有一个NullPointerException
      //再tryAcquire方法的时候也可能会发生异常 因为这个完全是用户自定义的方法。
      if (failed){
        cancelAcquire(node);
      }
    }
  }

• 进入队列的线程如果自己的前置节点是头结点 会再一次获取同步状态，成功则返回！
• 获取同步状态失败 检查自己是否能休眠（能休眠的条件是前置节点的等待状态是SIGNAL，前面说了等待状态为SIGNAL的线程 后续节点是处于等待状态，并且当前节点释放同步状态之后会通知后续节点）
• 如果线程在休眠的过程中 被中断了 只是标记一下中断状态 继续获取同步状态 获取不到 继续休眠 直到线程获取到同步状态成功返回 for循环了 也只是设置一下当前线程的中断状态，至于是否中断 在acquire方法中是不予理会的。

到此 一个线程就被放入了阻塞队列并且该线程最终会调用LockSupport的park方法进行阻塞。等待head节点的线程叫醒自己。

AQS 独占锁的释放

假如一开始就从下面的tryAcquire方法中获取到了同步状态，或者线程被head节点的线程叫醒。执行完临界代码之后就需要释放同步状态。

//该方法实现摘自 ReentrantLock 释放同步状态 主要就是对同步状态state的操作
@Override
protected boolean tryRelease(int releases) {
 int c = getState() - releases;
 //如果独占线程不是自己 就抛一个异常
 if (Thread.currentThread() != getExclusiveOwnerThread())
   throw new IllegalMonitorStateException();
 //能执行下面的代码 说明 当前线程持有同步状态   
 boolean free = false;
 if (c == 0) {
   free = true;
   setExclusiveOwnerThread(null);
 }
//这里不需要CAS设置同步状态
 setState(c);
 return free;
}

下面是AQS提供的释放同步状态的方法，tryRelease 由子类实现具体的操作同步状态state，可以参考上面的代码。

    public final boolean release(int arg) {
        //尝试释放同步状态 
        if (tryRelease(arg)) {
            Node h = head;
            //释放完同步状态之后 如果头结点不为null 就叫醒后续的节点
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

最终叫醒线程的操作是在unparkSuccessor 方法中。

private void unparkSuccessor(Node node) {
       int ws = node.waitStatus;
       if (ws < 0)
           compareAndSetWaitStatus(node, ws, 0);
       Node s = node.next;
       //下面的代码即为找到 下一个需要叫醒的节点
       if (s == null || s.waitStatus > 0) {
           s = null;
           //注意这里是 从后往前找 大家可以想一下为什么要从后往前找
           for (Node t = tail; t != null && t != node; t = t.prev)
               if (t.waitStatus <= 0)
                   s = t;
       }
       if (s != null)
           //最终还是使用LockSupport的unpark来叫醒节点上的线程
           LockSupport.unpark(s.thread);
    }

释放逻辑和前面获取同步状态的代码呼应。最为重要的就是对同步状态的操作。

//获取同步状态
compareAndSetState(0, acquires) //对volatile变量的读取和写入操作
LoadStore Barriers //读volatile变量后面插入LoadStore 和LoadLoad 屏障
LoadLoad Barriers
.
.
.
同步代码块.....
.
.
.
//释放同步状态
StoreStore Barriers  //写前面插入 StoreStore屏障
setState(c)   //对volatile变量的写入操作  
StoreLoad Barriers //写前面插入 StoreLoad屏障

那么回到我们之前的问题 Lock是如何解决内存可见性问题的，对照【并发编程】二：volatile的特性以及内存语义及实现分析 一目了然。同步代码块的共享变量在执行setState之前全部刷新到主内存中。

总结

独占锁的获取和释放源码分析就到这。Lock-Condition实现了MESA管程模型，而对管程的实现就是AQS，同时同步状态state保证了线程的可见性。