AQS深入理解系列（一）独占锁的获取过程

╰+哭是因爲堅強的太久メ 2023-02-12 11:24 23阅读 0赞

### 文章目录 ###

*  前言
 *  AQS实现核心
 *   *  state
     *  等待队列
     *  CAS
 *  根据实现核心找AQS的成员
 *   *  state
     *  等待队列
     *  CAS
 *  观察ReentrantLock的内部类
 *  公平的、不响应中断的 独占锁的获取
 *   *  tryAcquire
     *  addWaiter
     *  enq
     *  enq的尾分叉 与 prev的有效性
     *  acquireQueued
     *  shouldParkAfterFailedAcquire
     *  parkAndCheckInterrupt
 *  不公平的、不响应中断的 独占锁的获取
 *   *  观察ReentrantLock的内部类
 *  响应中断的 独占锁的获取
 *  超时的 独占锁的获取
 *  只一次尝试的 非公平的 独占锁的获取
 *  总结

# 前言 #

AQS（AbstractQueuedSynchronizer）可以说是整个Java并发框架的基础，其实现大量依赖乐观锁的方式（即CAS+自旋）。它实现了一个FIFO的等待队列用于等待获取同步状态，而获取/释放同步器状态的函数则依靠子类来实现。

虽然AQS是一个抽象类，但却没有任何抽象方法。如果定义为抽象方法确实不合适，因为继承使用AQS并不一定需要使用到AQS提供的所有功能（独占锁和共享锁），这样子类反而需要实现所有抽象方法。如果定义为空实现的普通方法，虽然不需要子类实现所有空方法了，但这样还是不够明确。现在AQS将这些方法的实现为抛出`UnsupportedOperationException`异常，那么如果是子类需要使用的方法，就覆盖掉它；如果是子类不需要使用的方法，一旦调用就会抛出异常。

[JUC框架 系列文章目录][JUC_]

# AQS实现核心 #

## state ##

同步器有一个state，它代表着当前同步器的状态，它是整个AQS的核心属性。我们平时使用的JUC框架下的常用类比如`ReentrantLock`，其实它们的方法就是在设置和改变这个state。而之前说的子类需要实现的方法，简单的说，它的实现逻辑也就是在设置和改变这个state。

## 等待队列 ##

AQS中已经为我们实现了一个FIFO的等待队列，它是一个双向链表。由于同步器的state一般不能让所有线程同时获得，所以将这些需要暂时等待的线程包装成一个节点放到队列中去，当获取state的条件满足时，会将这个节点内的线程唤醒，以便它接下来去尝试获取state。

## CAS ##

CAS是一种轻量级的并发处理，在对AQS属性以及队列节点属性进行修改时，都会用到CAS操作。既然是多线程环境下，那么就会有多个线程同时修改这些属性，而CAS保证了同一时刻只有一个线程能修改成功，而其他CAS操作失败的线程，一般则会通过自旋继续尝试CAS操作。

# 根据实现核心找AQS的成员 #

根据上面讲到的AQS实现核心，我们来寻找AQS类中成员。

## state ##

private volatile int state;

如上，state已经被我们找到了，它一个volatile的变量，这样就保证了可见性。

由于本文分析的是独占锁，所以当state为0时，代表没有线程持有锁。当state为1时，代表有线程持有锁。当state>1时，代表有线程持有该锁，并且重入过该锁。所以state是否为0，可以作为判断是否有线程持有该独占锁的标准。

private transient Thread exclusiveOwnerThread;

而`exclusiveOwnerThread`成员则用来记录当前持有锁的线程。

## 等待队列 ##

等待队列的节点需要有一个实现类，它正是`Node`这个静态内部类。

static final class Node { 
            /** Marker to indicate a node is waiting in shared mode */
            static final Node SHARED = new Node();
            /** Marker to indicate a node is waiting in exclusive mode */
            static final Node EXCLUSIVE = null;
    
            /** waitStatus value to indicate thread has cancelled */
            static final int CANCELLED =  1;
            /** waitStatus value to indicate successor's thread needs unparking */
            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;
    
            volatile int waitStatus;
    		// 双向链表的结构
            volatile Node prev;
            volatile Node next;
    		// Node对象用来包装线程
            volatile Thread thread;
    		// 用来表明当前node的线程是想要获取共享锁还是独占锁
            Node nextWaiter;
    
            final boolean isShared() { 
                return nextWaiter == SHARED;
            }
        }

*  作为双向链表的节点，自然需要`prev`和`next`，即前驱和后继指针。通过这两个指针将各节点连接起来。
 *  `thread`成员肯定也是必需的。因为`Node`就是用来设计包装线程对象的，自然需要一个`Thread`类型的成员。
 *  `nextWaiter`成员则是用来表明当前node的线程是想要获取共享锁还是独占锁。注意，这个成员只是这个作用，不是用来连接双向链表的。
 *  最重要的还是`waitStatus`成员，用来表明node代表线程的状态。

有了队列节点，自然也需要AQS持有这个队列。

// 头结点，固定是一个dummy node，因为它的thread成员固定为null
    private transient volatile Node head;
    
    // 尾节点，请求锁失败的线程，会包装成node，放到队尾
    private transient volatile Node tail;

`head`和`tail`都是AQS的成员，分别代表队列的头和尾，通过持有这两个成员，相当于AQS也持有了这个队列。  
![在这里插入图片描述][20200531181242462.jpg]  
等待队列如上图所示，注意head节点作为一个dummy node，它的thread成员一定为null。

*  head节点的thread成员为null，可以理解为将它的thread成员放到AQS的`exclusiveOwnerThread`属性上去了，所以它的thread成员为null。
 *  即使等待线程只有一个，等待队列中的节点个数也肯定是2个，因为第一个节点总是dummy node。

## CAS ##

熟悉原子类源码的同学，肯定都见过利用`Unsafe`工具类来调用CAS操作。对于AQS或Node的属性修改，也需要使用这些CAS操作。

private static final Unsafe unsafe = Unsafe.getUnsafe();
        private static final long stateOffset;
        private static final long headOffset;
        private static final long tailOffset;
        private static final long waitStatusOffset;
        private static final long nextOffset;
    
        static { 
            try { 
                stateOffset = unsafe.objectFieldOffset
                    (AbstractQueuedSynchronizer.class.getDeclaredField("state"));
                headOffset = unsafe.objectFieldOffset
                    (AbstractQueuedSynchronizer.class.getDeclaredField("head"));
                tailOffset = unsafe.objectFieldOffset
                    (AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
                waitStatusOffset = unsafe.objectFieldOffset
                    (Node.class.getDeclaredField("waitStatus"));
                nextOffset = unsafe.objectFieldOffset
                    (Node.class.getDeclaredField("next"));
    
            } catch (Exception ex) {  throw new Error(ex); }
        }

从上面可以看到，需要通过CAS操作来修改的属性有AQS的`state`、`head`和`tail`；Node的`waitStatus`和`next`。因为这几个属性确实会被多线程访问。

protected final boolean compareAndSetState(int expect, int update) { 
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }
    private final boolean compareAndSetHead(Node update) { 
        return unsafe.compareAndSwapObject(this, headOffset, null, update);
    }
    private final boolean compareAndSetTail(Node expect, Node update) { 
        return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
    }
    private static final boolean compareAndSetWaitStatus(Node node, int expect,int update) { 
        return unsafe.compareAndSwapInt(node, waitStatusOffset, expect, update);
    }
    private static final boolean compareAndSetNext(Node node, Node expect, Node update) { 
        return unsafe.compareAndSwapObject(node, nextOffset, expect, update);
    }

最后，我们利用`Unsafe`的`compareAndSetXXX`即CAS方法。

# 观察ReentrantLock的内部类 #

public class ReentrantLock implements Lock, java.io.Serializable { 
        private final Sync sync;
        
        abstract static class Sync extends AbstractQueuedSynchronizer { 
            ...
        }
        
        static final class NonfairSync extends Sync{ 
            ...
        }
        
        static final class FairSync extends Sync { 
            ...
        }
        // 默认是非公平锁
        public ReentrantLock() { 
            sync = new NonfairSync();
        }
        // 根据参数，设置公平或非公平
        public ReentrantLock(boolean fair) { 
            sync = fair ? new FairSync() : new NonfairSync();
        }
        
        // 获取锁
        public void lock() { 
            sync.lock();
        }
        
        ...
    }

可以看到ReentrantLock使用AQS都是通过使用子类：

*  `Sync`继承了`AbstractQueuedSynchronizer`，在`Sync`里，实现了`tryRelease`（父类中的实现是抛出异常）。
 *  `NonfairSync`和`FairSync`都继承了`Sync`，在`NonfairSync`和`FairSync`里，会调用`acquire`（父类已有的实现），会实现`tryAcquire`（父类中的实现是抛出异常）。
 *  AQS可以实现 **独占锁和共享锁**，但ReentrantLock只使用了独占锁部分。获取锁的方式可以分为 **公平和非公平**，**响应中断和不响应中断**。本文将以 公平、不响应中断 的方式作为切入点，来分析AQS源码。

# 公平的、不响应中断的 独占锁的获取 #

//ReentrantLock.java
        static final class FairSync extends Sync { 
            private static final long serialVersionUID = -3000897897090466540L;
    
            final void lock() { 
                acquire(1);
            }
    
            /** * Fair version of tryAcquire. Don't grant access unless * recursive call or no waiters or is first. */
            protected final boolean tryAcquire(int acquires) { 
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) { 
                    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;
            }
        }

*  获取锁的第一步便是调用`acquire`，里面的参数1代表state需要增加1。

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

先大概说一下每个函数的作用，可能的调用流程：

1.  `tryAcquire`用来获取独占锁一次，try的意思就是只试一次，要么成功，要么失败。
2.  `tryAcquire`返回true时，后面的三个函数都不会执行了。
3.  `tryAcquire`返回false时，必将调用`addWaiter`和`acquireQueued`。
4.  `addWaiter`是AQS的实现，因为开始获取锁失败了（`tryAcquire`返回false），所以需要把当前线程包装成node放到等待队列中，返回代表当前线程的node。
5.  `acquireQueued`是AQS的实现，简单的理解就是：用一个死循环不断得去执行`tryAcquire`，直到获取锁。当然：
    
    1.  程序不会真的在死循环，一般情况下，会不断经历 阻塞和被唤醒 两种状态。
    2.  当参数node的前驱是head时，才会去`tryAcquire`尝试获得锁。
6.  `selfInterrupt`用来复原中断状态，虽然这个版本的函数不用响应中断。当`acquireQueued`返回真时，代表这期间函数曾经检测到过中断状态，并且将中断状态消耗掉了（`Thread.interrupted()`），所以需要在退出`acquire`之前，将中断状态重新设置上。

悄悄给你说，其实上面就已经讲完了独占锁的获取过程了，接下来让我们具体分析。

## tryAcquire ##

前面提到，tryAcquire在ReentrantLock里，`NonfairSync`和`FairSync`分别实现了tryAcquire，而我们这里从`FairSync`的tryAcquire看起。

简单来说，tryAcquire的实现就是：尝试获得锁一次，成功了返回true，否则false。

protected final boolean tryAcquire(int acquires) { 
                final Thread current = Thread.currentThread();
                //获得当前同步器的state
                int c = getState();
                if (c == 0) { 
                    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;
            }

*  参数`acquires`代表你想让同步器的state再增加多少。函数返回值为true，代表你成功获取到了锁。返回true时，同步器的state已经增加了`acquires`，且`Thread exclusiveOwnerThread`成员被设置成了当前执行线程。
 *  首先获得同步器的state。
 *  如果进入`if (c == 0)`分支，说明当前state为0，当前锁已经被释放掉了，但此时CHL队列中可能有线程已经在排队了（考虑到此版本是公平锁），所以需要通过`hasQueuedPredecessors`判断队列中是否已经有等待线程（返回true代表有）。
    
     *  `hasQueuedPredecessors`返回true，那么直接返回false，说明tryAcquire失败。
     *  `hasQueuedPredecessors`返回false，才会尝试CAS操作设置state。如果CAS操作成功，那么说明当前线程成功抢到了锁，调用`setExclusiveOwnerThread`设置独占线程；如果CAS操作失败，那么直接返回false，说明此次tryAcquire失败。
 *  如果进入`else if (current == getExclusiveOwnerThread())`分支，说明当前state不为0，已经有线程持有锁，但考虑锁可重入，如果当前线程就是AQS的独占线程的话，那么就直接让state再加`acquires`；如果当前线程根本不是AQS的独占线程，那么直接返回false，说明此次tryAcquire失败。

tryAcquire的逻辑总结来说：

*  当锁已经被释放时（state为0），先以公平的方式判断是否可以尝试获得锁（hasQueuedPredecessors的返回值），再尝试获得锁（通过CAS操作设置state为1）。
 *  当锁已经被占有时，判断一下是否是自己占有的（`current == getExclusiveOwnerThread()`），如果是就重入这个锁。
 *  需要注意，前者设置state使用的是CAS操作，因为此时当前线程还没有获得锁，不一定谁能竞争到，所以用CAS保证只有一个线程能设置state成功；而后者直接set，是因为当前线程已经获取锁了，此时别的线程都不能修改state，即只有当前线程在写state，所以直接set是安全的。

## addWaiter ##

既然执行到了addWaiter，说明当前线程第一次执行tryAcquire时失败了。既然获取锁失败了，那么就需要将当前线程包装一个node，放到等待队列的队尾上去，以后锁被释放时别人就会通过这个node来唤醒自己。

private Node addWaiter(Node mode) { 
            Node node = new Node(Thread.currentThread(), mode);
            // 使用enq的快捷方法，如果CAS操作失败，才会去执行enq 
            Node pred = tail;
            // 如果队列不为空
            if (pred != null) { 
                node.prev = pred;
                if (compareAndSetTail(pred, node)) { 
                    pred.next = node;
                    return node;
                }
            }
            // 执行到这里，有两种情况：
            // 1.队列为空。head和tail成员从来没有初始化过
            // 2.CAS操作失败。当执行compareAndSetTail时，tail成员已经被修改了
            enq(node);
            return node;
        }

*  由于当初这么调用的`addWaiter(Node.EXCLUSIVE)`，然后会调用下面的这版构造器。由此可见，刚放到队尾的node，它的`nextWaiter`肯定为null，它的`waitStatus`为0（默认初始化）。

static final Node EXCLUSIVE = null;
            
            Node(Thread thread, Node mode) {      // Used by addWaiter
                this.nextWaiter = mode;
                this.thread = thread;
            }

*  函数的主要逻辑，其实跟`enq`函数中一样，所以称它为`enq`的快捷方式，区别在于`enq`是循环执行这段逻辑。逻辑为：当队列不为空时，CAS尝试tail成员为新创建的node，如果成功，那么将next指针修正，并返回这个node。该函数既然完成了 将当前线程所包装成的node放在队尾的使命，自然就可以返回该node了。
 *  如果执行到了`enq(node)`，那么可能有两种情况：
    
     *  队列为空。head和tail成员从来没有初始化过。
     *  CAS操作失败。当执行compareAndSetTail时，tail成员已经被修改了。
 *  自然，`enq`函数能保证 在多线程下 安全得将 该node放到队尾去，它的具体做法是 自旋+CAS。
 *  不管是提前return，还是执行完`enq`再return，当return时，已经是将代表当前线程的node放到队尾了。注意，返回的是，代表当前线程的node。

## enq ##

由于addWaiter的时候并没有成功将刚创建的node放到队尾，这时需要enq出马了。

private Node enq(final Node node) { 
            for (;;) { 
                Node t = tail;
                // 如果tail为null，说明队列为空，head肯定也为null
                // 进一步说明 等待队列的初始化是懒汉式的
                if (t == null) {  
                    if (compareAndSetHead(new Node()))
                        tail = head;
                // 如果tail不为null，说明队列至少有一个dummy node，head肯定也不为null
                } else { 
                    node.prev = t;
                    if (compareAndSetTail(t, node)) { 
                        t.next = node;
                        return t;
                    }
                }
            }
        }

*  进入`if (t == null)`分支，tail为null，说明队列为空，head肯定也为null。然后尝试CAS设置head成员。
    
     *  注意，如果队列从来没有初始化过（head、tail为null），那么这个循环至少得执行两次，第一次给队列新建一个空node，第二次进`if (t == null)`的else分支，把参数node放在空node的后面。
     *  根据上一条可知，**就算只有一个线程入队，入队完毕后队列将有两个node，第一个node称为dummy node，因为它的thread成员为null；第二个node才算是实际意义的队头，它的thread成员不为null。**
     *  新建的是空node，它的所有成员都是默认值。`thread`成员为null，waitStatus为0。之后你会发现，队尾node的waitStatus总是0，因为默认初始化。
     *  `compareAndSetHead`作为一个CAS操作只有一个参数，是因为它的实现是`unsafe.compareAndSwapObject(this, headOffset, null, update);`。
     *  `compareAndSetHead`的CAS操作也可能失败，当队列为空时，两个线程同时执行到`enq`。
 *  进入`if (t == null)`的else分支，tail不为null，说明队列至少有一个dummy node，head肯定也不为null。
    
     *  先令node的prev指向tail，但只有CAS设置node为tail成功后，才会将tail的next指向node，才会将双向链表的指针都正确完成指向。
     *  `compareAndSetTail(t, node)`可能失败，当多个线程都执行到了`node.prev = t`这里。
 *  这个循环只有在`compareAndSetTail(t, node)`成功时才会退出循环，这就保证了enq最终肯定能将参数node放到队尾。
 *  简单总结就是：`enq`利用了自旋（循环）和CAS操作，保证了node放到队尾。

## enq的尾分叉 与 prev的有效性 ##

在队列已经有node的情况下，如果同时有多个线程执行到`node.prev = t`这里，最终只有一个线程能够成功设置tail成员。

} else { 
                    node.prev = t;  // 1
                    if (compareAndSetTail(t, node)) {   // 2
                        t.next = node;  // 3
                        return t;
                    }
                }

从上面看，发现要完成双向链表的指针指向，需要经过3步：

1.  将参数node的前驱指向tail
2.  CAS设置参数node为tail
3.  如果CAS成功，则修正tail的后继

因为CAS操作的保证，所有线程都能够执行第1步，但第2、3步只会有一个线程能够执行到。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70]  
**enq的尾分叉**：从上面的步骤可以看出，如果存在很多个线程都刚好执行到了`node.prev = t`这里，那么CAS失败的线程不能成功入队，此时它们的prev还暂时指向的旧tail。

**prev的有效性**：从上图第二步可以看到，此时线程1的node已经是成功放到队尾了，但此时队列却处于一个中间状态，前一个node的next还没有指向队尾呢。此时，如果另一个线程如果通过next指针遍历队列，就会漏掉最后那个node；但如果另一个线程通过tail成员的prev指针遍历队列，就不会漏掉node了。

**prev的有效性**也解释了AQS源码里遍历队列时，为什么常常使用tail成员和prev指针来遍历，比如你看`unparkSuccessor`。

## acquireQueued ##

acquireQueued函数是整个独占锁获取的精华部分，它解释了独占锁获取的整个过程。

执行到这个函数，说明：

*  当前线程已经执行完了`addWaiter`方法。
 *  传入的node的thread成员就是当前线程。
 *  传入的node已经成功入队。（`addWaiter`的作用）

简单的说，acquireQueued是利用自旋+tryAcquire“不断”地尝试获取锁，当然实际上如果真的是在死循环来不断调tryAcquire，肯定电脑都卡死了。实际流程是：

*  每次循环都会判断是否可以尝试获取锁（`p == head`），如果可以，那么尝试（`tryAcquire(arg)`）。
    
     *  如果尝试获取锁成功，那么函数的使命就达到了，执行完相应收尾工作，然后返回。
 *  如果 不可以尝试 或者 尝试获取锁却失败了，那么阻塞当前线程（`parkAndCheckInterrupt`）。
 *  如果当前线程被唤醒了，又会重新走这个流程。被唤醒时，是从`parkAndCheckInterrupt`处唤醒，然后从这里继续往下执行。

final boolean acquireQueued(final Node node, int arg) { 
            boolean failed = true;
            try { 
                boolean interrupted = false;
                for (;;) { 
                    final Node p = node.predecessor();
                    // 尝试获取锁的前提是node是head的后继
                    if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    // 执行到这里，说明
                    // 要么不符合 尝试获取锁的前提
                    // 要么 尝试获取锁失败了
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

为什么`tryAcquire(arg)`的前提是`p == head`？  
因为从`enq`的逻辑可知，head只会是一个dummy node，实际意义的node只会在head的后面。而node的前驱是head（`final Node p = node.predecessor()`），则代表node已经是队列中的第一个实际node了，排在最前面的node自然可以尝试去获取锁了。

回想整个调用过程，是最开始在`acquire`里调用`tryAcquire`就已经失败了，然而此时第一次循环时，又可能马上去调`tryAcquire`（说可能，是因为需要`p == head`成立），这会不会是一次肯定失败的`tryAcquire`？  
考虑这种场景，线程1获取了锁正在使用还没释放，此时队列为空，线程2此时也来获取锁，自然最开始在`acquire`里调用`tryAcquire`会失败，假设线程2刚开始执行`acquireQueued`，此时线程1释放了锁，此时线程2肯定排在head后面，那么线程2马上`tryAcquire`，然后就可以获取成功。

执行acquireQueued的线程是谁？  
一定是node参数的thread成员，虽然执行过程中，可能会经历不断 阻塞和被唤醒 的过程。

为什么刚执行完addWaiter方法时，才把代表当前线程的node放到队尾，怎么之后一判断就会发现自己处于head的后继了？  
这个问题不考虑上面的特殊场景，而考虑addWaiter时，队列中有许多node。其实这很合理，这说明从head到当前方法栈中的node之间的那些node，它们自己也会在执行acquireQueued，它们依次执行成功（指`p == head && tryAcquire(arg)`成功），每次执行成功相当于把head成员从队列上后移一个node，当它们都执行完毕，当前方法栈中的node自然也就是head的后继了。  
注意，“之间的那些node”的最后一个node执行acquireQueued成功后（代表 最后一个node的代表线程获得锁成功，它自己成为了head），当前方法还在阻塞之中，只有当这“最后一个node”释放独占锁时，才会执行`unparkSuccessor(head)`，当前线程才会被唤醒。关于释放独占锁，以后再具体讲。

finally块是否会执行`cancelAcquire(node)`？  
虽然号称此函数是不响应中断的函数，但不响应中断只是对于AQS的使用者来说，如果一个线程阻塞在`parkAndCheckInterrupt`这里，别的线程来中断它，它是会马上唤醒的，然后继续这个循环。不过想要退出这个函数，只有通过`return interrupted`，而前一句就是`failed = false`，所以finally块里，是永远不会去执行`cancelAcquire(node)`的。

如下图，演示了多个线程依次获得独占锁的过程。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 1]

if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
    
        private void setHead(Node node) { 
            head = node;
            node.thread = null;
            node.prev = null;
        }

从逻辑中可见，如果当前线程获取锁成功，代表当前线程的node会新设置自己为head，然后将其弄成dummy node，即把node的thread成员清空，但这个被清空的thread成员已经在`tryAcquire`里将这个thread设置为了exclusiveOwnerThread。

*  可以这么理解，head之所以它的thread成员为null，是因为它的thread成员被放在了exclusiveOwnerThread成员里。
 *  使用`setHead`而非`compareAndSetHead`，因为此时不需要CAS操作，执行到这里说明当前线程已经获得了独占锁（tryAcquire成功），所以别的线程是不可能同时执行这部分代码的。

## shouldParkAfterFailedAcquire ##

我们先把函数名分成两部分：

> shouldPark：指的是 该函数的返回值影响是否可以执行parkAndCheckInterrupt函数。因为`shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()`这么写，只有当该函数返回true时，才会去执行parkAndCheckInterrupt。注意，parkAndCheckInterrupt函数执行后，当前线程就会被挂起了，也就是我们所说的阻塞。

> AfterFailedAcquire：指的是 获取锁失败了才会执行该函数。其实具体指两种情况：1. `p == head`为false，即当前线程的node的前驱不是head 2. 虽然 `p == head`为true，但`parkAndCheckInterrupt`返回false了，即当前线程虽然已经排到等待队列的最前面，但获取锁还是失败了。

回想之前讲过的函数，发现它们居然都没有使用过waitStatus这个属性，而现在就可以派上用场了。

static final int CANCELLED =  1;
    static final int SIGNAL    = -1;
    static final int CONDITION = -2;
    static final int PROPAGATE = -3;

node一共有四种状态，但在独占锁的获取和释放过程中，我们只可能将node的状态变成`CANCELLED`或`SIGNAL`，而shouldParkAfterFailedAcquire函数就会把一个node的状态变成`SIGNAL`。注意，一个node新建的时候，它的waitStatus是默认初始化为0的。

*  `CANCELLED`，一个node的状态是CANCELLED，说明这个node的代表线程已经取消等待了。
 *  `SIGNAL`，一个node的状态是SIGNAL，说明这个node的**后继node**的代表线程已经阻塞或马上阻塞（`shouldParkAfterFailedAcquire`设置前驱为SIGNAL后，下一次的`acquireQueued`循环可能就会阻塞了，所以说“已经阻塞或马上阻塞”），并且当前node成为head并释放锁时，会根据SIGNAL来唤醒后继node。即SIGNAL是唤醒后继节点的标志。
 *  有趣的是，`CANCELLED`状态与当前node关联，`SIGNAL`状态与后继node关联。

本函数，简单的讲就是，跳过无效前驱，把node的有效前驱（有效是指node不是CANCELLED的）找到，并且将有效前驱的状态设置为`SIGNAL`，之后便返回true代表马上可以阻塞了。

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { 
            int ws = pred.waitStatus;
            if (ws == Node.SIGNAL)
                /* * 前驱节点已经设置了SIGNAL，闹钟已经设好，现在我可以安心睡觉（阻塞）了。 * 如果前驱变成了head，并且head的代表线程exclusiveOwnerThread释放了锁， * 就会来根据这个SIGNAL来唤醒自己 */
                return true;
            if (ws > 0) { 
                /* * 发现传入的前驱的状态大于0，即CANCELLED。说明前驱节点已经因为超时或响应了中断， * 而取消了自己。所以需要跨越掉这些CANCELLED节点，直到找到一个<=0的节点 */
                do { 
                    node.prev = pred = pred.prev;
                } while (pred.waitStatus > 0);
                pred.next = node;
            } else { 
                /* * 进入这个分支，ws只能是0或PROPAGATE。 * CAS设置ws为SIGNAL */
                compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
            }
            return false;
        }

*  如果前驱节点的状态为`SIGNAL`，说明闹钟标志已设好，返回true表示设置完毕。
 *  如果前驱节点的状态为`CANCELLED`，说明前驱节点本身不再等待了，需要跨越这些节点，然后找到一个有效节点，再把node和这个有效节点的前驱后继连接好。
 *  如果是其他情况，那么CAS尝试设置前驱节点为`SIGNAL`。

由于shouldParkAfterFailedAcquire函数在`acquireQueued`的调用中处于一个死循环中，且因为shouldParkAfterFailedAcquire函数若返回false，且考虑当前线程一直不能获取到锁的情况，那么此函数必将至少执行两次才能阻塞自己。

*  `shouldParkAfterFailedAcquire`只有在检测到前驱的状态为`SIGNAL`才能返回true，只有true才会执行到`parkAndCheckInterrupt`。
 *  `shouldParkAfterFailedAcquire`返回false后，进入下一次循环，当前线程又会再次尝试获取锁（`p == head && tryAcquire(arg)`）。或者说，每次执行`shouldParkAfterFailedAcquire`，都说明当前循环 尝试过获取锁了，但失败了。
 *  如果刚开始前驱的状态为0，那么需要第一次执行`compareAndSetWaitStatus(pred, ws, Node.SIGNAL)`返回false并进入下一次循环，第二次才能进入`if (ws == Node.SIGNAL)`分支，所以说 至少执行两次。
 *  死循环保证了最终一定能设置前驱为`SIGNAL`成功的。（考虑当前线程一直不能获取到锁）

## parkAndCheckInterrupt ##

既然shouldParkAfterFailedAcquire已经返回了true，那么我现在可以执行parkAndCheckInterrupt了。

private final boolean parkAndCheckInterrupt() { 
            LockSupport.park(this);  //阻塞当前线程
            return Thread.interrupted();
        }

调用完`LockSupport.park(this)`，当前线程就阻塞在这里，直到有别的线程`unpark`了当前线程，或者中断了当前线程。而返回的`Thread.interrupted()`代表当前线程在阻塞的过程中，有没有被别的线程中断过，如果有，则返回true。注意，`Thread.interrupted()`会消耗掉中断的状态，即第一次执行能返回true，但紧接着第二次执行就只会返回false了。

*  如果是别的线程`unpark`了当前线程，那么调用`Thread.interrupted()`返回false。
 *  如果是别的线程中断了当前线程，那么调用`Thread.interrupted()`返回true。

回到acquireQueued的逻辑中，发现一旦当前线程被中断过一次，那么`parkAndCheckInterrupt`就返回了true，那么执行`interrupted = true`，`interrupted`局部变量就一定是true的了。

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);
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())  //这里返回了true，说明上一行也返回了true才会执行到这里
                        interrupted = true;  //这里设置后，会被永久保留
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

再等到当前线程获取锁成功后，那么acquireQueued返回的就一定是true了。再回到acquire的逻辑，发现需要进入if分支，再执行`selfInterrupt()`将中断状态补上，这样下一次`Thread.interrupted()`就能返回true了。为的就是在 回到用户代码之前，把中断状态补上，万一用户需要中断状态呢。

public final void acquire(int arg) { 
            if (!tryAcquire(arg) &&
                acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  //acquireQueued返回了true
                selfInterrupt(); //中断状态补上
        }

# 不公平的、不响应中断的 独占锁的获取 #

其实不公平锁与公平锁之间的差别只会体现在AQS子类的重写方法中，所以我们直接看子类实现就好。使用不公平锁对ReentrantLock来说，还是直接调用`ReentrantLock.lock()`，没有区别。要想使用非公平锁，必须在构造`ReentrantLock`时指定好。

## 观察ReentrantLock的内部类 ##

//ReentrantLock.java
        abstract static class Sync extends AbstractQueuedSynchronizer { 
        	...
            final boolean nonfairTryAcquire(int acquires) { 
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) { 
                    if (compareAndSetState(0, acquires)) { 
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) { 
                    int nextc = c + acquires;
                    if (nextc < 0) // overflow
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }
            ...
    	}
    
    
        static final class NonfairSync extends Sync { 
            private static final long serialVersionUID = 7316153563782823691L;
    
            final void lock() { 
            	// if分支里的逻辑只是一次快速尝试
            	// 它和nonfairTryAcquire里的部分逻辑是一样的
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    acquire(1);
            }
    
            protected final boolean tryAcquire(int acquires) { 
            	// 将nonfairTryAcquire的逻辑直接放在这里，就把公平锁看起来一样了
                return nonfairTryAcquire(acquires);
            }
        }

*  与公平锁相比，非公平锁的lock实现略有不同。公平锁的`lock`实现是直接调用`acquire(1)`，而非公平锁的`lock`实现会先尝试CAS修改state，如果能够将state从0改成1，那么说明当前线程获取锁，既然获取锁，那么便直接插队`setExclusiveOwnerThread(Thread.currentThread())`。如果CAS操作失败，再走正常流程，调用父类函数`acquire(1)`。
 *  再看子类实现`nonfairTryAcquire`，发现和公平锁的实现`tryAcquire`几乎一模一样，除了公平锁需要多判断一下`hasQueuedPredecessors`的返回值，也就是需要判断队列是否等待线程。

其实非公平锁的原理就是：不管等待队列中是否有等待线程，直接竞争获取state，要是获取成功了，就直接设置当前线程为`exclusiveOwnerThread`成员了。这不就是，插了所有等待线程的队嘛。也就是说，非公平锁它可以和队列中的head后继的代表线程同时竞争锁。

public final void acquire(int arg) { 
            if (!tryAcquire(arg) &&  // 非公平锁插队的机会，只有这里tryAcquire的时候
                acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
                selfInterrupt();
        }

但是 非公平锁插队的机会只有在`acquire`里面第一次执行`tryAcquire`的时候，一旦这里`tryAcquire`获取锁失败了，就会进入`acquireQueued`的死循环，在循环之前会将当前线程包装成node放到队尾去，之后在循环中的每次循环，想要执行获取锁的动作（`tryAcquire(arg)`）必须自己是head的后继才可以（`p == head`）。

总结：

*  非公平锁插队的机会只有，`acquire`方法里第一次执行`tryAcquire`的时候，如果这次插队失败，那么它也不可能插队成功了。
 *  公平锁和非公平锁，在进入`acquireQueued`之后，使用起来没有任何区别。

# 响应中断的 独占锁的获取 #

使用响应中断的锁对ReentrantLock来说，是调用`ReentrantLock.lockInterruptibly()`。从下面函数中，可以看到函数都会抛出`InterruptedException`异常，这是我们能看到的第一处不同。

//ReentrantLock.java
        public void lockInterruptibly() throws InterruptedException { 
            sync.acquireInterruptibly(1);
        }
    //AbstractQueuedSynchronizer.java
        public final void acquireInterruptibly(int arg)
                throws InterruptedException { 
            if (Thread.interrupted())
                throw new InterruptedException();
            if (!tryAcquire(arg))
                doAcquireInterruptibly(arg);
        }

`acquireInterruptibly`这个方法与 不响应中断的`acquire`方法 对应。同样的，进入这个方法后，会第一次进行`tryAcquire`尝试。但不同的，此`acquireInterruptibly`函数中，会去检测`Thread.interrupted()`，并抛出异常。

但注意，对于`acquireInterruptibly`这个方法而言，既可以是公平的，也可以是不公平的，这完全取决于`tryAcquire`的实现（即取决于ReentrantLock当初是怎么构造的）。

private void doAcquireInterruptibly(int arg)
            throws InterruptedException { 
            final Node node = addWaiter(Node.EXCLUSIVE);
            boolean failed = true;
            try { 
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return;
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        throw new InterruptedException();
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

而`doAcquireInterruptibly`方法 的相对应的方法为`acquireQueued`方法。观察两个方法的差别很少：

*  `doAcquireInterruptibly`没有返回值，而`acquireQueued`方法有返回值，代表当前线程是否被中断过。
    
     *  `acquireQueued`方法需要有返回值，因为函数调用返回上层后，需要根据返回值来判断是否需要重新设置中断状态，在返回用户代码之前。
     *  `doAcquireInterruptibly`不需要返回值，因为该函数中如果检测到了中断状态，就直接抛出异常就好了。
 *  `doAcquireInterruptibly`方法的finally块是可能会执行到`cancelAcquire(node)`的，而`acquireQueued`方法不可能去执行`cancelAcquire(node)`的。
    
     *  在`doAcquireInterruptibly`方法中，如果线程阻塞在`parkAndCheckInterrupt`这里后，别的线程来中断阻塞线程，阻塞线程会被唤醒，然后抛出异常。本来抛出异常该函数就马上结束掉的，但由于有finally块，所以在结束掉之前会去执行finally块，并且由于`failed`为true，则会执行`cancelAcquire(node)`。

回忆起node有一种`CANCELLED`状态，看来就是为`cancelAcquire(node)`准备的了。

private void cancelAcquire(Node node) { 
            // 避免空指针异常
            if (node == null)
                return;
    
            node.thread = null;
            
            Node pred = node.prev;
            while (pred.waitStatus > 0)  // 循环用来跳过无效前驱
                node.prev = pred = pred.prev;
            // 执行完循环，pred会指向node的有效前驱。
            // 当然，如果node的前驱就是有效的。那么就不需要跳过了。
    
            // pred的后继无论如何都需要取消，因为即使前面循环没有执行，
            // 现在pred的后继（肯定是参数node）也是一个马上取消掉的node。
            // 之后有些CAS操作会尝试修改pred的后继，如果CAS失败，那么说明有别的线程在做
            // 取消动作或通知动作，所以当前线程也不需要更多的动作了。
            Node predNext = pred.next;
    
            // 这里直接使用赋值操作，而不是CAS操作。
            // 如果别的线程在执行这步之后，别的线程将会跳过这个node。
            // 如果别的线程在执行这步之前，别的线程还是会将这个node当作有效节点。
            node.waitStatus = Node.CANCELLED;
    
            // 如果node是队尾，那简单。直接设置pred为队尾，然后设置pred的后继为null
            if (node == tail && compareAndSetTail(node, pred)) { 
                compareAndSetNext(pred, predNext, null);
            // 如果node不是队尾，node则有后继。
            } else { 
                int ws;
                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 { 
                    unparkSuccessor(node);
                }
    
                node.next = node; // help GC
            }
        }

如果node是队尾，那说明node后面没有节点，也就不存在节点需要去唤醒了。

分析node不是队尾的情况，既然不是队尾，说明node后面有节点。如下图所示。  
这里面又有分支，先直接看进入分支要做什么，再来分析进入分支的条件：

*  在if分支里，去做`compareAndSetNext(pred, predNext, next)`，即修复pred的后继，完善双向链表的指针。但这样做有一个前提，就是需要pred的状态已经是SIGNAL的了。
 *  在else分支里，去做`unparkSuccessor(node)`，去唤醒node后继。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 2]  
从上图可以看到，实际意义上，pred的后继已经变成了node后继了。

*  `pred != head`不成立，那么说明pred就是head，执行else分支。node的后继运气爆棚，因为node自己取消掉了，node的后继便成为了等待队列中第一个线程（即成为了head后继），自然需要去唤醒它了（`unparkSuccessor(node)`）。
 *  `pred != head`成立，但`(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))`不成立，执行else分支。
    
     *  第一个条件成立，说明pred并不是head。
     *  第二个条件不成立，里面是`||`，说明是两个子条件都不成立。有下面情况：
        
         *  如果pred的状态是CANCELLED。这似乎有点矛盾，因为之前的for循环已经判断过pred的状态是 <= 0的了，但你要知道多线程环境下，什么都可能发生。很可能从for循环执行到这里的时候，pred又被取消掉了。考虑到pred如果是head后继的话，那么node后继就一下子成为了队列中第一个线程了，所以还是有必要执行`unparkSuccessor(node)`。
         *  如果pred的状态是 <= 0但还不是SIGNAL，但CAS设置pred的状态为SIGNAL却失败了。SIGNAL是作为后继节点被唤醒的标志而存在的，现在居然没有设置成功，所以很有必要执行`unparkSuccessor(node)`。
 *  `pred != head`成立，`(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))`也成立，但`pred.thread != null`不成立，执行else分支。
    
     *  第一个条件成立，说明pred并不是head。
     *  第二个条件成立，里面是`||`，说明是两个子条件要么前真，要么前假后真。
        
         *  如果是前真，那么说明pred的状态已经是SIGNAL。
         *  如果是前假后真，那么说明pred的状态是0或PROPAGATE，且接下来的CAS操作也成功了，即成功设置为SIGNAL。
     *  第三个条件不成立，说明pred变成了一个dummy node了。要么pred是变成head了，要么pred突然被取消了（执行了`node.thread = null`）。这两种情况，前者必须执行`unparkSuccessor(node)`，后者只是有必要执行。
 *  `pred != head`成立，`(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))`也成立，且`pred.thread != null`也成立，只有这里才执行if分支。说明闹钟设置成功，并且设置的node也不是个空节点，那么只需要将pred与node后继相连即可（`compareAndSetNext(pred, predNext, next)`）。

总结一下`cancelAcquire`：

*  如果闹钟设置成功，且闹钟都在node不是一个dummy node，那么将pred与node后继相连，让node后继继续安心睡觉。
 *  如果发现node后继已经是排队的第一个了、发现闹钟没有设置成功、发现闹钟设置成功但闹钟所在节点变空节点，都需要换线node后继。

# 超时的 独占锁的获取 #

使用超时的锁对ReentrantLock来说，是调用`public boolean tryLock(long timeout, TimeUnit unit)`。从下面函数中，可以看到函数都会抛出`InterruptedException`异常，这是我们能看到的第一处不同。

//ReentrantLock.java
        public boolean tryLock(long timeout, TimeUnit unit)
                throws InterruptedException { 
            return sync.tryAcquireNanos(1, unit.toNanos(timeout));//第二个实参，换算得到nano
        }
    //AbstractQueuedSynchronizer.java
        public final boolean tryAcquireNanos(int arg, long nanosTimeout)
                throws InterruptedException { 
            if (Thread.interrupted())
                throw new InterruptedException();
            return tryAcquire(arg) ||
                doAcquireNanos(arg, nanosTimeout);
        }

`tryAcquireNanos`这个方法与 不响应中断的`acquire`方法 对应。同样的，进入这个方法后，会第一次进行`tryAcquire`尝试。但不同的，此`tryAcquireNanos`函数中，会先去检测`Thread.interrupted()`，并抛出异常。

但注意，对于`tryAcquireNanos`这个方法而言，既可以是公平的，也可以是不公平的，这完全取决于`tryAcquire`的实现（即取决于ReentrantLock当初是怎么构造的）。

private boolean doAcquireNanos(int arg, long nanosTimeout)
                throws InterruptedException { 
            if (nanosTimeout <= 0L)//如果时间小于0，直接返回失败
                return false;
            final long deadline = System.nanoTime() + nanosTimeout;//算出“死期”，当死期到了就直接返回失败了
            final Node node = addWaiter(Node.EXCLUSIVE);
            boolean failed = true;
            try { 
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return true;
                    }
                    // 看看你的年龄是否到达了死期
                    nanosTimeout = deadline - System.nanoTime();
                    if (nanosTimeout <= 0L)//小于0，说明死期到了
                        return false;
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        nanosTimeout > spinForTimeoutThreshold)//剩余寿命得大于1ms
                        LockSupport.parkNanos(this, nanosTimeout);
                    if (Thread.interrupted())
                        throw new InterruptedException();
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

将`doAcquireNanos`方法 与不响应中断的`acquireQueued`方法、响应中断的`doAcquireInterruptibly`方法进行对比，发现差别很少，简单的我用注释说明了。

*  每次循环都会检查时间是否到达deadline。
 *  当剩余时间小于`spinForTimeoutThreshold`时，则不能调用`LockSupport.parkNanos`，因为时间太短，反而无法精确控制阻塞时间，所以不如在剩余的时间里一直循环。
 *  `LockSupport.parkNanos`除了会因为别人的park而唤醒，也会因为别人的中断而唤醒，当然最重要的，时间到了，它自己会唤醒。
 *  不管哪种情况，被唤醒后，都会检查中断状态。每个循环都会检查一次。

# 只一次尝试的 非公平的 独占锁的获取 #

只一次尝试的、非公平的独占锁获得对ReentrantLock来说，是调用`ReentrantLock.tryLock()`。而`nonfairTryAcquire`方法就是之前讲过的非公平锁的获取方式。

//ReentrantLock.java
    public boolean tryLock() { 
            return sync.nonfairTryAcquire(1);
        }
    
        abstract static class Sync extends AbstractQueuedSynchronizer { 
            ...
            final boolean nonfairTryAcquire(int acquires) { 
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) { 
                    if (compareAndSetState(0, acquires)) { 
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) { 
                    int nextc = c + acquires;
                    if (nextc < 0) // overflow
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }
            ...
        }

# 总结 #

*  对于独占锁，AQS的state代表代表锁的状态，为0代表没有线程持有锁，非0代表有线程持有了锁。
 *  获得了锁的线程会将自己设置为`exclusiveOwnerThread`。
 *  `addWaiter`负责new出一个包装当前线程的node，`enq`负责将node添加到队尾，如果队尾为空，它还负责添加dummy node。
 *  `acquireQueued`是整个获取锁过程的核心，这里是指它的那个死循环。一般情况下，每次循环做的事就是：尝试获取锁，获取锁失败，阻塞，被唤醒。如果某一次循环获取锁成功，那么之后会返回到用户代码调用处。
 *  `shouldParkAfterFailedAcquire`负责自身的前驱节点的状态设置为`SIGNAL`，这样，当前驱节点释放锁时，会根据`SIGNAL`来唤醒自身。
 *  `parkAndCheckInterrupt`最简单，用来阻塞当前线程。它也会去检查中断状态。

[JUC_]: https://blog.csdn.net/anlian523/article/details/106598910
[20200531181242462.jpg]: https://img-blog.csdnimg.cn/20200531181242462.jpg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020060121565272.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2020060122161137.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200601225441138.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70