ReetrantLock与AQS的底层原理

最新推荐文章于 2023-06-11 16:31:46 发布

super_crazy123

最新推荐文章于 2023-06-11 16:31:46 发布

阅读量328

点赞数

CC 4.0 BY-SA版权

分类专栏： 20个经典编程问题文章标签：多线程并发编程 java

本文链接：https://blog.youkuaiyun.com/shushucn2012/article/details/114541236

20个经典编程问题专栏收录该内容

10 篇文章

订阅专栏

本文详细探讨了Java中的隐式锁(synchronized)和显式锁(Lock接口)，重点介绍了ReentrantLock的特点，如公平锁、非公平锁、重入、超时获取和条件变量。此外，讲解了AQS并发框架和ReentrantLock与synchronized的区别，以及在实际场景中的选择策略。

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

1、隐式锁和显式锁

关键字synchronized属于隐式锁，即锁的持有与释放都是隐式的，我们无需干预。

显式锁，即锁的持有和释放都必须由我们手动编写。

2、Lock接口

在Java 1.5中，官方在concurrent并发包中加入了Lock接口，该接口中提供了lock()方法和unLock()方法对显式加锁和显式释放锁操作进行支持。

Lock lock = new ReentrantLock();
lock.lock();
try{
    //临界区......
}finally{
    lock.unlock();
}

当前线程使用lock()方法与unlock()对临界区进行包围，其他线程由于无法持有锁将无法进入临界区直到当前线程释放锁，unlock()操作必须在finally代码块中，这样可以确保即使临界区执行抛出异常，线程最终也能正常释放锁。

Lock接口还提供了以下方法，提供更加灵活的操作：

lockInterruptibly() : 取锁的过程中可中断

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

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

Condition newCondition(): 获取等待通知组件，该组件与当前锁绑定，当前线程只有获得了锁才能调用该组件的await()方法。

重入锁ReetrantLock

重入锁ReetrantLock，JDK 1.5新增的类，实现了Lock接口，作用与synchronized关键字相当，但比synchronized更加灵活。ReetrantLock也是一种支持重进入的锁，即该锁可以支持一个线程对资源重复加锁，需要注意的加锁多少次，就必须解锁多少次，这样才可以成功释放锁。

公平锁与非公平锁

所谓的公平与非公平指的是在请求先后顺序上，先对锁进行请求的就一定先获取到锁，那么这就是公平锁，反之，如果对于锁的获取并没有时间上的先后顺序，如后请求的线程可能先获取到锁，这就是非公平锁。一般而言非，非公平锁机制的效率往往会胜过公平锁的机制，但在某些场景下，可能更注重时间先后顺序，那么公平锁自然是很好的选择。

ReetrantLock默认是非公平锁，但是可以在构造函数中传入参数，改成公平锁模 public ReentrantLock(boolean fair)

ReetrantLock是基于AQS并发框架实现的。

Synchronized和ReentrantLock的区别：

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

1.ReentrantLock是Java层面的实现，synchronized是JVM层面的实现。

2.ReentrantLock可以实现公平和非公平锁。

3.ReentantLock获取锁时，限时等待，配合重试机制更好的解决死锁

4.ReentrantLock可响应中断

5.使用synchronized结合Object上的wait和notify方法可以实现线程间的等待通知机制。ReentrantLock结合Condition接口同样可以实现这个功能。而且相比前者使用起来更清晰也更简单。

并发基础组件AQS

AbstractQueuedSynchronizer又称为队列同步器(后面简称AQS)，它是用来构建锁或其他同步组件的基础框架，内部通过一个int类型的成员变量state来控制同步状态,当state=0时，则说明没有任何线程占有共享资源的锁，当state=1时，则说明有线程目前正在使用共享变量，其他线程必须加入同步队列进行等待，AQS内部通过内部类Node构成FIFO的同步队列来完成线程获取锁的排队工作，同时利用内部类ConditionObject构建等待队列，当Condition调用wait()方法后，线程将会加入等待队列中，而当Condition调用signal()方法后，线程将从等待队列转移动同步队列中进行锁竞争。注意这里涉及到两种队列，一种的同步队列，当线程请求锁而等待的后将加入同步队列等待，而另一种则是等待队列(可有多个与Condition对象数量相当)，通过Condition调用await()方法释放锁后，将加入等待队列。

head和tail分别是AQS中的变量，其中head指向同步队列的头部，注意head为空结点，不存储信息。而tail则是同步队列的队尾。

同步队列采用的是双向链表的结构这样可方便队列进行结点增删操作。

state变量则是代表同步状态，执行当线程调用lock方法进行加锁后，如果此时state的值为0，则说明当前线程可以获取到锁(在本篇文章中，锁和同步状态代表同一个意思)，同时将state设置为1，表示获取成功。如果state已为1，也就是当前锁已被其他线程持有，那么当前执行线程将被封装为Node结点加入同步队列等待。其中Node结点是对每一个访问同步代码的线程的封装。

共享模式和独占模式

AQS作为基础组件，对于锁的实现存在两种不同的模式，即共享模式(如Semaphore)和独占模式(如ReetrantLock)，

所谓共享模式是一个锁允许多条线程同时操作，如信号量Semaphore采用的就是基于AQS的共享模式实现的，而独占模式则是同一个时间段只能有一个线程对共享资源进行操作，多余的请求线程需要排队等待。

无论是Semaphore还是ReetrantLock，其内部绝大多数方法都是间接调用AQS完成的。

ReetrantLock获取锁的一般过程

    final void lock() {
        if (compareAndSetState(0, 1))
          setExclusiveOwnerThread(Thread.currentThread());
        else
          acquire(1);
    }

首先对同步状态执行CAS操作，尝试把state的状态从0设置为1，如果返回true则代表获取同步状态成功，也就是当前线程获取锁成，可操作临界资源，如果返回false，则表示已有线程持有该同步状态(其值为1)，获取锁失败，注意这里存在并发的情景，也就是可能同时存在多个线程设置state变量，因此是CAS操作保证了state变量操作的原子性。

返回false后，执行 acquire(1)方法。传1，代表获取锁。

public final void acquire(int arg) {
    //再次尝试获取同步状态
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

tryAcquire(arg)里做了两件事，一是尝试再次获取同步状态，如果获取成功则将当前线程设置为OwnerThread，返回true，否则判断当前线程current是否为OwnerThread，如果是则属于重入锁，state自增1，并获取锁成功，返回true，反之失败，返回false。

如果tryAcquire(arg)返回false，则会执行addWaiter(Node.EXCLUSIVE)进行入队操作。把线程封装成Node节点插入到双向FIFO队列中。

将当前线程挂起 LockSupport.park(this);

将当前线程唤醒 LockSupport.park(this);

Condition接口

在并发编程中，每个Java对象都存在一组监视器方法，如wait()、notify()以及notifyAll()方法，通过这些方法，我们可以实现线程间通信与协作（也称为等待唤醒机制），如生产者-消费者模式，而且这些方法必须配合着synchronized关键字使用，与synchronized的等待唤醒机制相比Condition具有更多的灵活性以及精确性，这是因为notify()在唤醒线程时是随机(同一个锁)，而Condition则可通过多个Condition实例对象建立更加精细的线程控制，也就带来了更多灵活性了，我们可以简单理解为以下两点

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

Condition的实现原理
Condition的具体实现类是AQS的内部类ConditionObject，前面我们分析过AQS中存在两种队列，一种是同步队列，一种是等待队列，而等待队列就相对于Condition而言的。

注意在使用Condition前必须获得锁，同时在Condition的等待队列上的结点与前面同步队列的结点是同一个类即Node。在实现类ConditionObject中有两个结点分别是firstWaiter和lastWaiter，firstWaiter代表等待队列第一个等待结点，lastWaiter代表等待队列最后一个等待结点。

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

参考https://blog.youkuaiyun.com/javazejian/article/details/75043422