ReentrantLock你了解多少（结合Lock、AQS进行讲解）

比眉伴天荒 2023-07-24 14:43 63阅读 0赞

## 写在前面 ##

**如果觉得有所收获，记得的点个关注和点个赞，感谢支持。**  
本篇文章要讲的是`Lock` 接口，重点强调 `ReentrantLock` 类，相关的接口在JUC 包里面，自 JDK 5 起，Java 类库中新提供了 `java.util.concurrent` 包（通常简称为 JUC 包）。Java 中有两种对并发资源加锁的方式，除了 `synchronized` 之外（不清楚的可以查看我之前写过的一篇关于[synchronize文章][synchronize]），还有本篇文章要讲的 `Lock`。`synchronized` 是 JVM 通过底层实现的，而 `Lock` 是通过 JDK 纯粹在软件层面上实现的。

## 先来讲讲 Lock 接口 ##

Lock 类本身是一个接口，对锁进行了规范，Lock 接口的定义如下（我这里删除了源码的注释，这样不占用版面）：

public interface Lock { 
        void lock();
        void lockInterruptibly() throws InterruptedException;
        boolean tryLock();
        boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
        void unlock();
        Condition newCondition();
    }

上面可以看到，Lock 接口一共规范给定了 6 个方法。其中最为常用的，是 `lock()` 方法和 `unlock()` 方法，这两个方法必须成对出现，否则就有可能出现异常，使用逻辑如下：

// 假如已经创建了一个lock对象
    lock.lock();
    try { 
        // ...
    } finally { 
        lock.unlock();
    }

这里使用 `lock` 上锁，与使用 `synchronized` 上锁的效果是相同的，但在使用上从大括号代码块变为 try 代码块，并且一定要使用 finally 语句为 `lock` 对象解锁。可以查阅阿里巴巴的 Java 代码规约，在里面已经说的非常明白了，内容如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center]  
Lock 接口规定了四种上锁，除了上文说到的最传统的 lock() 方法之外，还有以下三种：

*  lockInterruptibly() 会处理线程中断的上锁
 *  tryLock() 尝试上锁并立即返回，上锁成功则 true，上锁失败则 false
 *  tryLock(long time, TimeUnit unit) 尝试一段时间上锁后返回，上锁成功则 true，上锁失败则 false

除以上上锁方法之外，最后还有一个方法 newCondition()，该方法用于协调线程，这个后面再提。

## 讲讲线程相关的知识 ##

在讲解线程中断之前呢，需要来了解一下线程相关的一些知识，我之前写过一篇博文，是有关在Java中如何使用线程，不清楚的可以过去看看，这里讲解线程的使用逻辑，即线程的状态，以及线程中断的逻辑。  
通常意义上线程有六种状态，但依我来看线程实际上只有两种状态：可运行状态、不可运行状态。

*  可运行状态：线程可以运行，但是并不一定正在运行，细分的话可以分为正在运行和等待运行两种状态。
 *  不可运行状态：线程不能运行，可能是主动的（主动等待），也可能是被动的（要用的资源被锁住了）。细分的话能分为三种状态：无限期等待状态、限期等待状态、阻塞状态，前两种是线程自己发起的，第三种是线程被迫的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 1]

对各个状态分别进行解释：

*  `New` 新增：线程刚刚创建（例如 `Thread t = new Thread()`），还没有执行代码
 *  `Runnable` 可运行：线程可以运行（例如 `thread.start()`），但并不代表一定在运行，是否正在运行要看虚拟机和 CPU 的线程调度情况。CPU 将时间划分为 `10-20 ms` 的一个个时间片，在每一个时间片中执行一条线程，到时间就切换（切换地太快导致似乎在并行执行多条线程），这被称为 CPU 在调度线程。在 `Runnable` 状态下，每一条线程都有可能会被执行，但是执行和切换的速度都很快，非要分出来是在执行还是在等待并没有太大的意义。
    
     *  `Ready` 等待运行：等待 CPU 调度
     *  `Running` 正在运行：CPU 正在执行
 *  `Waiting` 无限期等待：线程主动等待，并且不设置等待结束的时间，直到被其他线程“唤醒”（例如 `thread.join()`）。
 *  `Timed Waiting` 限期等待：线程主动等待，但是设置一个等待的时长，到时间就自动唤醒（例如 `thread.sleep(sleepTime)`），在等待的这段时间也可以被其他线程“唤醒”。
 *  `Blocked` 阻塞等待：线程被动等待，因为抢锁失败了，被迫等着（例如使用 `synchronized` 同时让多条线程获取资源，总有线程会被迫等待）。

有关线程状态还可以剖析地更深一些：

*  Java 的 `Thread` 类看似是一个寻常的 Java 对象，实际上可以视为对底层系统操作线程的封装，因此使用 `Thread` 类时不能完全按照面向对象的常规思维来思考，而是要以底层硬件的实现逻辑来思考。
 *  上文我将线程分为了可运行状态和不可运行状态，细分析的话，这实际上是指 CPU 有没有为线程分配时间片。在另外的地方（线程和进程的区别）学习到，线程是操作系统能够调度的最小单位，“能调度的最小单位“这种说法，就是指 CPU 划分出一个个时间片，每一个时间片”调度“一个线程。可运行状态指的是 CPU 能够调度线程，而不可运行状态指的是 CPU 不能调度线程，比如某一个线程中执行 `Thread.sleep(sleepTime)` 方法，那么这个线程进入 `Timed Waiting` 状态，在这种状态下 CPU 不再调度该线程，直到该线程休眠时间结束，回到 `Runnable` 状态，CPU 才可以调度该线程，这个行为被称作线程的“挂起”。
 *  线程通过 `sleep(time)` 和 `wait(time)` 方法都可以进入 `Timed Waiting` 状态，CPU 都不再会调度该线程，但是 `sleep` 的一方不会释放锁，`wait` 的一方会释放锁。其他线程如果需要正在 `sleep` 的线程的资源，将一直阻塞到那个线程醒来再释放资源。
 *  只有使用 `synchronized` 才能导致线程进入 `Blocked` 状态，线程从 `Waiting` 状态无法直接进入 `Runnable` 状态，只能先进入 `Blocked` 状态去获取锁。（顺便一提，进入 `Waiting` 状态的 `wait()、notify()、notifyAll()` 方法，只能在 `synchronized` 代码块中使用）

线程中断，这里的“中断”是一个颇有迷惑性的词语，它并不是指线程就此停止，而是指线程收到了一个“中断信号”，线程应该根据这个信号来自行了断一些事情（但是收到中断信号也可以不处理）。比如，线程 1 向线程 2 发送了一条中断信息，线程 2 的中断状态发生了改变，线程 2 根据中断状态来进行逻辑处理。所以我认为，中断是线程间通信的一种方式，通信的内容是“建议另一条线程停止行为”，但是线程并不一定采取意见，即使采取意见也绝不是终止线程，而是停止某个一直重复运行的行为，继续执行后续的代码。我目前所见，中断有两种使用场景：

*  线程根据中断状态，停止某个循环（例如下面这段伪代码）

while(还没中断){ 
        循环执行
    }
    中断了，进行后续操作

*  如果线程处于阻塞、限期等待或者无限期等待状态，那么就会抛出 `InterruptedException`，从而提前结束该线程，但是不能中断 `I/O` 阻塞和 `synchronized` 锁阻塞。这里的用法是，当线程处于不可运行状态时（暂停 CPU 调度），以异常的形式，强制让线程处理中断，以恢复回到可运行状态（CPU 可调度）。虽然这是在处理异常，但实际上并不是指程序有什么错误，而是代表一种强制手段：必须要对中断进行处理。再换句话说，这是一种恢复线程状态，停止发呆的一种机制。

try { 
        // 当前线程休眠1秒
        Thread.sleep(1000);
    } catch (InterruptedException e) { 
        // 线程中断，不让继续休眠了，处理后续的业务逻辑
    }

线程中断有三个相关方法：

<table> 
 <thead> 
  <tr> 
   <th>API</th> 
   <th>介绍</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>public void interrupt()</td> 
   <td>中断线程</td> 
  </tr> 
  <tr> 
   <td>public boolean isInterrupted()</td> 
   <td>查看线程是否中断</td> 
  </tr> 
  <tr> 
   <td>public static boolean interrupted()</td> 
   <td>静态方法，查看当前线程是否中断的同时，清除中断状态，即如果线程中断，执行之后将不再处于中断状态</td> 
  </tr> 
 </tbody> 
</table>

中断的源码，以及阻塞状态下的线程抛出中断异常的原理，这里暂不考究了。在此只掌握到两点即可：

*  线程中断不代表线程活动终止
 *  线程中断的基本原理，是给线程的中断标志位赋 true

## 聊一聊AQS ##

AQS 可以算是 JUC 包的核心，一大片并发类，包括要学习的 `ReentrantLock` 锁，都是以 AQS 为内核，不了解 AQS 则无法继续学习。

AQS 的全称是 `AbstractQueuedSynchronizer`（抽象队列同步器，中文一般简称“队列同步器”），它的作用正如其名，是一个队列，需要同步的线程们在队列里排队，每次让一个线程占用资源，剩下的线程在队列同步器里待命。这样的设计实现了这种效果：当多个线程争抢资源时，保证只会有一条线程在运行，其他线程都在等待队列里等候安排。打开 AQS 接口看源码，会看到多如牛毛的方法，初识 AQS 如果从这些方法着手，就可以准备去世了，因此我们从 AQS 的成员变量着手，对 AQS 进行猜测性学习。以下代码部分，基本全部参考自[《一行一行源码分析清楚 AbstractQueuedSynchronizer》][AbstractQueuedSynchronizer]，这篇博文写的真的非常好

AQS 重要的成员变量有四个，分别是：

// 头结点，你直接把它当做【当前持有锁的线程】可能是最好理解的
    private transient volatile Node head;
    
    // 阻塞的尾节点，每个新的节点进来，都插入到最后，也就形成了一个链表
    private transient volatile Node tail;
    
    // 这个是最重要的，代表当前锁的状态，0代表没有被占用，大于 0 代表有线程持有当前锁
    // 这个值可以大于 1，是因为锁可以重入，每次重入都加上 1
    private volatile int state;
    
    // 代表当前持有独占锁的线程（该变量继承自父类），举个最重要的使用例子
    // 因为锁可以重入，reentrantLock.lock()可以嵌套调用多次，所以每次用这个来判断当前线程是否已经拥有了锁
    // if (currentThread == getExclusiveOwnerThread()) {state++}
    private transient Thread exclusiveOwnerThread;

AQS 接口中定义了一个内部类：Node，这个类是 AQS 队列的基本构成元素，即并发线程们在 AQS 队列里等候时，都是装在这个 Node 对象里排序的。Node 类源码如下：

static final class Node { 
        // 标识节点当前在共享模式下
        static final Node SHARED = new Node();
        // 标识节点当前在独占模式下
        static final Node EXCLUSIVE = null;
    
        // ======== 下面的几个int常量是给waitStatus用的 ===========
        // 代表此线程取消了争抢这个锁
        static final int CANCELLED = 1;
        // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒
        static final int SIGNAL = -1;
        // 本文不分析condition
        static final int CONDITION = -2;
        // 同样的不分析，略过吧
        static final int PROPAGATE = -3;
        // =====================================================
    
        // 取值为上面的1、-1、-2、-3，或者0(以后会讲到)
        // 这么理解，暂时只需要知道如果这个值 大于0 代表此线程取消了等待，
        // ps: 半天抢不到锁，不抢了，ReentrantLock是可以指定timeouot的。。。
        volatile int waitStatus;
        // 前驱节点的引用
        volatile Node prev;
        // 后继节点的引用
        volatile Node next;
        // 这个就是线程本尊
        volatile Thread thread;
    }

Node 类的代码容易看得人一头雾水，初学时应当将其视为一个普通的链表节点，它必须需要

*  Node prev：指向前个节点
 *  Node next：指向后个节点
 *  Thread Thread：本节点需要存储的内容

除此之外该节点还有一个状态位：

*  int waitStatus：节点状态，在之后的代码中很重要

Node 类定义的其他内容不用太过纠结，看之后的代码会懂。根据学习这个类，以及参考学习其他 AQS 相关的博文，可以大概知道 AQS 队列的基本结构和设计逻辑是这样的：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 2]  
看图应该就能明白 AQS 的数据结构，需要注意的是，head 并不在 AQS 的阻塞队列当中。以下部分是 AQS 的源码分析，这部分的内容很难，可以不看，不会影响到 Lock 接口的学习。之前的代码中说过，使用 Lock 接口上锁的基本步骤是：

lock.lock();		--> AQS#acquire()
    try { 
        // ...
    } finally { 
        lock.unlock();	--> AQS#release()
    }

实际上，`lock()` 和 `unlock()` 方法的原理，是使用 AQS 的 `acquire()` 和 `release()` 方法实现的，因此我们来粗略地学习这两个方法，并大致了解 AQS 的原理。（以下代码说明均为简略版，查看详细代码说明请参见上述博文）

#### 上锁（新线程加入队列） ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 3]

#### 解锁（老线程执行完毕，传唤下一个线程） ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 4]  
AQS 的具体实现代码，我自认为是又长又难的，因此不把全部代码整理出来了，只在此记录一些点吧：

*  AQS 中有大量的方法，是为了处理并发的，例如队列还是空的，同时有两个线程进来申请锁，如何来让一个线程拿到锁，另一个线程去队列里排队等候。AQS 解决并发问题的原理是 CAS（CAS 的原理去看上篇介绍 synchronized 的博文），AQS 去调用 JDK5 刚刚出现的 `sun.misc.Unsafe` 类里面的方法，这个类对 CPU 的 CAS 指令进行了封装。
 *  进入阻塞队列排队的线程会被挂起，而唤醒的操作是由前驱节点完成的。当占用锁的线程结束，调用 `unlock()` 方法，此时 AQS 会去队列里唤醒排在最前面的节点线程。
 *  AQS 接口确定了队列同步的主要逻辑，也就是上锁时线程先尝试获取锁，失败则加入队列；解锁时队列先尝试解除锁，如果解锁成功则唤醒后继节点。但是尝试获取锁和尝试解除锁这两个操作，都是交由子类去实现的。这就使得 AQS 框架确立了基础的并发队列机制，但锁的形式可以有各种不同。实际上每个锁（每个 AQS 接口的实现类）就是在重写 AQS 的 `tryAcquire()` 和 `tryRelease()` 方法，其他的都依赖于 AQS 接口代码。
 *  AQS 有两个很重要的变量，分别是队列的状态 `state`，以及队列节点的状态 `waitStatus`。
    
     *  `state`：0 代表锁没有被占用，1 代表有线程正在占用锁，1 往上代表有线程正在重入占用锁
     *  `waitStatus`：0 代表初始化，大于 0 代表该节点取消了等待，-1 代表后继节点需要被唤醒

## ReentrantLock ##

不容易呀，终于到了ReentrantLock，ReentrantLock 的字面意义是可重入锁，代表线程可以多次执行 `lock()` 方法占有锁，不会导致死锁问题。ReentrantLock 允许公平锁，只要在构造方法中传入 true（`new ReentrantLock(true)`）即可。公平锁的意思是，当多个线程获取锁时，按照先来后到的顺序，先申请锁的线程一定先得到锁，后申请锁的线程一定后得到锁。如果是非公平锁，那么各个线程获取到锁的顺序是“随机”的。对于 ReentrantLock 的非公平锁而言，后到的线程可以先试着获取一次锁，获取到了就直接返回，获取不到就跟公平锁一样在后面排队。ReentrantLock 实现公平锁和非公平锁的方式，是在内部维护两种 AQS 队列。

// 非公平锁（Sync是一个AQS队列）
    static final class NonfairSync extends Sync { ...}
    // 公平锁
    static final class FairSync extends Sync { ...}

经过刚才对 AQS 的学习，我们知道学习锁实际上只需要看 tryAcquire() 和 tryRelease() 方法，其他都交由 AQS 接口就可以了。

### 上锁 tryAcquire() ###

#### 公平锁 ####

// 尝试直接获取锁，返回值是boolean，代表是否获取到锁
    // 返回true：1.没有线程在等待锁；2.重入锁，线程本来就持有锁，也就可以理所当然可以直接获取
    protected final boolean tryAcquire(int acquires) { 
        final Thread current = Thread.currentThread();
        int c = getState();
        // state == 0 此时此刻没有线程持有锁
        if (c == 0) { 
            // 虽然此时此刻锁是可以用的，但是这是公平锁，既然是公平，就得讲究先来后到，
            // 看看有没有别人在队列中等了半天了
            if (!hasQueuedPredecessors() &&
                // 如果没有线程在等待，那就用CAS尝试一下，成功了就获取到锁了，
                // 不成功的话，只能说明一个问题，就在刚刚几乎同一时刻有个线程抢先了 =_=
                // 因为刚刚还没人的，我判断过了
                compareAndSetState(0, acquires)) { 
    
                // 到这里就是获取到锁了，标记一下，告诉大家，现在是我占用了锁
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        // 会进入这个else if分支，说明是重入了，需要操作：state=state+1
        // 这里不存在并发问题
        else if (current == getExclusiveOwnerThread()) { 
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        // 如果到这里，说明前面的if和else if都没有返回true，说明没有获取到锁
        // 回到上面一个外层调用方法（AQS的acquire()方法）继续看:
        // if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 
        // selfInterrupt();
        return false;
    }

#### 非公平锁 ####

protected final boolean tryAcquire(int acquires) { 
        // 调用了nonfairTryAcquire()方法，往下看
        return nonfairTryAcquire(acquires);
    }
    
    final boolean nonfairTryAcquire(int acquires) { 
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) { 
            // 与公平锁相比，只有这里有区别
            // 非公平锁不会先判断AQS队列中是否有等候的节点，而是直接试着获取一次锁
            // 如果这次尝试获取不到，则和公平锁一样尾插队列
            if (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;
    }

#### 公平锁和非公平锁只有两点区别 ####

*  非公平锁实际上会先 CAS 获取一次锁，如果失败则调用 AQS 的 `acquire()` 方法（这段上面没提）

// 非公平锁的lock()方法（会先CAS获取一次锁，获取不到再走AQS接口）
    final void lock() { 
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    
    // 公平锁的lock()方法
    final void lock() { 
        acquire(1);
    }

*  在首次试着获取锁失败的情况下，非公平锁会在 `tryAcquire()` 方法中再试着获取一次锁，但是公平锁会严格地按照先来后到的顺序获取

可以总结出来，非公平锁比公平锁多尝试获取了两次锁，如果成功就不用进入队列了。这样可以提高并发的线程吞吐量，但是有可能导致先等待的线程一直获取不到锁。

### 解锁 tryRelease() ###

公平锁和非公平锁，共用一套解锁方法，也就是 `Lock#unlock() -> AQS#release() -> Lock#tryRelease() -> AQS#unparkSuccessor()`，其中 `tryRelease()` 方法是交由实现类 ReentrantLock 去重写的（不明白的话回到上面看一看 AQS 的解锁逻辑）。ReentrantLock 重写的 `tryRelease()` 方法的代码如下：

protected final boolean tryRelease(int releases) { 
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        // 是否完全释放锁
        boolean free = false;
        // 处理重入的问题，如果c==0，也就是说没有嵌套锁了，可以释放了，否则还不能释放掉
        if (c == 0) { 
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

ReentrantLock 作为可重入锁，每次上锁就使 AQS 队列的状态（初始化是 0）增加 1，解锁使状态减少 1，如果 AQS 队列的状态变为 0 了，就代表没有线程持有锁。

## ReentrantLock使用 ##

这里模拟售票，通过ReentrantLock的方式实现线程的安全

public class LockMain { 
        public static void main(String[] args) { 
            Window window = new Window();
            Thread thread1 = new Thread(window);
            Thread thread2 = new Thread(window);
            Thread thread3 = new Thread(window);
            thread1.start();
            thread2.start();
            thread3.start();
        }
    }
    
    
    /** * 售票窗口 */
    class Window implements Runnable{ 
    
        private volatile int num = 100;
        ReentrantLock lock = new ReentrantLock();
        @Override
        public void run() { 
            while (true){ 
                lock.lock();
                try { 
                    if (num > 0){ 
                        System.out.println(Thread.currentThread().getName()+"窗口在售票,票号为"+ num);
                        num --;
                    }else { 
                        break;
                    }
                }finally { 
                    lock.unlock();
                }
    
            }
        }
    }

[synchronize]: https://dengbocong.blog.csdn.net/article/details/105303316
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center]: /images/20230528/53500fee1391414783194ae0718015d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20230528/6f1546f849ff4fe99c2774bd294bffa5.png
[AbstractQueuedSynchronizer]: https://www.javadoop.com/post/AbstractQueuedSynchronizer
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20230528/3b93198d9b6641f49ce231c5247490fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20230528/23dc0a7ef93948ab81994a2b35329b5f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20230528/6824a3ce36f2448096454a0f23e2d392.png