一、摘要
在之前的文章中，我们介绍了 ReentrantLock、ReadWriteLock、CountDownLatch、CyclicBarrier、Semaphore、ThreadPoolExecutor 等并发工具类的使用方式，它们在请求共享资源的时候，都能实现线程同步的效果。
在使用方式上稍有不同，有的是独占式，多个线程竞争时只有一个线程能执行方法，比如 ReentrantLock 等；有的是共享式，多个线程可以同时执行方法，比如：ReadWriteLock、CountDownLatch、Semaphore 等，不同的实现争用共享资源的方式也不同。
如果仔细阅读源码，会发现它们都是基于AbstractQueuedSynchronizer这个抽象类实现的，我们简称 AQS。
AQS 是一个提供了原子式管理同步状态、阻塞和唤醒线程功能的框架，是除了 Java 自带的synchronized关键字之外的锁实现机制。
可以这么说，AQS是JUC包下线程同步类的基石，也是很多面试官喜欢提问的话题，掌握AQS原理对我们深入理解线程同步技术有着非常重要的意义。
本文以ReentrantLock作为切入点，来解读AQS相关的知识点，最后配上简单的应用示例来帮助大家理解 AQS，如果有描述不对的地方，欢迎大家留言指出，不胜感激！
二、ReentrantLock
在之前的线程系列文章中，我们介绍了ReentrantLock的基本用法，它是一个可重入的互斥锁，它具有与使用synchronized关键字一样的效果，并且功能更加强大，编程更加灵活，支持公平锁和非公平锁两种模式。
使用方式也非常简单，只需要在相应的代码上调用加锁和释放锁方法即可，简单示例如下！
public class Counter {
// 默认非公平锁模式
private final Lock lock = new ReentrantLock();
public void add() {
// 加锁
lock.lock();
try {
// 具体业务逻辑...
} finally {
// 释放锁
lock.unlock();
}
}
}
如果阅读lock()和unlock()方法，会发现它的底层都是由AQS来实现的。
下面，我们一起来看看这两个方法的源码实现，本文源码内容摘取自 JDK 1.8 版本，可能不同的版本略有区别！
2.1、lock 方法源码
public class ReentrantLock implements Lock, java.io.Serializable {
// 同步锁实现类
private final Sync sync;
public ReentrantLock() {
// 默认构造方法为非公平锁实现类
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
// true：公平锁实现类，false：非公平锁实现类
sync = fair ? new FairSync() : new NonfairSync();
}
public void lock() {
// 加锁操作
sync.lock();
}
// 非公平锁实现类
static final class NonfairSync extends Sync {
// 加锁操作
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
}
// 公平锁实现类
static final class FairSync extends Sync {
// 加锁操作
final void lock() {
acquire(1);
}
}
// 公平锁和非公平锁，都继承自 AQS
abstract static class Sync extends AbstractQueuedSynchronizer {
// lock 抽象方法
abstract void lock();
}
}
从源码上可以清晰的看到，当初始化ReentrantLock对象时，需要指定锁的模式。
默认构造方法是非公平锁模式，采用的是NonfairSync内部实现类；公平锁模式下，则采用的是FairSync内部实现类；这两个内部实现类都继承了Sync抽象类；同时，Sync也继承了AbstractQueuedSynchronizer，也就是我们上文提到的AQS。
如果把lock()方法的请求链路进行抽象，可以用如下图进行简要概括。
无论是非公平锁模式还是公平锁模式，可能最终都会调用AQS的acquire()方法，它表示通过独占式的方式加锁，我们继续往下看这个方法的源码，部分核心代码如下：
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
// 通过独占式的方式加锁
public final void acquire(int arg) {
// 尝试加锁，会回调具体的实现类
if (!tryAcquire(arg) &&
// 如果尝试加锁失败，将当前线程加入等待队列
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// 由子类完成加锁逻辑的实现，支持重写该方法
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
}
从AQS的源码上可以看出，acquire()方法并不进行具体加锁逻辑的实现，而是通过具体的实现类重写tryAcquire()方法来完成加锁操作，如果加锁失败，会将当前线程加入等待队列。
如果是非公平锁模式，会回调ReentrantLock类的NonfairSync.tryAcquire()方法；如果是公平锁模式，会回调ReentrantLock类的FairSync.tryAcquire()方法，我们继续回看ReentrantLock类的源码。
非公平锁NonfairSync静态内部实现类，相关的源码如下！
// 非公平锁实现类
static final class NonfairSync extends Sync {
// 加锁操作
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
// 尝试非公平方式加锁，重写父类 tryAcquire 方法
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 采用CAS方式修改线程同步状态，如果成功返回true
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 支持当前线程，重复获得锁，将state值加1
int nextc = c + acquires;
if (nextc 公平锁FairSync静态内部实现类，相关的源码如下！
// 公平锁实现类
static final class FairSync extends Sync {
// 加锁操作
final void lock() {
acquire(1);
}
// 尝试公平方式加锁，重写父类 tryAcquire 方法
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 1）判断等待队列是否有线程处于等待状态，如果没有，尝试获取锁；如果有，就进入等待队列
// 2）采用CAS方式修改线程同步状态，如果成功返回true
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 支持当前线程，重复获得锁，将state值加1
int nextc = c + acquires;
if (nextc 从源码上可以清晰的看到，无论是是公平锁还是非公平锁模式，都是采用compareAndSetState()方法（简称CAS）进行加锁，如果成功就返回true；同时支持当前线程重复获得锁，也就是之前提到的锁可重入机制。
唯一的区别在于：公平锁实现类多了一个hasQueuedPredecessors()方法判断，它的用途是判断等待队列是否有线程处于等待状态，如果没有，尝试获取锁；如果有，就将当前线程存入等待队列，依此排队，从而保证线程通过公平方式获取锁的目的。
关于 CAS 实现原理，在之前的并发原子类文章中已经有所介绍，通过它加上volatile修饰符可以实现一个无锁的线程安全访问操作，本文不再重复解读，有兴趣的朋友可以翻阅之前的文章。
2.2、unlock 方法源码
public class ReentrantLock implements Lock, java.io.Serializable {
// 同步锁实现类
private final Sync sync;
public void unlock() {
// 释放锁操作
sync.release(1);
}
}
unlock()方法的释放锁实现相对来说就简单多了，整个请求链路可以用如下图进行简要概括。
当调用unlock()方法时，会直接跳转到AQS的release()方法上，AQS相关的源码如下！
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
// 释放锁操作
public final boolean release(int arg) {
// 尝试释放锁
if (tryRelease(arg)) {
// 从队列头部中获取一个等待线程，并进行唤醒操作
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
// 由子类完成释放锁逻辑的实现，支持重写该方法
protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}
}
与加锁操作类似，AQS的release()方法并不进行具体释放锁逻辑的实现，而是通过具体的实现类重写tryRelease()方法来完成释放锁操作，如果释放锁成功，会从队列头部中获取一个等待线程，并进行唤醒操作。
我们继续回看ReentrantLock类的Sync.tryRelease()释放锁方法，部分核心源码如下：
abstract static class Sync extends AbstractQueuedSynchronizer {
// 尝试释放锁
protected final boolean tryRelease(int releases) {
// 将state值进行减1操作
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
}
相比加锁过程，释放锁要简单的多，主要是将线程的同步状态值进行自减操作。
三、AQS 原理浅析
如果仔细的研究 AQS 的源码，尽管实现上很复杂，但是也有规律可循。
从上到下，整个框架可以分为五层，架构可以用如下图来描述！（图片来自ReentrantLock 的实现看 AQS 的原理及应用 – 美团技术团队）
当有自定义线程同步器接入AQS时，只需要按需重写第一层的方法即可，不需要关心底层的实现。
以加锁为例，当调用AQS的 API 层获取锁方法时，会先尝试进行加锁操作（具体逻辑由实现类完成），如果加锁失败，会进入等待队列处理环节，这些处理逻辑同时也依赖最底层的基础数据提供层来完成。
3.1、原理概述
整个AQS实现线程同步的核心思想，可以用如下这段话来描述！
AQS 内部维护一个共享资源变量和线程等待队列，如果被请求的共享资源空闲，那么就将当前请求资源的线程设置为有效的工作线程，将共享资源设置为锁定状态；如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是 CLH 队列的变体实现的，将暂时获取不到锁的线程加入到等待队列中，待条件允许的时候将线程从队列中取出并进行唤醒。
CLH 队列是一个单向链表队列，对应的还有 CLH 锁实现，它是一个基于逻辑队列非线程饥饿的一种自旋公平锁实现，由 Craig、Landin 和 Hagersten 三位大佬发明，因此命名为 CLH 锁。关于这方面的技术知识讲解可以参阅这篇文章：多图详解 CLH 锁的原理与实现。
而AQS中的队列采用的是 CLH 变体的虚拟双向队列，通过将每一条请求共享资源的线程封装成一个 CLH 队列的一个节点来实现锁的分配。
具体实现原理，可以用如下图来简单概括：
同时，AQS中维护了一个共享资源变量state，通过它来实现线程的同步状态控制，这个字段使用了volatile关键字修饰符来保证多线程下的可见性。
当多个线程尝试获取锁时，会通过CAS方式来修改state值，服务器托管网当state=1时表示当前对象锁已经被占有（相对独占模式来说），此时其他线程来加锁时会失败，加锁失败的线程会被放入上文说到的FIFO等待队列中，并且线程会被挂起，等待其他获取锁的线程释放锁才能够被唤醒。
总结下来，用大白话说就是，AQS是基于 CLH 队列，使用volatile修饰共享变量state，线程通过CAS方式去改变state状态值，如果成功则获取锁成功，失败则进入等待队列，等待被唤醒的线程同步器框架。
打开 ReentrantLock、ReadWriteLock、CountDownLatch、CyclicBarrier、Semaphore 等类的源码实现，你会发现它们的线程同步状态都是基于AQS实现的，可以看成是AQS的衍生物。
下面我们一起来看看相关的源码实现！
3.2、源码浅析
3.2.1、线程同步状态控制
AQS源码中维护的共享资源变量state，表示同步状态的意思，它是实现线程同步控制的关键字段，核心源码如下：
/**
* The synchronization state.
*/
private volatile int state;
针对state字段值的获取和修改，AQS提供了三个方法，并且都采用Final修饰，意味着子类无法重写它们，相关方法如下：
| 方法 | 描述 |
|---|---|
| protected final int getState() | 获取state的值 |
| protected final void setState(int newState) | 设置state的值 |
| protected final boolean compareAndSetState(int expect, int update) | 使用 CAS 方式更新state
|
如果仔细分析源码，state字段还有一个很大的用处，通过它可以实现多线程的独占模式和共享模式。
以ReentrantLock和Semaphore类为例，它们的加锁过程中state值的变化情况如下。
3.2.1.1、ReentrantLock 独占模式的获取锁，简易流程图如下：
ReentrantLock类部分核心源码，实现逻辑如下：
public class ReentrantLock implements Lock, java.io.Serializable {
// 非公平锁实现类
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
// 加锁操作
final void lock() {
// 将state从0设置为1，如果成功，直接获取当前共享资源
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
// 尝试加锁，会转调tryAcquire方法
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// 判断state是否等于0
if (c == 0) {
// 尝试state从0设置为1，如果成功，返回true
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 支持当前线程可重入，每调用一次，state的值加1
int nextc = c + acquires;
if (nextc 3.2.1.2、Semaphore 共享模式的获取锁，简易流程图如下：
Semaphore类部分核心源码，实现逻辑如下：
public class Semaphore implements java.io.Serializable {
// 初始化的时候，设置线程最大并发数，本质设置的是state的值
public Semaphore(int permits) {
sync = new NonfairSync(permits);
}
// 非公平锁内部实现类
static final class NonfairSync extends Sync {
NonfairSync(int permits) {
// 设置state的值
setState(permits);
}
// 通过共享方式，尝试获取锁
protected int tryAcquireShared(int acquires) {
return nonfairTryAcquireShared(acquires);
}
}
// 尝试获取共享资源，会调用Sync.nonfairTryAcquireShared方法
public boolean tryAcquire() {
// 如果state的值小于0，表示无可用共享资源
return sync.nonfairTryAcquireShared(1) >= 0;
}
// 抽象同步类
abstract static class Sync extends AbstractQueuedSynchronizer {
// 通过共享方式，尝试获取锁
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
// 通过cas方式，设置state自减
int available = getState();
int remaining = available - acquires;
if (remaining 3.2.2、公平锁和非公平锁实现
在上文的ReentrantLock源码分析过程中，对于公平锁和非公平锁实现，其实已经有所解读。
在AQS中所有的加锁逻辑是有具有的实现类来完成，以ReentrantLock类为例，它的加锁逻辑由两个实现类来完成，分别是非公平锁静态内部实现类NonfairSync和公平锁静态内部实现类FairSync。
如上文的源码介绍，这两个类的的加锁逻辑基本一致，唯一的区别在于：公平锁实现类加锁时，增加了一个hasQueuedPredecessors()方法判断，这个方法会判断等待队列是否有线程处于等待状态，如果没有，尝试获取锁；如果有，就进入等待队列。
简单的说就是，非公平锁实现类的加锁方式，如果有线程尝试获取锁，直接尝试通过CAS方式进行抢锁，如果抢成功了，就直接获取锁，没有抢成功就进入等待队列；而公平锁实现类的加锁方式，会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面，如果没有则尝试抢锁。
相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。其次，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。
Semaphore类的公平锁和非公平锁实现也类似，拥有两个静态内部实现类，源码就不再解读了，有兴趣的朋友可以自行阅读。
3.2.3、主要模板方法
从ReentrantLock的源码实现中可以看出，AQS使用了模板方法设计模式，它不提供加锁和释放锁的具体逻辑实现，而是由实现类重写对应的方法来完成，这样的好处就是实现更加的灵活，不同的线程同步器可以自行继承AQS类，然后实现独属于自身的加锁和解锁功能。
常用的模板方法主要有以下几个：
| 方法 | 描述 |
|---|---|
| protected boolean isHeldExclusively() | 判断该线程是否正在独占资源。只有用到Condition才需要去实现它 |
| protected boolean tryAcquire(int arg) | 独占方式。尝试获取资源，arg为获取锁的次数，成功则返回true，失败则返回false
|
| protected boolean tryRelease(int arg) | 独占方式。尝试释放资源，arg为释放锁的次数，成功则返回true，失败则返回false
|
| protected int tryAcquireShared(int arg) | 共享方式。尝试获取资源，arg为获取锁的次数，负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源 |
| protected boolean tryReleaseShared(int arg) | 共享方式。尝试释放资源，arg为释放锁的次数，如果释放后允许唤醒后续等待结点返回true，否则返回false
|
通常自定义线程同步器，要么是独占模式，要么是共享模式。
如果是独占模式，重写tryAcquire()和tryRelease()方法即可，比如 ReentrantLock 类。
如果是共享模式，重写tryAcquireShared()和tryReleaseShared()方法即可，比如 Semaphore 类。
3.2.4、线程加入等待队列实现
当线程调用tryAcquire()方法获取锁失败之后，就会调用addWaiter()方法，将当前线程加入到等待队列中去。
addWaiter()方法，部分核心源码如下：
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
// 将当前线程加入等待队列
private Node addWaiter(Node mode) {
// 以当前线程构造一个节点，尝试通过CAS方式插入到双向链表的队尾
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 如果插入没有成功，则通过enq入队
enq(node);
return node;
}
// 通过enq入队
private Node enq(final Node node) {
// CAS 自旋方式，直到成功加入队尾
for (;;) {
Node t = tail;
if (t == null) {
// 队列为空，创建一个空结点作为head结点，并将tail也指向它
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
}
我们再来看看Node类节点相关的属性，部分核心源码如下：
static final class Node {
// 当前节点在队列中的状态，状态值枚举含义如下：
// 0:节点初始化时的状态
// 1: 表示节点引用线程由于等待超时或被打断时的状态
// -1: 表示当队列中加入后继节点被挂起时，其前驱节点会被设置为SIGNAL状态，表示该节点需要被唤醒
// -2：当节点线程进入condition队列时的状态
// -3：仅在释放共享锁releaseShared时对头节点使用
volatile int waitStatus;
// 前驱节点
volatile Node prev;
// 后继节点
volatile Node next;
//该节点的线程实例
volatile Thread thread;
// 指向下一个处于Condition状态的节点（用于条件队列）
Node nextWaiter;
//...
}
可以很清晰的看到，每个关键属性变量都加了volatile修饰符，确保多线程环境下可见。
正如上文所介绍的，Node其实是一个双向链表数据结构，大致的数据结构图如下！（图片来自ReentrantLock 的实现看 AQS 的原理及应用 – 美团技术团队）
其中第一个节点，也叫头节点，为虚节点，并不存储任何线程信息，只是占位用；真正有数据的是从第二个节点开始，当有线程需要加入等待队列时，会向队尾进行插入。
线程加入等待队列之后，会再次调用acquireQueued()方法，尝试进行获取锁，如果成功或者中断就退出，部分核心源码如下：
final boolean acquireQueued(final Node node, int arg) {
// 标记是否成功拿到锁
boolean failed = true;
try {
// 标记等待过程中是否中断过
boolean interrupted = false;
// 开始自旋，要么获取锁，要么中断
for (;;) {
// 获取当前节点的前驱节点
final Nod服务器托管网e p = node.predecessor();
// 如果p是头结点，说明当前节点在等待队列的头部，尝试获取锁（头结点是虚节点）
if (p == head && tryAcquire(arg)) {
// 获取锁成功，头指针移动到当前node
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
// 如果p不是头节点或者是头节点但获取锁失败，判断当前节点是否要进入阻塞，如果满足要求，就通过park让线程进入阻塞状态，等待被唤醒
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
// 如果没有成功获取锁（比如超时或者被中断），那么取消节点在队列中的等待
cancelAcquire(node);
}
}
线程加入等待队列实现，总结下来，大致步骤如下：
- 1.调用
addWaiter()方法，将当前线程封装成一个节点，尝试通过CAS方式插入到双向链表的队尾，如果没有成功，再通过自旋方式插入，直到成功为止 - 2.调用
acquireQueued()方法，对在等待队列中排队的线程，尝试获取锁操作，如果失败，判断当前节点是否要进入阻塞，如果满足要求，就通过LockSupport.park()方法让线程进入阻塞状态，并检查是否被中断，如果没有，等待被唤醒
3.2.5、线程从等待队列中被唤醒实现
当线程调用tryRelease()方法释放锁成功之后，会从等待队列的头部开始，获取排队的线程，并进行唤醒操作。
释放锁方法，部分核心源码如下：
public final boolean release(int arg) {
// 尝试释放锁
if (tryRelease(arg)) {
// 获取头部节点
Node h = head;
if (h != null && h.waitStatus != 0)
// 尝试唤醒头部节点的下一个节点中的线程
unparkSuccessor(h);
return true;
}
return false;
}
其中unparkSuccessor()是执行唤醒线程的核心方法，部分核心源码如下：
private void unparkSuccessor(Node node) {
// 获取头结点 waitStatus
int ws = node.waitStatus;
// 置零当前线程所在的结点状态，允许失败
if (ws 0) {
s = null;
// 从尾部节点开始向前找，找到队列中排在最前的有效节点
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus 线程从等待队列中被唤醒实现，总结下来，大致步骤如下：
- 1.当线程调用
tryRelease()方法释放锁成功之后，会从等待队列获取排队的线程 - 2.如果队列的头节点的下一个节点有效，会尝试进行唤醒节点中的线程；如果为空或者被取消，就从队列尾部依此寻找节点，找到队列中排在最前的有效节点，并尝试进行唤醒操作
四、简单应用
了解完AQS基本原理之后，按照以上的知识点，我们可以自己实现一个不可重入的互斥锁线程同步类。
示例代码如下：
public class MutexLock {
// 自定义同步器
private static class Sync extends AbstractQueuedSynchronizer {
// 判断是否锁定状态
@Override
protected boolean isHeldExclusively() {
return getState() == 1;
}
// 尝试获取资源，立即返回。成功则返回true，否则false。
@Override
protected boolean tryAcquire(int acquires) {
//state为0才设置为1，不支持重入！
if (compareAndSetState(0, 1)) {
//设置为当前线程独占资源
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
// 尝试释放资源，立即返回。成功则为true，否则false。
@Override
protected boolean tryRelease(int releases) {
// 判断资源是否已被释放
if (getState() == 0)
throw new IllegalMonitorStateException();
setExclusiveOwnerThread(null);
//释放资源，放弃占有状态
setState(0);
return true;
}
}
// 真正同步类的实现都依赖继承于AQS的自定义同步器！
private final Sync sync = new Sync();
// 获取锁，会阻塞等待，直到成功才返回
public void lock() {
sync.acquire(1);
}
// 释放锁
public void unlock() {
sync.release(1);
}
}
测试类如下：
public class MutexLockTest {
private static int count =0;
private static MutexLock lock = new MutexLock();
public static void main(String[] args) throws Exception {
final int threadNum = 10;
CountDownLatch latch = new CountDownLatch(threadNum);
// 创建10个线程，同时对count进行1000相加操作
for (int i = 0; i 输出结果：
执行结果：10000
从日志输出结果可以清晰的看到，执行结果与预期值一致！
五、小结
本文从ReentrantLock源码分析到AQS原理解析，进行了一次知识内容的总结，从上文的分析中可以看出，AQS是JUC包下线程同步器实现的基石。
ReentrantLock、ReadWriteLock、CountDownLatch、CyclicBarrier、Semaphore、ThreadPoolExecutor 等并发工具类，线程同步的实现都基于AQS来完成，掌握AQS原理对线程同步的理解和使用至关重要。
AQS原理是面试时热点话题，希望本篇能帮助到大家！
六、参考
1.https://www.cnblogs.com/waterystone/p/4920797.html
2.https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html
3.https://zhuanlan.zhihu.com/p/197840259
4.https://juejin.cn/post/7006895386103119908
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
