多线程之美5一 AbstractQueuedSynchronizer源码分析<一>

AQS的源码分析 <一>

目录结构

1、什么是CAS ?

2、同步器类结构

3、CLH同步队列

4、AQS中静态内部类Node

5、方法分析

​ 5.1、acquire(int arg )

​ 5.2、release(int arg) 释放锁

6、总结

前言

在多线程环境下，我们一般会对临界区资源（共享资源）进行加锁,释放锁，保证同一时刻最多只有一个线程（独占模式），就如去公共厕所里，在使用一个小房间时会加锁避免自己在使用的时候，别人突然闯进来一样，引起不必要的麻烦，在使用完后，再打开锁，其他人才可使用；还有生产者消费者模型中，线程之间要同步，需要等待和通知机制，来协调线程合作。那么这些是这么实现的？如可重入锁ReentrantLock, 读写锁ReadWriteLock, 信号量 Semaphore, 计数器CountDownLatch，这些都会涉及线程之间的协调同步，那么会有一个抽象的结构，将这些需要共用的功能抽离出来，统一来满足要求吗？我们一起来看看AbstractQueuedSynchronizer 这个抽象类，如何来实现这些功能和其设计的巧妙, 我们能看到Doug lea 大佬在很多地方使用的循环CAS操作(自旋锁)。

1、什么是CAS ?

CAS 即 compare and swap 比较并交换， 涉及到三个参数，内存值V, 预期值A, 要修改的新值B, 拿着预期值A与内存值V比较，相等则符合预期，将内存值V更新为B, 否则不相等，不能更新V;

比如我想去果篮拿1个苹果，我预期篮子是5个，而果篮中实际有2个，被其他人早已偷偷吃了几个我还不知道！于是我的期望值5与果篮值实际2不符，那么我就不能更新篮子的苹果数量了。这和数据库中乐观锁机制一样。后面我想用一篇文章单独总结一下CAS, 如它存在的ABA问题以及加上版本号来解决ABA问题， 还有用CAS实现自旋锁等。

2、同步器类结构

public abstract class AbstractQueuedSynchronizer  extends AbstractOwnableSynchronizer

AbstractQueuedSynchronizer （以后简称AQS）是一个抽象类，定义了一些通用功能以及子类需要根据自身特性重写实现的方法，有两个内部类 Node和ConditionObject, 以及2个链表结构的队列，一个是双向链表的同步队列，用来存放尝试获取锁，却未获取到锁需等待的线程，另一个是单向链表的条件队列，用来存放某些线程已经获取到锁了，为了等待某些事件（如IO事件,mq消息等）主动放弃锁挂起等待条件的线程。

这里主要分析2个方法，分别是独占式获取锁 acquire, 释放锁release。

// 独占模式 EXCLUSIVE
acquire(int arg)
release(int arg)
// 共享模式 SHARED
acquireShared(int arg)
releaseShared(int arg)

3、CLH同步队列

AQS 内部持有一个双向链表的队列（CLH队列，也称线程同步队列，用来存储尝试获取锁，未获取到等待的线程），AQS 持有head, tail节点，以及资源同步状态state 属性, 来表示有限的锁资源占用情况。

注：Head节点是一个空节点，是不关联线程的，因为Head节点表示当前已经占用资源在使用的线程，该线程已经不需要等待锁，在同步队列中作占位作用，它只是一个标志节点，其他线程才是对锁资源有需求，在队列中等待的，慢慢看来，后面代码会更有理解。

双向链表结构如下图：

public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer
    implements java.io.Serializable {
    /**
     * 等待队列中的头节点，懒初始化，如果头节点存在，表示当前正在占用锁资源的线程。                
     *
     */
    private transient volatile Node head;

    /**
     * 等待队列中尾节点
     */
    private transient volatile Node tail;

    /**
     * 同步状态,在独占模式下 state=0,表示锁空闲，可获取,state =1,则表示被其他线程占用，需等待
     * 就如火车上的厕所，绿灯表示可用，红灯表示里面有人，需要等待
     */
    private volatile int state;

4、AQS中静态内部类Node

CLH双向链表中每个node 中有关联的线程，节点状态信息，以及节点的前后指针，每个属性有volatile修饰，可保证多线程之间的可见性。

static final class Node {
    // 获取锁的模式分为独占式和共享式
        static final Node SHARED = new Node();
       
       //独占式
        static final Node EXCLUSIVE = null;
   
  // 以下是节点在等待队列中的5种状态，初始为0，即waitStatus的值

        static final int CANCELLED =  1;
  
        static final int SIGNAL    = -1;

        static final int CONDITION = -2;
  
        static final int PROPAGATE = -3;

// 以下4个属性分别用volatile修饰，保证多线程之间可见性
 
 //节点的状态
        volatile int waitStatus;
   //前置节点
        volatile Node prev;
  // 后置节点
        volatile Node next;
 // 节点关联的线程
        volatile Thread thread;

Node中在队列中的等待状态 waitStatus,初始为0，还有以下4种状态和其含义：

• SIGNAL: waitStatus= -1,表示当前节点线程在使用完同步资源，释放资源后，需要去唤醒后面的一个节点中的线程。
• CANCELLED：waitStatus= 1，节点在循环尝试获取锁资源失败，被中断了，就不再需要再在队列中等待资源了，需要执行节点出队操作，将该节点移出该队列。就如一群小伙伴都在排队等待领取免费的辣条呢，都要排到小名了， 突然被妈妈叫着回去吃饭了，被强行中断了，那就要移出队列，让给其他人了哦。
• PROPAGATE：waitStatus= -3, 该状态是共享模式下，如CountDownLatch等实现同步时，可有多个线程同时获取锁资源，在独占模式下，锁资源有限，只有1个，一次最多有一个线程获取到锁资源，共享模式下，锁资源可有多个，可有多个线程同时获取到锁，如果锁资源数量可足够下一个节点中线程使用，会继续唤醒下一个。
• CONDITION：waitStatus= -2，表示在Condition条件等待队列中。

5、方法分析

5.1、acquire(int arg )

锁资源只有1个，同一时刻最多只有一个线程可获取到锁，独占式获取锁，其他未获取到锁的线程需在同步队列中等待。

 public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
          //如果在等待过程中，线程被标记中断了，响应中断
            selfInterrupt();
    }

变形为：

 public final void acquire(int arg) {
      boolean ta = tryAcquire(arg)
      if(!ta) {
        Node  aw = addWaiter(Node.EXCLUSIVE);
        boolean isInterrupt = acquireQueued(aw,arg);
        if(isInterrupt) {
          //如果在等待过程中，线程被标记中断了，响应中断
            selfInterrupt();
        }
      }
 }

1. tryAcquire(arg)： 尝试去获取锁资源，具体怎样获取锁由每个子类实现，AQS不做处理，统一抛出 throw new UnsupportedOperationException() 异常；

2. addWaiter(Node.EXCLUSIVE)：如果尝试获取锁失败，将该线程封装到一个新node节点中,添加到等待队列中

3. acquireQueued(node, arg) ：如果在head节点后，再次尝试去获取锁，可能占用锁的线程已经释放资源了，如果再次获取失败，在队列中寻找到安全位置（告知前置节点，使用完资源唤醒一下自己）后，则在队列中挂起，等待被唤醒，返回布尔类型，表示线程是否被中断。

下面来分别查看以上3个方法的源码：

1）tryAcquire() 是尝试去获取锁，需要每个具体实现类去实现，默认抛出异常

 protected boolean tryAcquire(int arg) {
    //抛出不支持操作异常
        throw new UnsupportedOperationException();
    }

来看看 ReentrantLock 是怎样实现 tryAcquire() 去获取锁的，ReentrantLock 有公平方式和非公平两种方式，这里简单看看非公平方式的实现细节。

protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }

内部调用nonfairTryAcquire 方法,代码如下：

  final boolean nonfairTryAcquire(int acquires) {
          //1,获取当前线程对象
            final Thread current = Thread.currentThread();
          //2,获取同步状态state
            int c = getState();
         //3, c为0表示锁可用，cas更新为1,compareAndSetState内部有unsafe类 调用本地方法（native修饰）执行原子更新操作，多个线程同时进来更新，只会有一个更新成功。更新成功就设置当前线程对象，用来标识当前线程拥有锁了，是有主的，其他线程在我没释放锁之前不可占用，也是用来支持可重入的。
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
              //4,如果当前线程等于当前已获取锁线程，可重入，同步状态 +1,返回true,允许再次获取锁
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

可重入锁 : 指线程在获取锁资源后，再次去获取同步锁，是允许再次获得的，不然存在产生死锁的风险，由上可知ReentrantLock 是支持可重入的，可重入多次，每重入一次 state +1，那么重入n 次，也需要释放n次（同理，每释放一次，state -1 ），不然state 无法恢复到到空闲状态0，导致其他线程无法获取到锁。

2）addWaiter(Node mode)，将当前线程封装为一个节点，添加到等待队列中。该方法分为2步操作，第一步利用CAS快速将节点入队，如果能入队成功，则返回，否则第二步执行 enq() 方法。

为什么？

为了执行效率和安全性两方面考虑，因在多线程环境下，同一时间可能并发执行多个线程，如果此时有2个线程都在执行入队操作，就有可能其中一个线程执行CAS 失败，他引用 的tail节点已经被更新，需要重新获取新的，此时就需要执行enq() 循环轮询去获取最新的tail节点执行入队操作，直到成功。

如图所示：

线程A在刚获取到pred = tail后，cpu调度切换到线程B，线程B此时也执行入队操作，入队成功，队列长度+1, tail更新，此时cpu调度 线程A，线程A再执行 compareAndSetTail(pred, node) 操作就会失败。

快速添加到队尾失败了，有两种情况，

1.是tail节点 为空，队列为空，那么需要初始化队列，添加一个空的head节点，表示当前已经获取锁资源，正在执行的线程。

2.是在cas添加到队尾后面时，有其他线程也在操作，抢先入队成功，导致自己获取的tail节点不是最新的，那就轮询获取最新的tail执行更新。

流程图如下：

addWaiter(Node mode) 代码如下：

    private Node addWaiter(Node mode) {
      /*1，创建 node节点,节点信息保存线程及模式
       * Node.EXCLUSIVE for exclusive 独占模式
       * Node.SHARED for shared 共享模式
       */
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
  //2,如果队尾节点不为空，尝试将节点添加到 tail后面，建立双向链接 
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
      //3,如果队尾节点为空，或者cas添加节点失败
        enq(node);
        return node;
    }

enq（node） 节点入队操作，for无限循环尝试去添加节点到队尾，直至成功。

private Node enq(final Node node) {
    for (;;) {
      //每新的一次循环，获取的是最新的tail，因tail节点是volatile修饰的，多线程之间内存可见，每次更新都会被刷新到内存
        Node t = tail;
        if (t == null) { // Must initialize
           //1，head节点是一个 node对象，但是没有绑定线程，表示当前已经获取到锁资源，正在执行的线程，此时首尾相同，会再次走一遍循环，添加当前节点到head节点后面
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
          //2,轮询去设置节点到队尾
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

boolean acquireQueued(final Node node, int arg) 返回线程是否被中断

在上一步方法将节点添加到同步队列后，执行该方法的目的是：

如果node的前置节点是head, 再次尝试一次获取锁资源，如果已经被释放了，那(线程)就去获取锁执行。如果不是头节点或者尝试获取锁资源失败，那就在队列找个位置挂起等待了 。

此时需要找一个安全点，确保前面的有效节点（没被取消的节点）的线程执行后，能够通知唤醒自己，当前节点线程才安心挂起等待。

流程图如下：

源代码如下：

  final boolean acquireQueued(final Node node, int arg) {
        //默认是失败
        boolean failed = true;
        try {
          //默认是没有被中断
            boolean interrupted = false;
          //无限循环
            for (;;) {
                final Node p = node.predecessor();
               //1，如果前置节点是head节点，再去尝试获取锁，如果获取成功了，则将自己更新为head，此时当前线程可以执行了。
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                   // 此时返回 false，没被中断
                    return interrupted;
                }
             //2,1失败或前置不是head,那么要定位一个有效的位置去阻塞等待，前面有些节点可能是被取消的，需要跳过这些节点，清除出队列，shouldParkAfterFailedAcquire就是来做这个事
                if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
                  //3,标记中断标记，返回被中断过 
                    interrupted = true;
            }
        } finally {
          // 4,正常情况下是一直会进行for循环，当跳出该循环，即出现异常，如被标记了中断，去调用阻塞，抛出中断异常,此时没有在队列中找到安全位置，因此将该节点移出队列
            if (failed)
                cancelAcquire(node);
        }
    }

shouldParkAfterFailedAcquire 在失败获取锁资源后，寻找可以安全挂起的位置

如果前置节点被取消，一直向前找到节点 ws<=0 为止,注意蓝色箭头，指向的前后指针还在，但是node1对象已经没有被引用，下次gc会被回收，则出队。

流程图如下：

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
       //1,前置节点已经是signal，在它释放资源后，会通知唤醒队列中下一个线程，所以当前位置就是安全阻塞等待点
            return true;
        if (ws > 0) {
          // ws> 0，前置节点被取消
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
      // 2,ws>0,那么就继续往前找，直到找到一个节点没被取消的,跳过了那些被取消的节点，这些节点后面会被GC   
            pred.next = node;
        } else {
          //3，尝试将前置节点 状态更新为signal,ws= -1, 进行下一次轮询
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

在找到安全位置后，挂起当前线程，等待被唤醒，如果下次被唤醒，首先检查一下自己是被前置节点唤醒 还是被中断唤醒的

 private final boolean parkAndCheckInterrupt() {
      // 挂起当前线程
        LockSupport.park(this);
       //当被唤醒，返回是否被中断标记位
        return Thread.interrupted();
    }

最后finally中，线程被中断，出现异常，取消节点；cancelAcquire(Node node) 将该节点移出等待队列，线程都被中断了，就不再

需要去等待锁资源了。

出队有三种情况:

• 1, 节点在队尾 ,等于tail

• 2, 节点在中间位置，既不在head后面，也不是tail

注： 我理解这里最终实现是要达到第3步的效果，但是在cancelAcquire方法里并没有更新第2步蓝色箭头的前置指针，而是留给了其他线程在获取锁资源时，执行shouldParkAfterFailedAcquire方法查找安全位置挂起来实现的，这时 node 将没有再被引用，因此会被GC。

• 3, 被取消节点在head的后面，第二个节点

  这里唯一做的就是去唤醒 node 的后继节点（如果为没被取消的节点），如果后继节点为空或者ws =1,那么就在队列从后向前遍历去唤醒一个有效节点，这个节点醒来做的事情是尝试去获取锁，并且将排在它队列前连续被取消的节点出队。所以这里更新节点的前后指针操作还是交给其他线程来做的，在 shouldParkAfterFailedAcquire方法实现的。

  

  源代码如下：

    private void cancelAcquire(Node node) {
        // Ignore if node doesn't exist
        if (node == null)
            return;
       //1,将节点与线程解绑
        node.thread = null;
       
       //2,跳过前面所有被取消的节点
        // Skip cancelled predecessors
        Node pred = node.prev;
        while (pred.waitStatus > 0)
            node.prev = pred = pred.prev;
       //3,获取前置节点后一个位置节点，不一定是 node,有可能是跳过的被取消的节点，留作cas更新用
        Node predNext = pred.next;
        //4,将当前节点状态改为取消 ws =1
        node.waitStatus = Node.CANCELLED;

       //5,第一种情况：尾节点，将node前置节点更新为tail,并断开前置节点的next后置指针，node将无引用，被gc
        if (node == tail && compareAndSetTail(node, pred)) {
            compareAndSetNext(pred, predNext, null);
        } else {
          
            int ws;
          // 第三种情况：node在中间位置，要做的就是让node前置节点 pred的next指针指向node后的没被取消的节点，跳过node
            if (pred != head &&
                ((ws = pred.waitStatus) == Node.SIGNAL ||
                 (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
                pred.thread != null) {
                Node next = node.next;
                if (next != null && next.waitStatus <= 0)
                    compareAndSetNext(pred, predNext, next);
            } else {
              // 第二种情况，在head后面，那么要需向node后找没被取消节点，让head跳过node指向他，并唤醒该节点的线程。
                unparkSuccessor(node);
            }

            node.next = node; // help GC
        }
    }

唤醒后继者，该方法在release 方法也被执行，在线程使用完资源后，去唤醒下一个等待该资源的线程去执行。

 private void unparkSuccessor(Node node) {
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);
      // 状态置为0,初始状态，也不让她通知下一个节点，此时节点应该是取消状态1，是大于0的，为啥还需再判断一次？，这个方法不只这里用，释放资源release也用，正常ws =-1,所以更新状态为0

       //首先判断node后置节点，如果不行，再从尾向前遍历去找一个没被取消的节点 去唤醒其线程
        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(s.thread);
    }

5.2、release(int arg) 释放锁

  public final boolean release(int arg) {
     //1,释放资源前提是已经获取到
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
              //2，head的waitStatus在独占模式应该是signal =-1
              // 唤醒下一个节点，代码如上
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

同样，tryRelease() 与 tryAcquire() 一样，尝试释放锁，AQS都未具体实现，抛出异常，留个子类具体去实现。

AQS中代码：

  protected boolean tryRelease(int arg) {
        throw new UnsupportedOperationException();
    }

这里还是看一下ReentrantLock 的具体实现

  protected final boolean tryRelease(int releases) {
      //1,在没有可重入情况下，state =1, releases =1, 此时 c应该 =0 
            int c = getState() - releases;
       //2,判断当前释放锁线程是否等于拿到锁的线程，不等就抛出异常
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
      //3,可见只有c=0,情况才可成功释放锁
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

注：因ReentrantLock可重入的锁，由上代码可见，只有在 state=0的情况，才可成功释放锁，常见错误场景：在使用ReentrantLock lock n次，却没有unlock相应的n次，导致没有成功释放锁。

6、总结

1、 AQS的CLH队列的 pre指针可保证可靠性，next是保证不了的，看上面的代码分析，在遍历队列时，会向前遍历来查找安全点。

2、Condition 队列与 CLH同步队列两者的区别，同步队列中的所有线程是在等待获取锁的，Condition条件队列是某些之前已经获取到锁，因为要等待某个事件（如IO事件)或者与某个线程同步（等待另一线程执行结果），主动调用await方法，主动释放锁后，将该线程放入条件队列中的，所以在条件队列中线程不是等待获取锁，而是在等某个条件，下一篇我会来分析AQS的重要机制- 等待通知，靠其内部类ConditionObject实现，await和 signal来阻塞与 通知机制，可替代传统Object类提供的wait和 notify功能，而AQS可有多个条件来分类，比之应用更加灵活。