AQS锁的原理

Posted 2023-03-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了AQS锁的原理相关的知识，希望对你有一定的参考价值。

参考技术A synchronized是JVM层面实现的锁，而AQS是JDK层面实现的锁。
关于synchronized锁，可以看之前写的这篇：
synchronized锁关键字的膨胀性与用法

其实AQS和synchronized在实现锁的原理上是一样的，只是AQS是借助了同步队列去进行自旋和阻塞，利用条件队列去实现Object的对象方法，去完成等待和唤醒。

我们要注意的是同步队列是等待获取锁的队列，条件队列是曾经获取到锁，但是因为类似（满队入队/空队出队）这样的阻塞行为，而避免一直阻塞，进行调节使用的。

废话不多说，我们从一个实际的场景出发去讲一下这个原理。

1、线程A,B,C想要抢占一个资源做操作；

2、线程A先得头筹获得了对象的锁。在它持有资源的同时，其他线程就会被阻塞，依次加入到同步队列中去，顺序为B,C；

3、每一个Node入队都会自旋检查自己前一个节点是不是signal状态，如果是signal状态，就阻塞自己，等待唤醒；如果不是，就自旋【尝试获取锁，获取不到就尝试将它变成signal状态】这个过程；

4、当线程A执行完毕后，它会释放锁，然后唤醒同步队列的头结点，这时候头结点B就会去获取锁；

5、当B获得锁之后，他发现之前线程A的操作让当前资源队列的元素为空，而它要做的操作是一个take()操作。无法执行，会一直阻塞。要怎么办呢？

6、这时候就会把它添加到条件队列当中，然后释放锁，让其他线程获取资源，直到满足线程B执行操作的条件为止；

7、释放锁之后，唤醒了同步队列的头结点C，此时C获得了资源。它对着资源队列执行了put()操作；

8、此时，条件队列中的节点B将被唤醒，从条件队列转移到同步队列的队尾中去；

9、等线程C执行完put()操作，释放锁，然后唤醒了同步队列中的第一个节点B；

10、然后线程B执行take()操作。并发结束。

以上就是一个简单的锁模型。

对于锁的状态state，是一个int值。

还有一个超时时间。这些是子类自己去实现规则。

同步队列和条件队列的元素都是Node

Node中主要有这些参数：

waitStatus 当前节点的状态。主要有0（初始化），1（取消），-1（SINGAL）【同步队列】，-2（CONDITION）【条件队列】，-3（PROPAGATE ）【共享锁】

是排他锁还是共享锁是根据Node中的字段标记的。

nextWaiter，在条件队列中，指下一个节点；在同步队列中，指什么属性的锁。

Thread 绑定的当前线程。

AQS(AbstractQueuedSynchronizer)源码深度解析—同步队列以及独占式获取锁释放锁的原理一万字

详细介绍了AQS中的同步队列以及同步状态的独占式获取、释放的原理。

AQS(AbstractQueuedSynchronizer)源码深度解析(2)—Lock接口以及自定义锁的实现

AQS(AbstractQueuedSynchronizer)源码深度解析(3)—同步队列以及独占式获取锁、释放锁的原理【一万字】

AQS(AbstractQueuedSynchronizer)源码深度解析(4)—共享式获取锁、释放锁的原理【一万字】

AQS(AbstractQueuedSynchronizer)源码深度解析(5)—条件队列的等待、通知的实现以及AQS的总结【一万字】

AQS中的同步队列与同步状态的获取、释放、阻塞有紧密的关联关系，这两个知识点必须要连起来学习。

文章目录

1 同步队列的结构
2 锁的获取与释放
3 acquire独占式获取锁
4 release独占式锁释放
- 4.1 unparkSuccessor唤醒后继结点
5 acquirelnterruptibly独占式可中断获取锁
6 tryAcquireNanos独占式超时获取锁
- 6.1 doAcquireNanos独占式超时获取锁
- 6.2 finally代码块
7 独占式获取/释放锁总结

1 同步队列的结构

public abstract class AbstractQueuedSynchronizer extends
            AbstractOwnableSynchronizer implements java.io.Serializable {
        /**
         * 当前获取锁的线程，该变量定义在父类中，AQS直接继承。在独占锁的获取时，如果是重入锁，那么需要知道到底是哪个线程获得了锁。没有就是null
         */
        private transient Thread exclusiveOwnerThread;
        /**
         * AQS中保持的对同步队列的引用
         * 队列头结点，实际上是一个哨兵结点，不代表任何线程，head所指向的Node的thread属性永远是null。
         */
        private transient volatile Node head;
        /**
         * 队列尾结点，后续的结点都加入到队列尾部
         */
        private transient volatile Node tail;
        /**
         * 同步状态
         */
        private volatile int state;

        /**
         * Node内部类，同步队列的结点类型
         */
        static final class Node {

            /*AQS支持共享模式和独占模式两种类型，下面表示构造的结点类型标记*/
            /**
             * 共享模式下构造的结点，用来标记该线程是获取共享资源时被阻塞挂起后放入AQS 队列的
             */
            static final Node SHARED = new Node();
            /**
             * 独占模式下构造的结点，用来标记该线程是获取独占资源时被阻塞挂起后放入AQS 队列的
             */
            static final Node EXCLUSIVE = null;


            /*线程结点的等待状态，用来表示该线程所处的等待锁的状态*/

            /**
             * 指示当前结点(线程)需要取消等待
             * 由于在同步队列中等待的线程发生等待超时、中断、异常，即放弃获取锁，需要从同步队列中取消等待，就会变成这个状态
             * 如果结点进入该状态，那么不会再变成其他状态
             */
            static final int CANCELLED = 1;
            /**
             * 指示当前结点（线程）的后续结点（线程）需要取消等待（被唤醒）
             * 如果一个结点状态被设置为SIGNAL，那么后继结点的线程处于挂起或者即将挂起的状态
             * 当前结点的线程如果释放了锁或者放弃获取锁并且结点状态为SIGNAL，那么将会尝试唤醒后继结点的线程以运行
             * 这个状态通常是由后继结点给前驱结点设置的。一个结点的线程将被挂起时，会尝试设置前驱结点的状态为SIGNAL
             */
            static final int SIGNAL = -1;
            /**
             * 线程在等待队列里面等待，waitStatus值表示线程正在等待条件
             * 原本结点在等待队列中，结点线程等待在Condition上，当其他线程对Condition调用了signal()方法之后
             * 该结点会从从等待队列中转移到同步队列中，进行同步状态的获取
             */
            static final int CONDITION = -2;
            /**
             * 释放共享资源时需要通知其他结点，waitStatus值表示下一个共享式同步状态的获取应该无条件传播下去
             */
            static final int PROPAGATE = -3;
            /**
             * 记录当前线程等待状态值，包括以上4中的状态，还有0，表示初始化状态
             */
            volatile int waitStatus;

            /**
             * 前驱结点，当结点加入同步队列将会被设置前驱结点信息
             */
            volatile Node prev;

            /**
             * 后继结点
             */
            volatile Node next;

            /**
             * 当前获取到同步状态的线程
             */
            volatile Thread thread;

            /**
             * 等待队列中的后继结点，如果当前结点是共享模式的，那么这个字段是一个SHARED常量
             * 在独占锁模式下永远为null，仅仅起到一个标记作用，没有实际意义。
             */
            Node nextWaiter;

            /**
             * 如果是共享模式下等待，那么返回true（因为上面的Node nextWaiter字段在共享模式下是一个SHARED常量）
             */
            final boolean isShared() {
                return nextWaiter == SHARED;
            }

            /**
             * 用于建立初始头结点或SHARED标记
             */
            Node() {
            }

            /**
             * 用于添加到等待队列
             *
             * @param thread
             * @param mode
             */
            Node(Thread thread, Node mode) {
                this.nextWaiter = mode;
                this.thread = thread;
            }
            //......
        }
    }
}

由上面的源码可知，同步队列的基本结构如下图：

在AQS内部Node的源码中我们能看到，同步队列是"CLH" （Craig, Landin, andHagersten）锁队列的变体，它的head引用指向的头结点作为哨兵结点，不存储任何与等待线程相关的信息，或者可以看成已经获得锁的结点。第二个结点开始才是真正的等待线程构建的结点，后续的结点会加入到链表尾部。

将新结点添加到链表尾部的方法是compareAndSetTail(Node expect,Node update)方法，该方法是一个CAS方法，能够保证线程安全。

最终获取锁的线程所在的结点，会被设置成为头结点（setHead方法），该设置步骤是通过获取锁成功的线程来完成的，由于只有一个线程能够成功获取到锁，因此设置的方法并不需要使用CAS来保证。

同步队列遵循先进先出(FIFO)，头结点的next结点是将要获取到锁的结点，线程在释放锁的时候将会唤醒后继结点，然后后继结点会尝试获取锁。

2 锁的获取与释放

Lock中“锁”的状态使用state变量来表示，一般来说0表示锁没被占用，大于0表示所已经被占用了。

AQS提供的锁的获取和释放分为独占式的和共享式的：

独占式：顾名思义就是同一时刻只能有一个线程获取到锁，其他获取锁线程只能处于同步队列中等待，只有获取锁的线程释放了锁，后继的线程才能够获取到锁。
共享式：同一时刻能够有多个线程获取到锁。

对于AQS 来说，线程同步的关键是对同步状态state的操作：

在独占式下获取和释放锁使用的方法为： void acquire( int arg) 、void acquirelnterruptibly(int arg) 、boolean release( int arg）。
在共享式下获取和释放锁的方法为： void acquireShared(int arg) 、void acquireSharedInterruptibly(int arg）、 boolean reaseShared(int arg）。

获取锁的大概通用流程如下：

线程会首先尝试获取锁，如果失败，则将当前线程以及等待状态等信息包成一个Node结点加到同步队列里。接着会不断循环尝试获取锁（获取锁的条件是当前结点为head的直接后继才会尝试），如果失败则会尝试阻塞自己（阻塞的条件是当前节结点的前驱结点是SIGNAL状态），阻塞后将不会执行后续代码，直至被唤醒；当持有锁的线程释放锁时，会唤醒队列中的后继线程，或者阻塞的线程被中断或者时间到了，那么阻塞的线程也会被唤醒。

如果分独占式和共享式，那么在上面的通用步骤之下有这些区别：

独占式获取的锁是与具体线程绑定的，就是说如果一个线程获取到了锁，exclusiveOwnerThread字段就会记录这个线程，其他线程再尝试操作state 获取锁时会发现当前该锁不是自己持有的，就会在获取失败后被放入AQS 同步队列。比如独占锁ReentrantLock 的实现，当一个线程获取了ReentrantLock 的锁后，在AQS 内部会首先使用CAS操作把state 状态值从0变为1 ，然后设置当前锁的持有者为当前线程，当该线程再次获取锁时发现它就是锁的持有者，则会把状态值从1变为2，也就是设置可重入次数，而当另外一个线程获取锁时发现自己并不是该锁的持有者就会被放入AQS 同步队列后挂起。
共享式获取的锁与具体线程是不相关的，当多个线程去请求锁时通过CAS 方式竞争获取锁，当一个线程获取到了锁后，另外一个线程再次去获取时如果当前锁还能满足它的需要，则当前线程只需要使用CAS 方式进行获取即可。比如Semaphore 信号量，当一个线程通过acquire（）方法获取信号量时，会首先看当前信号量个数是否满足需要，不满足则把当前线程放入同步队列，如果满足则通过自旋CAS 获取信号量，相应的信号量个数减少对应的值。

实际上，具体的步骤更加复杂，下面讲解源码的时候会提到！

3 acquire独占式获取锁

通过调用AQS的acquire模版方法可以独占式的获取锁，该方法不会响应中断，也就是由于线程获取同步状态失败后进入同步队列中，后续对线程进行中断操作时，线程不会从同步队列中移出。基于独占式实现的组件有ReentrantLock等。

该方法大概步骤如下：

首先调用tryAcquire方法尝试获取锁，如果获取锁成功会返回true，方法结束；否则获取锁失败返回false，然后进行下一步的操作。
通过addWaiter方法将线程按照独占模式Node.EXCLUSIVE构造同步结点，并添加到同步队列的尾部。
然后通过acquireQueued(Node node,int arg)方法继续自旋获取锁。
一次自旋中如果获取不到锁，那么判断是否可以挂起并尝试挂起结点中的线程（调用LockSupport.park(this)方法挂起自己，注意这里的线程状态是WAITING）。而挂起线程的唤醒主要依靠前驱结点或线程被中断来实现，注意唤醒之后会继续自旋尝试获得锁。
最终只有获得锁的线程才能从acquireQueued方法返回，然后根据返回值判断是否调用selfInterrupt设置中断标志位，但此时线程处于运行态，即使设置中断标志位也不会抛出异常（即acquire（lock）方法不会响应中断）。
线程获得锁，acquire方法结束，从lock方法中返回，继续后续执行同步代码！

/**
 * 独占式的尝试获取锁，一直获取不成功就进入同步队列等待
 */
public final void acquire(int arg) {
    //内部是由4个方法的调用组成的
    if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

3.1 tryAcquire尝试获取独占锁

熟悉的tryAcquire方法，这个方法我们在最开头讲“AQS的设计”时就提到过，该方法是AQS的子类即我们自己实现的，用于首次尝试获取独占锁，一般来说就是对state的改变、或者重入锁的检查、设置当前获得锁的线程等等，不同的锁有自己相应的逻辑判断，这里不多讲，后面讲具体锁的实现的时候（比如ReentrantLock）会讲到。总之，获取成功该方法就返回true，失败就返回false。

在AQS的中tryAcquire的实现为抛出异常，因此需要子类重写：

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

3.2 addWaiter加入到同步队列

addWaiter方法是AQS提供的，也不需要我们重写，或者说是锁的通用方法！

addWaiter方法用于将按照独占模式构造的同步结点Node.EXCLUSIVE添加到同步队列的尾部。大概步骤为：

按照给定模式，构建新结点。
如果同步队列不为null，则尝试将新结点添加到队列尾部（只尝试一次），如果添加成功则返回新结点，方法结束。
如果队列为null或者添加失败，则调用enq方法循环尝试添加，直到成功，返回新结点，方法结束。

/**
 * addWaiter(Node node)方法将获取锁失败的线程构造成结点加入到同步队列的尾部
 *
 * @param mode 模式。独占模式传入的是一个Node.EXCLUSIVE，即null；共享模式传入的是一个Node.SHARED，即一个静态结点对象（共享的、同一个）
 * @return 返回构造的结点
 */
private Node addWaiter(Node mode) {
    /*1 首先构造结点*/
    Node node = new Node(Thread.currentThread(), mode);
    /*2 尝试将结点直接放在队尾*/
    //直接获取同步器的tail结点，使用pred来保存
    Node pred = tail;
    /*如果pred不为null，实际上就是队列不为null
     * 那么使用CAS方式将当前结点设为尾结点
     * */
    if (pred != null) {
        node.prev = pred;
        //通过使用compareAndSetTail的CAS方法来确保结点能够被线程安全的添加，虽然不一定能成功。
        if (compareAndSetTail(pred, node)) {
            //将新构造的结点置为原队尾结点的后继
            pred.next = node;
            //返回新结点
            return node;
        }
    }
    /*
     * 3 走到这里，可能是:
     * (1) 由于可能是并发条件，并且上面的CAS操作并没有循环尝试，因此可能添加失败
     * (2) 队列可能为null
     * 调用enq方法，采用自旋方式保证构造的新结点成功添加到同步队列中
     * */
    enq(node);
    return node;
}

/**
 * addWaiter方法中使用到的Node构造器
 *
 * @param thread 当前线程
 * @param mode   模式
 */
Node(Thread thread, AbstractQueuedSynchronizer.Node mode) {
    //等待队列中的后继结点 就等于该结点的模式
    //由此可知，共享模式该值为Node.SHARED结点常量，独占模式该值为null
    this.nextWaiter = mode;
    //当前线程
    this.thread = thread;
}

3.2.1 enq保证结点入队

enq方法用在同步队列为null或者一次CAS添加失败的时候，enq要保证结点最终必定添加成功。大概步骤为：

开启一个死循环，在死循环中进行如下操作；
如果队列为空，那么初始化队列，添加一个哨兵结点，结束本次循环，继续下一次循环；
如果队列不为空，那么向前面的方法一样，则尝试将新结点添加到队列尾部，如果添加成功则返回新结点的前驱，循环结束；如果不成功，结束本次循环，继续下一次循环。

enq方法返回的是新结点的前驱，当然在addWaiter方法中没有用到。

另外，添加头结点使用的compareAndSetHead方法和添加尾结点使用的compareAndSetTail方法都是CAS方法，并且都是调用Unsafe类中的本地方法，因为线程挂机、恢复、CAS操作等最终会通过操作系统中实现，Unsafe类就提供了Java与底层操作系统进行交互的直接接口，这个类的里面的许多操作类似于C的指针操作，通过找到对某个属性的偏移量，直接对该属性赋值，因为与Java本地方法对接都是Hospot源码中的方法，而这些的方法都是采用C++写的，必须使用指针！

也可以说Unsafe是AQS的实现并发控制机制基石。因此在学习AQS的时候，可以先了解Unsafe：Java中的Unsafe类的原理详解与使用案例。

/**
 * 循环，直到尾结点添加成功
 */
private Node enq(final Node node) {
    /*死循环操作，直到添加成功*/
    for (; ; ) {
        //获取尾结点t
        Node t = tail;
        /*如果队列为null，则初始化同步队列*/
        if (t == null) {
            /*调用compareAndSetHead方法，初始化同步队列
             * 注意：这里是新建了一个空白结点，这就是传说中的哨兵结点
             * CAS成功之后，head将指向该哨兵结点，返回true
             * */
            if (compareAndSetHead(new Node()))
                //尾结点指向头结点（哨兵结点）
                tail = head;
            /*之后并没有结束，而是继续循环，此时队列已经不为空了，因此会进行下面的逻辑*/
        }
        /*如果队列不为null，则和外面的的方法类似，调用compareAndSetTail方法，新建新结点到同步队列尾部*/
        else {
            /*1 首先修改新结点前驱的指向，这一步不是安全的
            但是没关系，因为这一步如果发生了冲突，那么下面的CAS操作必然之后有一条线程会成功
            其他线程将会重新循环尝试*/
            node.prev = t;
            /*
             * 2 调用compareAndSetTail方法通过CAS方式尝试将结点添加到同步队列尾部
             * 如果添加成功，那么才能继续下一步，结束这个死循环，否则就会不断循环尝试添加
             * */
            if (compareAndSetTail(t, node)) {
                //3 修改原尾结点后继结点的指向
                t.next = node;
                //返回新结点，结束死循环
                return t;
            }
        }
    }
}

/**
 * CAS添加头结点. 仅仅在enq方法中用到
 *
 * @param update 头结点
 * @return true 成功；false 失败
 */
private final boolean compareAndSetHead(Node update) {
    return unsafe.compareAndSwapObject(this, headOffset, null, update);
}


/**
 * CAS添加尾结点. 仅仅在enq方法中用到
 *
 * @param expect 预期原尾结点
 * @param update 新尾结点
 * @return true 成功；false 失败
 */
private final boolean compareAndSetTail(Node expect, Node update) {
    return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
}

在addWaiter和enq方法中，成为尾结点需要三步：

设置前驱prev
设置tail
设置后继next

由于第二步设置tail是CAS操作，那么只能保证node的前驱prev一定是正确的，但是此后设置后继的操作却不一定能够马上成功就切换到了其他线程，此时next可能为null，但实际他的后继并不一定真的为null。

因此同步队列只能保证前驱prev一定是可靠的，但是next却不一定可靠，所以后面的源码的遍历操作基本上都是从后向前通过前驱prev进行遍历的。

3.3 acquireQueued结点自旋获取锁

能够走到该方法，那么说明通过了tryAcquire()和addWaiter()方法，表示该线程获取锁已经失败并且被放入同步队列尾部了。

acquireQueued方法表示结点进入同步队列之后的动作，实际上就进入了一个自旋的过程，自旋过程中，当条件满足，获取到了锁，就可以从这个自旋中退出并返回，否则可能会阻塞该结点的线程，后续即使阻塞被唤醒，还是会自旋尝试获取锁，直到成功或者而抛出异常。

最终如果该方法会因为获取到锁而退出，则会返回否被中断标志的标志位或者因为异常而退出，则会抛出异常！大概步骤为：

同样开启一个死循环，在死循环中进行下面的操作；
如果当前结点的前驱是head结点，那么尝试获取锁，如果获取锁成功，那么当前结点设置为头结点head，当前结点线程出队，表示当前线程已经获取到了锁，然后返回是否被中断标志，结束循环，进入finally；
如果当前结点的前驱不是head结点或者尝试获取锁失败，那么判断当前线程是否应该被挂起，如果返回true，那么调用parkAndCheckInterrupt挂起当前结点的线程（LockSupport.park 方法挂起线程，线程出于WAITING），此时不再执行后续的步骤、代码。
如果当前线程不应该被挂起，即返回false，那本次循环结束，继续下一次循环。
如果线程被其他线程唤醒，那么判断是否是因为中断而被唤醒并修改标志位，同时继续循环，直到在步骤2获得锁，才能跳出循环！（这也是acquire方法不会响应中断的原理—park方法被中断时不会抛出异常，仅仅是从挂起状态返回，然后需要继续尝试获取锁）
最终，线程获得了锁跳出循环，或者发生异常跳出循环，那么会执行finally语句块，finally中判断线程是否是因为发生异常而跳出循环，如果是，那么执行cancelAcquire方法取消该结点获取锁的请求；如果不是，即因为获得锁跳出循环，则finally中什么也不干！

/**
 * @param node 新结点
 * @param arg  参数
 * @return 如果在等待时中断，则返回true
 */
final boolean acquireQueued(final Node node, int arg) {
    //failed表示获取锁是否失败标志
    boolean failed = true;
    try {
        //interrupted表示是否被中断标志
        boolean interrupted = false;
        /*死循环*/
        for (; ; ) {
            //获取新结点的前驱结点
            final Node p = node.predecessor();
            /*只有前驱结点是头结点的时候才能尝试获取锁
             * 同样调用tryAcquire方法获取锁
             * */
            if (p == head && tryAcquire(arg)) {
                //获取到锁之后，就将自己设置为头结点（哨兵结点），线程出队列
                setHead(node);
                //前驱结点（原哨兵结点）的链接置空，由JVM回收
                p.next = null;
                //获取锁是否失败改成false，表示成功获取到了锁
                failed = false;
                //返回interrupted，即返回线程是否被中断
                return interrupted;
            }
            /*前驱结点不是头结点或者获取同步状态失败*/
            /*shouldParkAfterFailedAcquire检测线程是否应该被挂起，如果返回true
             * 则调用parkAndCheckInterrupt用于将线程挂起
             * 否则重新开始循环
             * */
            if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                /*到这一步，说明是当前结点（线程）因为被中断而唤醒，那就改变自己的中断标志位状态信息为true
                 * 然后又从新开始循环，直到获取到锁，才能返回
                 * */
                interrupted = true;
        }
    }
    /*线程获取到锁或者发生异常之后都会执行的finally语句块*/ finally {
        /*如果failed为true，表示获取锁失败，即对应发生异常的情况，
        这里发生异常的情况只有在tryAcquire方法和predecessor方法中可能会抛出异常，此时还没有获得锁，failed=true
        那么执行cancelAcquire方法，该方法用于取消该线程获取锁的请求，将该结点的线程状态改为CANCELLED，并尝试移除结点（如果是尾结点）
        另外，在超时等待获取锁的的方法中，如果超过时间没有获取到锁，也会调用该方法

        如果failed为false，表示获取到了锁，那么该方法直接结束，继续往下执行；*/
        if (failed)
            //取消获取锁请求，将当前结点从队列中移除，
            cancelAcquire(node);
    }
}


/**
 * 位于Node结点类中的方法
 * 返回上一个结点，或在 null 时引发 NullPointerException。 当前置不能为空时使用。 空检查可以取消，表示此异常无代码层面的意义，但可以帮助 VM？所以这个异常到底有啥用？
 *
 * @return 此结点的前驱
 */
final Node predecessor() throws NullPointerException {
    //获取前驱
    Node p = prev;
    //如果为null，则抛出异常
    if (p == null)
        throw new NullPointerException();
    else
        //返回前驱
        return p;
}


/**
 * head指向node新结点，该方法是在tryAcquire获取锁之后调用，不会产生线程安全问题
 *
 * @param node 新结点
 */
private void setHead(Node node) {
    head = node;
    //新结点的thread和prev属性置空
    //即丢弃原来的头结点，新结点成为哨兵结点，内部线程出队
    //设置里虽然线程引用置空了，但是一般在tryAcquire方法中轨记录获取到锁的线程，因此不担心找不到是哪个线程获取到了锁
    //这里也能看出,哨兵结点或许也可以叫做"获取到锁的结点"
    node.thread = null;
    node.prev = null;
}

3.3.1 shouldParkAfterFailedAcquire结点是否应该挂起

shouldParkAfterFailedAcquire方法在没有获取到锁之后调用，用于判断当前结点是否需要被挂起。大概步骤如下：

如果前驱结点已经是SIGNAL(-1)状态，即表示当前结点可以挂起，返回true，方法结束；
否则，如果前驱结点状态大于0，即 Node.CANCELLED，表示前驱结点放弃了锁的等待，那么由该前驱向前查找，直到找到一个状态小于等于0的结点，当前结点排在该结点后面，返回false，方法结束；
否则，前驱结点的状态既不是SIGNAL(-1)，也不是CANCELLED(1)，尝试CAS设置前驱结点的状态为SIGNAL(-1)，返回false，方法结束！

只有前驱结点状态为SIGNAL时，当前结点才能安心挂起，否则一直自旋！

从这里能看出来，一个结点的SIGNAL状态一般都是由它的后继结点设置的，但是这个状态却是表示后继结点的状态，表示的意思就是前驱结点如果释放了锁，那么就有义务唤醒后继结点！

/**
 * 检测当前结点（线程）是否应该被挂起
 *
 * @param pred 该结点的前驱
 * @param node 该结点
 * @return 如果前驱结点已经是SIGNAL状态，当前结点才能挂起，返回true；否则，可能会查找新的前驱结点或者尝试将前驱结点设置为SIGNAL状态，返回false
 */
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    //获取 前取的waitStatus_等待状态
    //回顾创建结点时候,并没有给waitStatus赋值，因此每一个结点最开始的时候waitStatus的值都为0
    int ws = pred.waitStatus;
    /*如果前驱结点已经是SIGNAL状态，即表示当前结点可以挂起*/
    if (ws == Node.SIGNAL)
        return true;
    /*如果前驱结点状态大于0，即 Node.CANCELLED 表示前驱结点放弃了锁的等待*/
    if (ws > 0) {
        /*由该前驱向前查找，直到找到一个状态小于等于0的结点(即没有被取消的结点)，当前结点成为该结点的后驱，这一步很重要，可能会清理一段被取消了的结点，并且如果该前驱释放了锁，还会唤醒它的后继，保持队列活性*/
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    }
    /*否则，前驱结点的状态既不是SIGNAL(-1)，也不是CANCELLED(1)*/
    else {
        /*前驱结点的状态CAS设置为SIGNAL(-1)，可能失败，但没关系，因为失败之后会一直循环*/
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    //返回false，表示当前结点不能挂起
    return false;
}

3.3.2 parkAndCheckInterrupt挂起线程&判断中断状态

shouldParkAfterFailedAcquire方法返回true之后，将会调用parkAndCheckInterrupt方法挂起线程并且后续判断中断状态，分两步：

使用LockSupport.park(this)挂起该线程，不再执行后续的步骤、代码。直到该线程被中断或者被唤醒（unpark）！
如果该线程被中断或者唤醒，那么返回Thread.interrupted()方法的返回值，该方法用于判断前线程的中断状态，并且清除该中断状态，即，如果该线程因为被中断而唤醒，则中断状态为true，将中断状态重置为false，并返回true，如果该线程不是因为中断被唤醒，则中断状态为false，并返回false。

/**
 * 挂起线程，在线程返回后返回中断状态
 *
 * @return 如果因为线程中断而返回，而返回true，否则返回false
 */
private final boolean parkAndCheckInterrupt() {
    /*1)使用LockSupport.park(this)挂起该线程，不再执行后续的步骤、代码。直到该线程被中断或者被唤醒（unpark）*/
    LockSupport.park(this);
    /*2)如果该线程被中断或者唤醒，那么返回Thread.interrupted()方法的返回值，
    该方法用于判断前线程的中断状态，并且清除该中断状态，即，如果该线程因为被中断而唤醒，则中断状态为true，将中断状态重置为false，并返回true，注意park方法被中断时不会抛出异常！
    如果该线程不是因为中断被唤醒，则中断状态为false，并返回false*/
    return Thread.interrupted();
}

3.3.3 finally代码块

在acquireQueued方法中，具有一个finally代码块，那么无论try中发生了什么，finally代码块都会执行的。在acquire独占式不可中断获取锁的方法中，执行finally的只有两种情况：

当前结点（线程）最终获取到了锁，此时会进入finally，而在获取到锁之后会设置failed = false。
在try中发生了异常，此时直接跳到finally中。这里发生异常的情况只可能在tryAcquire或predecessor方法中发生，然后直接进入finally代码块中，此时还没有获得锁，failed=true！
1. tryAcquire方法是我们自己实现的，抛出什么异常由我们来定，就算抛出异常一般也不会在acquireQueued中抛出，可能在最开始调用tryAcquire时就抛出了。
2. predecessor方法中，会检查如果前驱结点为null则抛出NullPointerException。但是注释中又说这个检查无代码层面的意义，或许是这个异常永远不会抛出？

finally代码块中的逻辑为：

如果failed = true，表示没有获取锁而进行finally，即发生了异常。那么执行cancelAcquire方法取消当前结点线程获取锁的请求，acquireQueued方法结束，然后抛出异常。
如果failed = false，表示已经获取到了锁，那么实际上finally中什么都不会执行。acquireQueued方法结束，返回interrupted—是否被中断标志。

综上所述，在acquire独占式不可中断获取锁的方法中，大部分情况在finally中都是什么也不干就返回了，或者说抛出异常的情况基本没有，因此cancelAcquire方法基本不考虑。

但是在可中断获取锁或者超时获取锁的方法中，执行到cancelAcquire方法的情况还是比较常见的。因此将cancelAcquire方法的源码分析放到可中断获取锁方法的源码分析部分！

3.4 selfInterrupt安全中断

selfInterrupt是acquire中最后可能调用的一个方法，顾名思义，用于安全的中断，什么意思呢，就是根据!tryAcquire和acquireQueued返回值判断是否需要设置中断标志位。

只有tryAcquire尝试失败，并且acquireQueued方法true时，才表示该线程是被中断过了的，但是在parkAndCheckInterrupt里面判断中断标志位之后又重置的中断标志位（interrupted方法会重置中断标志位）。

虽然看起来没啥用，但是本着负责的态度，还是将中断标志位记录下来。那么此时重新设置该线程的中断标志位为true。

/**
 * 中断当前线程，由于此时当前线程出于运行态，因此只会设置中断标志位，并不会抛出异常
 */
static void selfInterrupt() {
    Thread.currentThread().interrupt();
}

4 release独占式锁释放

当前线程获取到锁并执行了相应逻辑之后，就需要释放锁，使得后续结点能够继续获取锁。通过调用AQS的release(int arg)模版方法可以独占式的释放锁，在该方法大概步骤如下：

尝试使用tryRelease(arg)释放锁，该方法在最开始我们就讲过，是自己实现的方法，通常来说就是将state值为0或者减少、清除当前获得锁的线程等等，如果符合自己的逻辑，锁释放成功则返回true，否则返回false；
如果tryRelease释放成功返回true，判断如果head不为null且head的状态不为0，那么尝试调用unparkSuccessor方
以上是关于AQS锁的原理的主要内容，如果未能解决你的问题，请参考以下文章

AQS(AbstractQueuedSynchronizer)源码深度解析—同步队列以及独占式获取锁释放锁的原理一万字

AQS中非公平锁的实现原理简介

Java技术指南「并发原理专题」AQS的技术体系之CLHMCS锁的原理及实现

AQS 原理解析以及源码分析

AQS原理与源码

AbstractQueuedSynchronizer原理分析