java之ReentrantLock

最新推荐文章于 2025-07-10 17:18:13 发布

原创最新推荐文章于 2025-07-10 17:18:13 发布 · 294 阅读

3 ·

CC 4.0 BY-SA版权

学习笔记专栏收录该内容

36 篇文章

订阅专栏

本文深入解析Java中的Lock接口与ReentrantLock实现原理，探讨显示锁与隐式锁的区别，以及AQS框架如何支撑多种锁机制。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Lock接口

Synchronized属于隐式锁，即锁的释放和获取都是隐式的。而我们接下来介绍的是显示锁Lock。JDK1.5中，在JAVA JUC包中添加了Lock接口，该接口提供了lock（）方法和unlock（）方法，以支持显示的加锁和解锁。需要注意的是unlock方法需要在finally中实现，不然会因为异常的出现导致各种并发问题。

public interface Lock {
    //加锁
    void lock();

    //解锁
    void unlock();

    //可中断获取锁，与lock()不同之处在于可响应中断操作，即在获
    //取锁的过程中可中断，注意synchronized在获取锁时是不可中断的
    void lockInterruptibly() throws InterruptedException;

    //尝试非阻塞获取锁，调用该方法后立即返回结果，如果能够获取则返回true，否则返回false
    boolean tryLock();

    //根据传入的时间段获取锁，在指定时间内没有获取锁则返回false，如果在指定时间内当前线程未被中并断获取到锁则返回true
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    //获取等待通知组件，该组件与当前锁绑定，当前线程只有获得了锁
    //才能调用该组件的wait()方法，而调用后，当前线程将释放锁。
    Condition newCondition();

可见Lock对象锁还提供了synchronized所不具备的其他同步特性，如可中断锁的获取(synchronized在等待获取锁时是不可中的)，超时中断锁的获取，等待唤醒机制的多条件变量Condition等，这也使得Lock锁在使用上具有更大的灵活性。下面进一步分析Lock的实现类重入锁ReetrantLock。

可重入锁ReentrantLock

重入锁ReentrantLock是Lock接口的具体实现类，JDK1.5中引入。ReentrantLock是一种支持重入的锁，即该锁支持一个线程对资源重复加锁，同时支持公平锁和非公平锁，所谓公平锁，即先对锁进行请求一定会先获取到锁。一般而言，非公平所效率高于公平锁。需要注意的是，ReentrantLock支持对同一资源重复加锁，但是加锁几次就需要解锁几次，这样才能成功释放锁。

并发组件AQS与ReentrantLock

一、AQS工作原理概要

AQS(AbstractQueuedSynchronizer)又称为队列同步器，它是构建锁和其它同步组件的框架基础，内部通过一个int型成员变量state来控制同步状态，当status=0时，则说明没有任何线程持有该锁，当status=1时，则说明有线程目前正在访问共享变量，其它线程必须进入同步队列等待。AQS通过内部类Node构成FIFO的同步队列来完成获取锁的排队工作，同时利用内部类ConditionObject构建等待队列，当Condition调用wait方法后，线程将会进入等待队列中，而当Condition调用singal方法后，线程讲从等待队列转移到同步队列进行锁竞争。注意这里有两种队列，同步队列和等待队列，同步队列指线程试图获取锁而排队等待的队列；等待队列为线程通过Condition调用await方法释放锁后，进入的等待队伍。这里先研究AQS的同步队列模型：

AQS同步器中有首尾指针，有status状态标识等等。其中头指针head指向头结点，不存储信息。而tail指向双链表末尾。其中Node结点为对每一个访问同步代码的线程的封装，从Node的数据结构可以看出（蓝色），Node包含了线程的状态，是否被阻塞，是否被等待唤醒，是否已经被取消，设置pre和next结点方便在释放锁后唤醒下一个正在等待的线程。

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;
    //条件状态，
    static final int CONDITION = -2;
    //在共享模式中使用表示获得的同步状态会被传播
    static final int PROPAGATE = -3;

    //等待状态,存在CANCELLED、SIGNAL、CONDITION、PROPAGATE 4种
    volatile int waitStatus;

    //同步队列中前驱结点
    volatile Node prev;

    //同步队列中后继结点
    volatile Node next;

    //请求锁的线程
    volatile Thread thread;

    //等待队列中的后继结点，这个与Condition有关，稍后会分析
    Node nextWaiter;

    //判断是否为共享模式
    final boolean isShared() {
        return nextWaiter == SHARED;
    }

    //获取前驱结点
    final Node predecessor() throws NullPointerException {
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }

    //.....
}

其中SHARED和EXCLUSIVE常量分别代表共享模式和独占模式，所谓共享模式即一个锁运行多个线程同时操作，如信号量Semaphore采用的就是AQS的共享模式实现，而独占模式就是同一时间段只能有一个线程对共享资源进行操作，如ReentrantLock。变量waitStatus则表示当前被封装成Node结点的线程状态，共有4中CANCLELLED,SINGAL,CONDITON，PROPAGATE。

CANCELLED；值为1，在同步队列中等待的线程等待超时或被中断，需要从Node队列中取消该Node结点，即结束状态，进入该状态的节点不会再变化。

SIGNAL：值为-1，被标识为等待唤醒状态的后继节点，当其结点的线程释放了同步锁或被取消，将会通知该后继结点线程执行。说白了就是备胎，就是处于唤醒状态，只要前继结点释放锁，就会通知标识为SINGAL状态的后继结点的线程执行。、

CONDITON：值为-2，与Condition相关，该标识的结点处于等待队列中，结点的线程等待在Condition上，当其他线程调用了Condition的Singal（）方法后，Condition状态的结点又等待队列转移到同步队列，等待获取同步锁。

PROPAGATE：值为-3，与共享模式相关，在共享模式中，在该状态标识的节点的线程处于可运行状态。

0状态：值为0，代表初始化状态。

AbstractOwnableSynchronizer：抽象类，定义了存储独占当前锁的线程和获取的方法
AbstractQueuedSynchronizer：抽象类，AQS框架核心类，其内部以虚拟队列的方式管理线程的锁获取与锁释放，其中获取锁(tryAcquire方法)和释放锁(tryRelease方法)并没有提供默认实现，需要子类重写这两个方法实现具体逻辑，目的是使开发人员可以自由定义获取锁以及释放锁的方式。
Node：AbstractQueuedSynchronizer 的内部类，用于构建虚拟队列(链表双向链表)，管理需要获取锁的线程。
Sync：抽象类，是ReentrantLock的内部类，继承自AbstractQueuedSynchronizer，实现了释放锁的操作(tryRelease()方法)，并提供了lock抽象方法，由其子类实现。
NonfairSync：是ReentrantLock的内部类，继承自Sync，非公平锁的实现类。
FairSync：是ReentrantLock的内部类，继承自Sync，公平锁的实现类。
ReentrantLock：实现了Lock接口的，其内部类有Sync、NonfairSync、FairSync，在创建时可以根据fair参数决定创建NonfairSync(默认非公平锁)还是FairSync,ReentrantLock所有方法都通过间接调用AQS和Sync及其子类来实现。

从上述类图可以看出AQS是一个抽象类，但请注意其源码中并没一个抽象的方法，这是因为AQS只是作为一个基础组件，并不希望直接作为直接操作类对外输出，而更倾向于作为基础组件，为真正的实现类提供基础设施，如构建同步队列，控制同步状态等，事实上，从设计模式角度来看，AQS采用的模板模式的方式构建的，其内部除了提供并发操作核心方法以及同步队列操作外，还提供了一些模板方法让子类自己实现，如加锁操作以及解锁操作，为什么这么做？这是因为AQS作为基础组件，封装的是核心并发操作，但是实现上分为两种模式，即共享模式与独占模式，而这两种模式的加锁与解锁实现方式是不一样的，但AQS只关注内部公共方法实现并不关心外部不同模式的实现，所以提供了模板方法给子类使用，也就是说实现独占锁，如ReentrantLock需要自己实现tryAcquire()方法和tryRelease()方法，而实现共享模式的Semaphore，则需要实现tryAcquireShared()方法和tryReleaseShared()方法，这样做的好处是显而易见的，无论是共享模式还是独占模式，其基础的实现都是同一套组件(AQS)，只不过是加锁解锁的逻辑不同罢了，更重要的是如果我们需要自定义锁的话，也变得非常简单，只需要选择不同的模式实现不同的加锁和解锁的模板方法即可。

在了解了AQS后，我们来深入研究ReentrantLock：

ReentrantLock中非公平锁：

sync是个抽象类，这里来看其子类NofairSync的具体实现：

/**
 * 非公平锁实现
 */
static final class NonfairSync extends Sync {
    //加锁
    final void lock() {
        //执行CAS操作，获取同步状态
        if (compareAndSetState(0, 1))
       //成功则将独占锁线程设置为当前线程  
          setExclusiveOwnerThread(Thread.currentThread());
        else
            //否则再次请求同步状态
            acquire(1);
    }
}

在获取同步状态时，首先对同步状态进行CAS操作，尝试把status由0设置为1，如果返回true则表示获取同步状态成功，也就是当前线程获取锁成功，如果返回false，则表示已存在线程获取了该同步状态，获取锁失败。返回false后执行acquire(1)方法，这个方法是AQS中的方法，它对中断不敏感，即使线程获取同步状态失败，进入同步队列，后续对该线程执行中断操作也不会从同步队列移出。

即获取失败后进入AQS同步队列。

这是默认不可中断的获取锁操作。

下面介绍的是可中断的获取锁操作：

可以通过调用ReentrantLock的lockInterrputibly（）或者tryLock()方法实现，最终它们都会调用doAcquireInterrputibly()方法

和不可中断获取锁最大的不同在于，在同步队列自旋过程中，若检测到线程的中断状态后直接抛出InterruptedException异常中断线程，并移出同步队列。

OK，加锁流程到此结束，下面来看一下解锁unlock()操作。

在释放同步状态时，则通过调用子类(ReetrantLock中的Sync内部类)的tryRelease(int releases)方法释放同步状态，释放成功则唤醒后继结点的线程。

ReentrantLock中公平锁：

在获取锁方法lock()中，该方法与nonfairTryAcquire(int acquires)方法唯一的不同是在使用CAS设置尝试设置state值前，调用了hasQueuedPredecessors()判断同步队列是否存在结点，如果存在必须先执行完同步队列中结点的线程，当前线程进入等待状态。这就是非公平锁与公平锁最大的区别，即公平锁在线程请求到来时先会判断同步队列是否存在结点，如果存在先执行同步队列中的结点线程，当前线程将封装成node加入同步队列等待。而非公平锁呢，当线程请求到来时，不管同步队列是否存在线程结点，直接尝试获取同步状态，获取成功直接访问共享资源，但请注意在绝大多数情况下，非公平锁才是我们理想的选择，毕竟从效率上来说非公平锁总是胜于公平锁。

以上便是ReentrantLock的内部实现原理，这里我们简单进行小结，重入锁ReentrantLock，是一个基于AQS并发框架的并发控制类，其内部实现了3个类，分别是Sync、NoFairSync以及FairSync类，其中Sync继承自AQS，实现了释放锁的模板方法tryRelease(int)，而NoFairSync和FairSync都继承自Sync，实现各种获取锁的方法tryAcquire(int)。ReentrantLock的所有方法实现几乎都间接调用了这3个类，因此当我们在使用ReentrantLock时，大部分使用都是在间接调用AQS同步器中的方法，这就是ReentrantLock的内部实现原理。

关于synchronized 与ReentrantLock

在JDK 1.6之后，虚拟机对于synchronized关键字进行整体优化后，在性能上synchronized与ReentrantLock已没有明显差距，因此在使用选择上，需要根据场景而定，大部分情况下我们依然建议是synchronized关键字，原因之一是使用方便语义清晰，二是性能上虚拟机已为我们自动优化。而ReentrantLock提供了多样化的同步特性，如超时获取锁、可以被中断获取锁（synchronized的同步是不能中断的）、等待唤醒机制的多个条件变量(Condition)等，因此当我们确实需要使用到这些功能是，可以选择ReentrantLock。

关于Condition接口

在并发编程中，每个Java对象都存在一组监视器方法，如wait()、notify()以及notifyAll()方法，通过这些方法，我们可以实现线程间通信与协作（也称为等待唤醒机制），如生产者-消费者模式，而且这些方法必须配合着synchronized关键字使用，

与synchronized的等待唤醒机制相比Condition具有更多的灵活性以及精确性，这是因为notify()在唤醒线程时是随机(同一个锁)，而Condition则可通过多个Condition实例对象建立更加精细的线程控制，也就带来了更多灵活性了，我们可以简单理解为以下两点

通过Condition能够精细的控制多线程的休眠与唤醒。
对于一个锁，我们可以为多个线程间建立不同的Condition。

Condition是一个接口类，其主要方法如下：

public interface Condition {

 /**
  * 使当前线程进入等待状态直到被通知(signal)或中断
  * 当其他线程调用singal()或singalAll()方法时，该线程将被唤醒
  * 当其他线程调用interrupt()方法中断当前线程
  * await()相当于synchronized等待唤醒机制中的wait()方法
  */
 void await() throws InterruptedException;

 //当前线程进入等待状态，直到被唤醒，该方法不响应中断要求
 void awaitUninterruptibly();

 //调用该方法，当前线程进入等待状态，直到被唤醒或被中断或超时
 //其中nanosTimeout指的等待超时时间，单位纳秒
 long awaitNanos(long nanosTimeout) throws InterruptedException;

  //同awaitNanos，但可以指明时间单位
  boolean await(long time, TimeUnit unit) throws InterruptedException;

 //调用该方法当前线程进入等待状态，直到被唤醒、中断或到达某个时
 //间期限(deadline),如果没到指定时间就被唤醒，返回true，其他情况返回false
  boolean awaitUntil(Date deadline) throws InterruptedException;

 //唤醒一个等待在Condition上的线程，该线程从等待方法返回前必须
 //获取与Condition相关联的锁，功能与notify()相同
  void signal();

 //唤醒所有等待在Condition上的线程，该线程从等待方法返回前必须
 //获取与Condition相关联的锁，功能与notifyAll()相同
  void signalAll();
}

关于Condition的实现类是AQS的内部类ConditionObject

Condition的实现原理

Condition的具体实现类是AQS的内部类ConditionObject，前面我们分析过AQS中存在两种队列，一种是同步队列，一种是等待队列，而等待队列就相对于Condition而言的。注意在使用Condition前必须获得锁，同时在Condition的等待队列上的结点与前面同步队列的结点是同一个类即Node，其结点的waitStatus的值为CONDITION。在实现类ConditionObject中有两个结点分别是firstWaiter和lastWaiter，firstWaiter代表等待队列第一个等待结点，lastWaiter代表等待队列最后一个等待结点，如下

 public class ConditionObject implements Condition, java.io.Serializable {
    //等待队列第一个等待结点
    private transient Node firstWaiter;
    //等待队列最后一个等待结点
    private transient Node lastWaiter;
    //省略其他代码.......
}

每个Condition都对应着一个等待队列，也就是说如果一个锁上创建了多个Condition对象，那么也就存在多个等待队列。等待队列是一个FIFO的队列，在队列中每一个节点都包含了一个线程的引用，而该线程就是Condition对象上等待的线程。当一个线程调用了await()相关的方法，那么该线程将会释放锁，并构建一个Node节点封装当前线程的相关信息加入到等待队列中进行等待，直到被唤醒、中断、超时才从队列中移出。Condition中的等待队列模型如下

正如图所示，Node节点的数据结构，在等待队列中使用的变量与同步队列是不同的，Condtion中等待队列的结点只有直接指向的后继结点并没有指明前驱结点，而且使用的变量是nextWaiter而不是next，这点我们在前面分析结点Node的数据结构时讲过。firstWaiter指向等待队列的头结点，lastWaiter指向等待队列的尾结点，等待队列中结点的状态只有两种即CANCELLED和CONDITION，前者表示线程已结束需要从等待队列中移除，后者表示条件结点等待被唤醒。再次强调每个Codition对象对于一个等待队列，也就是说AQS中只能存在一个同步队列，但可拥有多个等待队列。下面从代码层面看看被调用await()方法(其他await()实现原理类似)的线程是如何加入等待队列的，而又是如何从等待队列中被唤醒的

awati()等待方法：

await()方法主要做了3件事，一是调用addConditionWaiter()方法将当前线程封装成node结点加入等待队列，二是调用fullyRelease(node)方法释放同步状态并唤醒后继结点的线程。三是调用isOnSyncQueue(node)方法判断结点是否在同步队列中，注意是个while循环，如果同步队列中没有该结点就直接挂起该线程，需要明白的是如果线程被唤醒后就调用acquireQueued(node, savedState)执行自旋操作争取锁，即当前线程结点从等待队列转移到同步队列并开始努力获取锁。

signal唤醒方法：

这里signal()方法做了两件事，一是判断当前线程是否持有独占锁，没有就抛出异常，从这点也可以看出只有独占模式先采用等待队列，而共享模式下是没有等待队列的，也就没法使用Condition。二是唤醒等待队列的第一个结点，即执行doSignal(first)