Java高并发学习（七）——AQS及源码解析 详细图解哦！！

AQS

AQS 是什么

通常的，AbstractQueueSynchronizer类简称AQS。

AbstractQueueSynchronizer字面意思是: 抽象的队列 同步器
抽象的，AbstractQueueSynchronizer是JUC的基石，其自身是抽象类，提供模板，供子类实现。

public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable

队列
队列的实现形式有单链表和双链表，AbstractQueueSynchronizer使用双链表。队列是对抢不到锁的线程的管理。

同步器

锁和同步器的关系
锁：面向锁的使用者。定义了程序员和锁交互的使用层API，隐藏了实现 细节。调用即可。
同步器：面向锁的实现者。比如Java并发大神DougLee，提出了统一规范并简化了锁的实现。屏蔽了同步 状态管理、阻塞线程排队和通知、唤醒机制等。

AQS 的作用

AQS 是用来构建锁（ReentrantLock）或者其他同步器组件（如CountDownLatch）的重量级框架及整个JUC体系的基石。通过内置的FIFO队列来完成资源获取线程的排队工作，并通过一个int类型变量表示持有锁的状态。

为什么AQS 是JUC的基石

可以看到很多的锁（ReentrantLock、ReentrantReadWriteLock等）和同步组件（CountDownLatch、Semaphore信号量）都使用到了AQS，所以说他是JUC的 基石自然而然啦。

抢到资源的线程直接使用处理业务逻辑，抢不到的必然涉及一种排队等候机制。抢占资源失败的线程继续去等待，但等候的线程仍然保留获取锁的可能且获取锁的流程仍在继续，

这个获取锁的流程由CLH队列的变体来实现。它将暂时获取不到锁的线程加入到 队列中，这个队列就是AQS的抽象表现。它将请求共享资源的线程封装成队列的节点（Node），通过CAS、自旋以及LockSupport.park()的方式，维护state变量的状态，是并发达到同步控制的效果。

AbstractQueuedSynchronizer源码分析

AQS组成

AQS主要包括两部分：

一个表示资源同步状态的volatile的int类型变量 state
一个FIFO 的双向队列CLH：通过该队列完成资源获取的排队工作，将每条要去抢占资源的线程封装成一个Node节点来实现锁的分配，通过CAS来完成对State值的修改。

CLH： 三个大牛组成的名字，是一个单向链表，AQS中的队列使用的是CLH辩题的虚拟双向队列FIFO。

Node内部类

AbstractQueuedSynchronizer有个内部类Node，这个Node的元素是Thread，相当于Node< Thread >。这个与Map类似，Map是通过数组实现的，数组的元素时Node< k, v>。

Node类的内部结构

其中waitStatus是排队队列中每个线程的状态，相当于定后驱每个客户的等待状态。取值为上面的枚举值。

Node类的属性含义

AQS同步队列的基本结构

int整型变量state

state表示同步状态，相当于银行办理业务的受理窗口的状态。
0表示该窗口没线程占用.
1表示该窗口有线程占用，需要等待，

以ReentrantLock非公平锁为例来理解 AQS

ReentrantLock的内部结构

1.A线程进入acquire(int arg)方法

所以调用AbstractQueuedSynchronizer 的 acquire(int arg)就是调用子类NonfairSync的tryAcquire(int acquires)

1.1 首先调用 nonfairTryAcquire(int acquires)尝试获取非公平锁

也就是 nonfairTryAcquire(1)尝试获取锁

一路返回true，最终执行结果

2.线程B进入acquire(int arg)方法

if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();

首先调用 tryAcquire(arg)，也就是tryAcquire(1)尝试获取锁

2.1 调用 nonfairTryAcquire(int acquires)尝试获取非公平锁

由于 tryAcquire(arg) 返回结果是false，所以!tryAcquire(arg) 为true，所以acquire(int arg)方法中的判断 继续执行。

if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();

2.2 addWaiter(Node.EXCLUSIVE)将B线程包装成Node节点

阻塞队列初始状态：

2.2.1 初始化阻塞队列

线程B进入addWaiter(Node mode)方法，调用addWaiter(Node.EXCLUSIVE)

initializeSyncQueue()方法具体实现：

队列初始化后的结果：

for循环还没有走完哦！

2.2.2 将封装了线程B的node节点加入阻塞队列

compareAndSetTail(Node expect, Node update) 方法实现如下：

修改后等待队列如下：

2.3 acquireQueued(addWaiter(Node.EXCLUSIVE), arg)

2.3.1 队首元素先尝试获取锁

一开始B节点的predecessor为head，所以会尝试获取锁，tryAcquire(int acquires)

调用tryAcquire(int acquires)即调用nonfairTryAcquire(int acquire)

进入shouldParkAfterFailedAcquire(Node pred, Node node)

上述的pred.compareAndSetWaitStatus(ws, Node.SIGNAL); 将waitstatus设置为-1。

for循环没结束哦！ 所以会再判断 if (shouldParkAfterFailedAcquire(p, node))

再次进入shouldParkAfterFailedAcquire(Node pred, Node node)

B线程进入阻塞状态

3.线程C进入acquire(int arg)方法

3.1 首先调用 nonfairTryAcquire(int acquires)尝试获取非公平锁

尝试获取锁，nonfairTryAcquire(1)

3.2 创建C节点

将线程C封装到 节点的过程与B类似，这里就不赘述了

3.3 将C节点加入阻塞队列过程

第一次进入shouldParkAfterFailedAcquire(Node pred, Node node)即调用 shouldParkAfterFailedAcquire(p, node)时，

第二次进入shouldParkAfterFailedAcquire(Node pred, Node node)即调用 shouldParkAfterFailedAcquire(p, node)时，

4.A线程释放锁

AbstractQueuedSynchronizer抽象类的release()方法

4.1 A线程调用tryRelease(int realeases)释放掉锁

调用ReentrantLock的tryRelease(1)

4.2 唤醒阻塞队列中的队首线程

unpark()唤醒B线程

5. B线程被唤醒并抢占锁

B线程被唤醒，由Waiting状态进入Running状态，从阻塞处开始执行

B线程在for循环中，调用tryAcquire(1)

5.1 B线程调用nonfairTryAcquire(1)尝试获取锁

5.2 B线程获取锁成功，释放阻塞队列中的内容

进入setHead(Node)方法，即调用setHeadnode()

修改后的阻塞队列

B线程工作时间结束后释放锁，然后C线程抢占锁的过程与B线程被A线程唤醒抢占锁类似。这里就不追溯了，打个断点自己调试一下，大概就清除了、