ReentrantLock 和 AQS解读

harife

已于 2022-05-24 11:33:33 修改

阅读量947

点赞数 1

分类专栏：高并发文章标签： java 开发语言

于 2022-05-23 10:38:05 首次发布

原文链接：https://www.jianshu.com/p/d589e942afd4

版权

高并发专栏收录该内容

1 篇文章 0 订阅

订阅专栏

ReentrantLock 和 AQS 的关系

首先我们以大家最熟悉的方式带你进入这个核武器库的大门，Java 并发包下的 ReentrantLock大家肯定很熟悉了。

基本上学过Java 的都知道ReentrantLock，下面我就不多说了直接上一段代码。

ReentrantLock lock = new ReentrantLock();
try {
    lock.lock(); // 加锁

    // 业务逻辑代码

} finally {
    lock.unlock(); // 释放锁
}

这段代码大家应该很熟悉了，无非就是获取一把锁，加锁和释放锁的过程。

有同学就问了这和AQS有毛关系呀！别着急，告诉你关系大着去了。在Java并发包中很多锁都是通过AQS来实现加锁和释放锁的过程的，AQS就是并发包基础。

例如：ReentrantLock、ReentrantReadWriteLock 底层都是通过AQS来实现的。

那么AQS到底为何物尼？别急，我们一步一来揭开其神秘的面纱。

AQS 的全称 AbstractQueuedSynchronizers抽象队列同步器，给大家画三张图来说明其在Java 并发包的地位、长啥样、和ReentrantLock 的关系。

通过此类图可以彰显出了AQS的地位、上层锁实现基本都是通过其底层来实现的。

有没有被忽悠的感觉？你没看错AQS就长这个鸟样。说白了其内部就是包含了三个组件

state 资源状态
exclusiveOwnerThread 持有资源的线程
CLH 同步等待队列。

在看这张图现在明白ReentrantLock 和 AQS 的关系了吧！大白话说就是ReentrantLock其内部包含一个AQS对象（内部类），AQS就是ReentrantLock可以获取和释放锁实现的核心部件。

ReentrantLock 加锁和释放锁底层原理实现

好了！经过上面的介绍估计大家已经对AQS混了个脸熟，下面我们就来说说这一段代码。

ReentrantLock lock = new ReentrantLock();
try {
    lock.lock(); // 加锁

    // 业务逻辑代码

} finally {
    lock.unlock(); // 释放锁
}

这段代码加锁和释放锁到底会发生什么故事尼？

很简单在AQS 内部有一个核心变量（volatile）state 变量其代表了加锁的状态，初始值为0。

另外一个重要的关键 OwnerThread 持有锁的线程，默认值为null

接着线程1过来通过lock.lock()方式获取锁，获取锁的过程就是通过CAS操作volatile 变量state 将其值从0变为1。

如果之前没有人获取锁，那么state的值肯定为0，此时线程1加锁成功将state = 1。

线程1加锁成功后还有一步重要的操作，就是将OwnerThread 设置成为自己。如下图线程1加锁过程。

其实到这大家应该对AQS有个大概认识了，说白了就是并发包下面的一个核心组件，其内部维持state变量、线程变量等核心的东西，来实现加锁和释放锁的过程。

大家有没有意识到不管是ReentrantLock还是ReentrantReadWriteLock 等为什么都是Reentrant 开头尼？

从单词本身意思也能看出，Reentrant 可重入的意思，也就说其是一个可重入锁。

可重入锁

就是你可以对一个 ReentrantLock 进行多次的lock() 和 unlock() 操作，也就是可以对一个锁加多次，叫做可重入锁。来一段代码直观感受下。

ReentrantLock lock = new ReentrantLock();
try {
    lock.lock(); // 加锁1

    // 业务逻辑代码
    lock.lock() // 加锁2
    
    // 业务逻辑代码
    
    lock.lock() // 加锁3

} finally {
    lock.unlock(); // 释放锁3
    lock.unlock(); // 释放锁2
    lock.unlock(); // 释放锁1
}

作者：阅历笔记

注意：释放锁是由内到外依次释放的，不可缺少。

问题又来了？ReentrantLock 内部又是如何来实现的尼？

说白了！还是我们AQS这个核心组件帮我实现的，很 easy~ 上述两个核心变量 state 和 OwnerThread 还记得吧！

重入就是判断当前锁是不是自己加上的，如果是，就代表自己可以再次上锁，每重入一次就是将state值加1。就是这么简单啦！！！

说完了可重入我们再来看看锁的互斥又是如何实现的尼？

此时线程2也跑过来想加锁，CAS操作尝试将 state 从0 变成 1，哎呀！糟糕state已经不是0了，说明此锁已经被别人拿到了。

接着线程2想？？？这个锁是不是我以前加上的，瞅瞅 OwnerThread=线程1 哎！明显不是自己上的，悲催加锁失败了～～～。来张图记录下线程2的悲苦经历。

可是线程2加锁失败将何去何从尼？

线程2：想，要是有个地方让我休息下，等线程1释放锁后通知我下再来从新尝试上锁就好了。

这时我们的核心部件AQS又登场了！

AQS: OK！好吧！那我就给你提供一个落脚地吧（CLH）进去待着吧！一会让线程1叫你。

线程2: 屁颠屁颠的就去等待区小憩一会去了。同样来张图记录下线程2高兴样。

此时线程1业务执行完了，开始释放锁

将state值改为0
将OwnerThread 设为null
通知线程2锁我已经用完了，该你登场了

线程2一听，乐坏了！立马开始尝试获取锁，CAS 尝试将 state 值设为 1 ，如果成功将OwnerThread设为自己线程2。
此时线程2成功获取到了锁，再来张图瞅瞅。

Reentrantkock总结

用一句话总结下：AQS就是Java并发包下的一个基础组件，用来实现各种锁和同步组件的，其核心分为三个组件。

Volatile state 变量
OwnerThread 加锁线程
CLH 同步等待队列

等并发核心组件。

AQS的CLH

同步队列

一个FIFO双向队列，队列中每个节点等待前驱节点释放共享状态（锁）被唤醒就可以了。

AQS如何使用它？

AQS依赖它来完成同步状态的管理，当前线程如果获取同步状态失败时，AQS则会将当前线程已经等待状态等信息构造成一个节点（Node）并将其加入到CLH同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点唤醒（公平锁），使其再次尝试获取同步状态。

Node节点面貌？

static final class Node {
        // 节点分为两种模式： 共享式和独占式
        /** 共享式 */
        static final Node SHARED = new Node();
        /** 独占式 */
        static final Node EXCLUSIVE = null;

        /** 等待线程超时或者被中断、需要从同步队列中取消等待（也就是放弃资源的竞争），此状态不会在改变 */
        static final int CANCELLED =  1;
        /** 后继节点会处于等待状态，当前节点线程如果释放同步状态或者被取消则会通知后继节点线程，使后继节点线程的得以运行 */
        static final int SIGNAL    = -1;
        /** 节点在等待队列中，线程在等待在Condition 上，其他线程对Condition调用singnal()方法后，该节点加入到同步队列中。 */
        static final int CONDITION = -2;
        /**
         * 表示下一次共享式获取同步状态的时会被无条件的传播下去。
         */
        static final int PROPAGATE = -3;

        /**等待状态*/
        volatile int waitStatus;

        /**前驱节点 */
        volatile Node prev;

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

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

        /**链接下一个等待状态 */
        Node nextWaiter;
        
        // 下面一些方法就不贴了
    }

CLH同步队列的结构图

这里是基于CAS（保证线程的安全）来设置尾节点的。

入列操作

如上图了解了同步队列的结构，我们在分析其入列操作在简单不过。无非就是将tail（使用CAS保证原子操作）指向新节点，新节点的prev指向队列中最后一节点（旧的tail节点），原队列中最后一节点的next节点指向新节点以此来建立联系，来张图帮助大家理解。

源码
源码我们可以通过AQS中的以下几个方法来了解下
addWaiter方法

private Node addWaiter(Node mode) {
// 以给定的模式来构建节点， mode有两种模式 
//  共享式SHARED， 独占式EXCLUSIVE;
  Node node = new Node(Thread.currentThread(), mode);
    // 尝试快速将该节点加入到队列的尾部
    Node pred = tail;
     if (pred != null) {
        node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        // 如果快速加入失败，则通过 anq方式入列
        enq(node);
        return node;
    }

先通过addWaiter(Node node)方法尝试快速将该节点设置尾成尾节点，设置失败走enq(final Node node)方法

private Node enq(final Node node) {
// CAS自旋，直到加入队尾成功        
for (;;) {
    Node t = tail;
        if (t == null) { // 如果队列为空，则必须先初始化CLH队列，新建一个空节点标识作为Hader节点,并将tail 指向它
            if (compareAndSetHead(new Node()))
                tail = head;
            } else {// 正常流程，加入队列尾部
                node.prev = t;
                    if (compareAndSetTail(t, node)) {
                        t.next = node;
                        return t;
                }
            }
        }
    }

通过“自旋”也就是死循环的方式来保证该节点能顺利的加入到队列尾部，只有加入成功才会退出循环，否则会一直循序直到成功。

上述两个方法都是通过compareAndSetHead(new Node())方法来设置尾节点，以保证节点的添加的原子性（保证节点的添加的线程安全。）

acquireQueued（final Node, int arg）

final boolean acquireQueued(final Node node, int arg) {
    // 是否拿到资源
    boolean failed = true;
        try {
            // 标记等待过程中是否被中断过
            boolean interrupted = false;
            // 自旋
            for (;;) {
               // 获取当前节点的前驱节点
               final Node p = node.predecessor();
               // 如果其前驱节点为head 节点，说明此节点有资格去获取资源了。（可能是被前驱节点唤醒,也可能被interrupted了的）
               if (p == head && tryAcquire(arg)) {
               // 拿到资源后将自己设置为head节点，
                   setHead(node);
                  // 将前驱节点 p.next = nul 在setHead(node); 中已经将node.prev = null 设置为空了，方便GC回收前驱节点，也相当于出列。
                  p.next = null; // help GC
                  failed = false;
                  return interrupted;
              }
              // 如果不符合上述条件，说明自己可以休息了，进入waiting状态，直到被unpark()
              if (shouldParkAfterFailedAcquire(p, node) &&
              parkAndCheckInterrupt())
              interrupted = true;
            }
     } finally {
        if (failed)
            cancelAcquire(node);
     }
}

当前节点的线程在‘死循环’中尝试获取同步状态，前提是只有其前驱节点为head节点时才有尝试获取同步状态的资格，否则继续在同步队列中等待被唤醒。

Why?

因为只有head是成功获取同步状态的节点，而head节点的线程在释放同步状态的同时，会唤醒后继节点，后继节点在被唤醒后检测自己的前驱节点是否是head节点，如果是则会通过自旋尝试获取同步状态。
维护CLH的FIFO原则。该方法中节点自旋获取同步状态。

shouldParkAfterFailedAcquire(Node pred, Node node)

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        // 拿到前驱的状态
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
           // 如果已经告诉过前驱节点，获取到资源后通知自己下，那就可以安心的去休息了。
            return true;
        if (ws > 0) {
           // 如果前驱节点放弃了，那就循环一直往前找，直到找到一个正常等待状态的节点，排在他后面
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
        // 如果前驱状态为0 或者 PROPAGATE 状态， 那就把前驱状态设置成SIGNAL，告诉它获取资源后通知下自己。
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

此方法检测自己前驱节点是否时head节点，如果是则尝试获取同步状态，不是则再次回到同步队列中找到一个舒适地方（也就是找到一个waitStatus > 0 的节点，排在他后面继续等待）休息，并告诉前驱节点释放同步状态或者被中断后通知自己下（compareAndSetWaitStatus(pred, ws, Node.SIGNAL)）。

注意：在此查找一个舒适区域休息（waitStatus > 0 的节点）时那些不符合条件的节点会形成了一个无效链，等待GC回收。

private final boolean parkAndCheckInterrupt() {
        // 调用park方法是线程进入waiting 状态
        LockSupport.park(this);
        //如果被唤醒查看是不是被中断状态
        return Thread.interrupted();
    }

最后调用park方法使节点中线程进入wating状态，等待被unpark()唤醒。