AQS&ReentrantLock源码解析

在Java中实现同步主要就两种方法Synchronized和Lock，前面的文章我们介绍了Synchronized是JVM层面的对象锁，它的实现基于MESA管程模型，而Lock是由Jdk实现的同样基于MESA管程模型的锁，其中Lock最核心的实现是ReentrantLock。

一、AQS
1.1 什么是AQS
在《深入理解Synchronized》这篇文章中，已经详细介绍了MESA管程模型，它主要由共享变量、入口等待队列和条件队列组成，在Synchronized的实现中，只有一个条件队列，而在ReentrantLock中，可以有多个条件队列。

而Java实现管程模型的核心就是AbstractQueuedSynchronizer(简称AQS)，这是一个抽象类，它实现了等待队列和条件队列中元素出队和入队的逻辑以及条件队列的等待唤醒机制。

Java的JUC包下的大多数同步器实现都有着共同的基础行为，比如等待队列、条件队列、独占获取、共享获取等，这些行为的抽象都在AbstractQueuedSynchronizer中实现，AQS是一个抽象同步框架，可以用来实现一个依赖状态的同步器。

JDK中中大多数同步器比Lock、Latch、Barrier等，它们使用AQS基本都是通过定义一个内部类Sync来继承AQS，然后将同步器所有调用都映射到Sync对应的方法

下面展示了部分AQS的实现类：

1.2 AQS特性
AQS实现了以下的基本功能：

阻塞等待队列
独占或共享
公平或非公平
可重入
可中断
在AQS内部，维护了一个volatile int state属性，这个属性表示共享资源的可用状态，以ReentrantLock为例，它的lock()方法就会去调用AQS的tryAcquire()方法，而这个方法就是通过CAS操作尝试去修改state属性的值，修改成功了就表示拿到了共享资源的使用资格，修改不成功就会被加入到等待队列中。

state属性提供了三种访问和修改的方法：

getState()

protected final int getState() {
    return state;
}
1
2
3
setState()

protected final void setState(int newState) {
    state = newState;
}
1
2
3
compareAndSetState()

protected final boolean compareAndSetState(int expect, int update) {
    // See below for intrinsics setup to support this
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
1
2
3
4
AQS定义了两种共享资源的访问方式：独占和共享

Exclusive(独占)：只有一个线程能够执行，如ReentrantLock
Share(共享)：多个线程可以同时执行，如Semaphore/CountDownLatch
AQS继承了AbstractOwnableSynchronizer，该类里面有一个exclusiveOwnerThread属性，记录当前独占线程，在判断是否为重入时，也是调用该抽象类的getExclusiveOwnerThread()方法获取独占线程与当前线程作比较，相等则说明是重入，不需要再次重试获取锁。

AQS定义了MESA管程模型中的两类队列：

同步等待队列

用于维护获取锁失败时入队的线程

AQS采用双向链表来实现同步等待队列，之所以采用双向链表是因为AQS支持可中断，当线程中断时，双向链表可以比较简单地将该线程从等待队列中移除，而使用单向链表实现则比较麻烦

条件等待队列

当调用Condition的await()方法时会释放锁，然后将线程加入到条件队列，调用sign()方法唤醒的时候，会把条件队列中的线程节点同步队列中，等待再次获取锁

AQS使用单向链表来实现条件等待队列，也就意味着条件等待队列中的线程不能被中断

在AQS中定义了一个内部类Node，Node中封装了Thread对象、前后节点(同步队列)、节点状态和下一个等待节点(等待队列)，而节点状态又分为5类，其中默认值为0。

初始化状态，默认值为0，表示当前节点在同步队列中，等待获取锁
CANCELLED状态，值为1，表示当前线程被取消
SIGNAL状态，值为-1，表示同步队列中当前节点的后续节点中的线程可以执行，也就是调用unpark()方法
CONDITION状态，值为-2，表示当前线程正在条件等待队列中
PROPAGATE状态，值为-3，表示当前场景下后续的acquireShared能够得以执行
不同的同步器竞争共享资源的方式也不同，自定义同步器实现(也就是继承AQS)时，只需要按照特定的需求来实现共享资源state的获取和释放方式即可，而至于具体线程在等待队列和条件队列的维护(获取锁失败入队或等待唤醒)，AQS都已经实现好了。

自定义同步器实现时主要实现以下几种方法，这些方法在AQS中都是抽象方法：

isHeldExclusively()

判断当前线程是否独占共享资源state，只有用到Condition才会去实现它

tryAcquire(int arg)

独占方式尝试获取共享资源state，成功则返回true，失败则返回false

tryRelease(int arg)

独占方式尝试释放共享资源state，成功则返回true，失败则返回false

tryAcquireShared(int arg)

共享方式尝试获取共享资源state，返回负数表示失败，返回0或正数表示成功，返回值为剩余共享资源数

tryReleaseShared(int arg)

共享方式尝试释放共享资源state，成功返回true，失败返回false

1.3 同步等待队列
AQS当中的同步等待队列也称为CLH队列，是一种基于双向链表数据结构的队列，是FIFO(先进先出)模式的线程等待队列，Java中的CLH队列是原CLH队列的一种变种，线程由原自旋机制改为阻塞机制。

AQS依赖CLH同步队列来完成同步状态的管理：

当前线程如果获取同步状态失败时，AQS则会将当前线程初始化状态等信息构成一个节点(Node)并将其加入到CLH同步队列，同时调用LockSupport.park()方法来阻塞当前线程。
当同步状态释放时，会把首节点换新(公平锁)，使其再次尝试获取同步状态
通过Condition的sign()或signAll()方法将条件队列中的节点转移到同步队列
基本结构如下如所示：

我们在前面介绍Node结构的时候，它包含了prev和next这两个前后节点指针，用于阻塞队列形成双向链表，而nextWaiter指示下一个节点指针，用于条件等待队列形成单向链表

1.4 条件等待队列
AQS中条件队列使用单向链表来保存节点，用Node的nextWaiter来连接

条件队列主要的是await()和signal()方法，而Conditon接口中定义了这些方法，同步器需要实现条件队列时，就需要实现Condition接口中的这些方法

AQS中通过内部类ConditionObject来实现了Condition接口，除实现了上面的方法，还定义了addConditionWaiter()添加等待节点等方法

当调用await()方法时，会将当前线程封装成一个Node节点，然后添加到等待队列中并阻塞当前线程

当调用signal()方法时，会把条件队列中的首节点添加到同步队列尾部进行等待(从条件队列转换到同步队列)

当同步队列头节点中的线程被唤醒后，调用await()方法会进行阻塞(从同步队列转换到条件队列)

二、Condition接口方法详解
1、调用Condition#await()方法会释放当前线程持有的锁，然后阻塞当前线程，同时向条件队列尾部添加一个节点，所以调用Condition#await()方法时必须持有锁

2、调用Condition#signal()方法会将条件队列的首节点移动到阻塞队列尾部，然后返回阻塞队列原来的尾节点(现在倒数第二个节点)，如果该节点为已取消状态(CANCELLED)或者更新该节点的状态为唤醒状态(SIGNAL)失败时，会去直接唤醒刚才插入阻塞队列的尾部节点中的线程(也就是因调用await()方法阻塞的线程)。

代码如下，后面再深入介绍为什么是更新为唤醒状态失败时会去唤醒线程：

Node p = enq(node);
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
    LockSupport.unpark(node.thread);
1
2
3
4
被唤醒之后的线程就可以去竞争锁了，所以调用Condition#signal()方法的时候必须持有锁，持有锁的线程去唤醒因调用await()方法而阻塞的线程

下面代码展示了等待唤醒机制await()和signal()的使用

ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();

new Thread(() ->{
    lock.lock();
    try {
        log.info(Thread.currentThread().getName()+"开始执行……");
        condition.await();
        log.info(Thread.currentThread().getName()+"任务完成……");
    } catch (InterruptedException e) {
        e.printStackTrace();
    }finally {
        lock.unlock();
    }
},"Thread1").start();

new Thread(() -> {
    lock.lock();
    try {
        log.info(Thread.currentThread().getName()+"开始执行……");
        condition.signal();
        Thread.sleep(2000);
        log.info(Thread.currentThread().getName()+"任务完成……");
    } catch (InterruptedException e){
        e.printStackTrace();
    } finally {
        lock.unlock();
    }
},"Thread2").start();

LockSupport.park();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
打印的结果如下：

17:11:12.735 [Thread1] INFO com.lizhi.lock.ReentrantLockTest - Thread1开始执行……
17:11:12.739 [Thread2] INFO com.lizhi.lock.ReentrantLockTest - Thread2开始执行……
17:11:14.748 [Thread2] INFO com.lizhi.lock.ReentrantLockTest - Thread2任务完成……
17:11:14.748 [Thread1] INFO com.lizhi.lock.ReentrantLockTest - Thread1任务完成……
1
2
3
4
在阿里的开发规范手册里面，强调了在lock()方法后面就要紧跟try-finally代码块，在finally代码块里面调用unlock()方法，防止出现因为代码异常而导致的死锁