AQS原理与ReentrantLock源码分析
AQS 的全称为 AbstractQueuedSynchronizer
,即抽象队列同步器,这个类在java.util.concurrent.locks
包下面。
AQS 是一个用来构建锁和同步器的框架,使用 AQS 能简单且高效地构造出大量应用广泛的同步器,比如我们提到的 ReentrantLock
,Semaphore
,其他的诸如 ReentrantReadWriteLock
,SynchronousQueue
,FutureTask
等等皆是基于 AQS 的。
AQS 原理
AQS 核心思想 / 工作流程是:如果被请求的共享资源空闲,则将当前请求资源的线程设置为有效的工作线程,并且将共享资源设置为锁定状态。如果被请求的共享资源被占用,那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制,这个机制 AQS 是用 CLH 队列锁实现的,即将暂时获取不到锁的线程加入到队列中。
CLH(Craig,Landin and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例,仅存在结点之间的关联关系)。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点(Node)来实现锁的分配。
这个队列是通过CLH队列实现的,从图可以看出,该队列是一个双向队列,有Node结点组成,每个Node结点维护一个prev引用和next引用,这两个引用分别指向自己结点的前驱结点和后继结点,同时AQS还维护两个指针Head和Tail,分别指向队列的头部和尾部。
AQS 使用一个 int 成员变量来表示同步状态,通过内置的 FIFO 队列来完成获取资源线程的排队工作。
AQS 使用 CAS 对该同步状态进行原子操作实现对其值的修改。
1 | private volatile int state; //共享变量,使用volatile修饰保证线程可见性 |
状态信息通过 protected 类型的 getState,setState,compareAndSetState 进行操作
1 | //返回同步状态的当前值 |
资源共享方式
AQS 定义两种资源共享方式
- 独占模式(Exclusive):资源是独占的,一次只能一个线程获取。如
ReentrantLock
。- 又可分为公平锁和非公平锁:
- 公平锁:按照线程在队列中的排队顺序,先到者先拿到锁
- 非公平锁:当线程要获取锁时,无视队列顺序直接去抢锁,谁抢到就是谁的
- 又可分为公平锁和非公平锁:
- 共享模式(Share):同时可以被多个线程获取,具体的资源个数可以通过参数指定。如
CountDownLatch
、Semaphore
、CyclicBarrier
、ReadWriteLock
。
相对来说,非公平锁会有更好的性能,因为它的吞吐量比较大。当然,非公平锁让获取锁的时间变得更加不确定,可能会导致在阻塞队列中的线程长期处于饥饿状态。
AQS 底层基于模板方法模式
AQS 的设计基于模板方法模式,自定义同步器时需要重写下面几个 AQS 提供的模板方法:
isHeldExclusively()
:该线程是否正在独占资源。只有用到condition才需要去实现它。tryAcquire(int)
:独占方式。尝试获取资源,成功则返回true,失败则返回false。tryRelease(int)
:独占方式。尝试释放资源,成功则返回true,失败则返回false。tryAcquireShared(int)
:共享方式,尝试获取资源。负数表示失败,0表示成功,但没有剩余可用资源,正数表示成功并且有剩余资源。tryReleaseShared(int)
:共享方式。尝试释放资源,如果释放后允许唤醒后续等待结点返回true,否则返回false。
这些方法虽然都是
protected
方法,但是它们并没有在AQS具体实现,而是直接抛出异常(这里不使用抽象方法的目的是:避免强迫子类中把所有的抽象方法都实现一遍,减少无用功,这样子类只需要实现自己关心的抽象方法即可,比如 Semaphore 只需要实现 tryAcquire 方法而不用实现其余不需要用到的模版方法)。AQS 类中的其他方法都是 final ,所以无法被其他类使用,只有这几个方法可以被其他类使用。
AQS 源码分析
获取资源
先来看下 AQS 提供的获取资源方法 acquire
:
1 | public final void acquire(int arg) { |
进入一步看一下tryAcquire()函数。该函数的作用是尝试获得一个许可(资源)。对于 AbstractQueuedSynchronizer 来说,这是一个未实现的抽象函数,默认直接抛出异常。具体实现在子类中。在重入锁,读写锁,信号量等实现中, 都有各自的实现。
如果tryAcquire()成功,则acquire()直接返回成功。如果获取资源失败,就通过 addWaiter(Node.EXCLUSIVE)
方法把这个线程加入同步等待队列中。其中传入的参数代表要插入的Node是独占式的。
1 | private Node addWaiter(Node mode) { |
由于AQS中会存在多个线程同时争夺资源的情况,因此肯定会出现多个线程同时插入节点的操作,在这里是通过CAS自旋的方式保证了操作的线程安全性。
将 Node 节点加入等待队列尾部后,处于等待队列的节点是从头结点一个一个去获取资源,具体实现在方法 acquireQueued
中:
1 | // 以独占的方式不间断地获取已在队列中的线程。 |
所以结点进入等待队列后,是调用park使它进入阻塞状态的。只有头结点的线程是处于活跃状态的。
释放资源
1 | public final boolean release(int arg) { |
以 ReentrantLock 为例
ReentrantLock
默认采用非公平锁,因为考虑获得更好的性能,通过 boolean
来决定是否用公平锁(传入 true 用公平锁)。
1 | /** Synchronizer providing all implementation mechanics */ |
非公平锁在调用 lock() 后,首先就会调用 CAS 进行一次抢锁,如果这个时候恰巧锁没有被占用,那么直接就获取到锁返回了。
1 | static final class NonfairSync extends Sync { |
非公平锁在 CAS 失败后,和公平锁一样都会调用 AQS 的模板方法 acquire
方法。
1 | static final class FairSync extends Sync { |
获取资源的入口是acquire(int arg)方法。arg是要获取的资源的个数,在独占模式下始终为1。我们先来看看这个方法的逻辑:
1 | public final void acquire(int arg) { |
然后模板方法会调用使用者(自定义同步器)重写的方法 tryAcquire
尝试去获取资源, 如果发现锁这个时候被释放了(state == 0),非公平锁会直接 CAS 抢锁,但是公平锁会判断等待队列是否有线程处于等待状态,如果有则不去抢锁,按顺序排到后面。
1 | final boolean nonfairTryAcquire(int acquires) { |
获取资源流程图
state 初始化为 0,表示未锁定状态。A 线程 lock() 时,会调用 tryAcquire()独占该锁并将 state+1。此后,其他线程再 tryAcquire()时就会失败,直到 A 线程 unlock()到 state=0(即释放锁)为止,其它线程才有机会获取该锁。当然,释放锁之前,A 线程自己是可以重复获取此锁的(state 会累加),这就是可重入的概念。但要注意,获取多少次就要释放多少次,这样才能保证 state 是能回到零态的。
参考资料