AbstractQueuedSynchronizer之AQS

AQS简单入门

AQS是抽象的队列同步器，是用来实现锁或者其它同步器组件的公共基础部分的抽象实现，是重量级基础框架及整个JUC体系的基石，主要用于解决锁分配给"谁"的问题

整体就是一个抽象的FIFO队列来完成资源获取线程的排队工作，并通过一个int类变量表示持有锁的状态

为什么说AQS是JUC包下的重要基石

和AQS有关的类：

• ReentrantLock
• CountDownLatch
• ReentrantReadWriteLock
• Semaphore
• …
  
  都继承了AQS类

我们使用锁可能只是简单的lock和unlock，但是实际底层锁的实际逻辑，还是AQS来去执行的

AQS能干嘛？

有堵塞需要排队，实现排队的必需队列等候机制管理

如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中，这个队列就是AQS同步队列的抽象表现。它将要请求共享资源的线程及自身的等待状态封装成队列的结点对象(Node)，通过CAS、自旋以及LockSuppor.park()的方式，维护state变量的状态，使并发达到同步的效果。

实际实现原理

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

AQS自身成员变量

下图就是模拟AQS工作的一个流程图

head：头指针，头部出队
tail：尾指针，尾部入队
state：同步状态，判断是否阻塞

Node内部类的成员变量

由于我本地装的是jdk17，AQS与jdk8的源码有不一致情况，所以直接抠图给大家来看看Node的一些内部成员变量

源码解读总结

以ReentrantLock非公平锁为案例去进行lock和unlock的debug源码解读（jdk8情况下）

整个ReentrantLock加锁过程，分为三个阶段

一、尝试加锁
tryAcquire 方法，尝试获取锁，以下几种情况，会导致获取锁失败:
1、锁已经被其他线程续取;
2、锁没有被其他线程获取，但当前线程需要排队:
3、cas 失败(可能过程中已经有其他线程拿到锁了)
锁为自由状态(c==0)，并不能说明可以立刻执行cas 获取锁，因为可能在当前线程获取锁之前，已经有其他线程在排队了，必须道循先来后到原则获取锁。所以还要调用hasQueuedPredecessors方法，查看自己是否需要排队

二、加锁失败，线程进入队列（这部分逻辑，是尝试获取锁失败的情况下，当前线程(尝试获取锁的)封装成 Node 对象，加入到aqs队列中的处理逻辑）
将当前线程封装成 Node对象，并加入排队队列中，根据排队队列是否执行过初始化，执行不同处理逻辑。
1、如果排队队列不为空，即之前已经初始化过了，此时只需将 新的 node加入排队队列未尾即可。
2、如果排队队列为空，需执行队列初始化。enq 会初始化一个 空的 Node，作为排队队列 的head，然后将需要排队的线程，作为head 的 next 节点插入。

三、线程入队列后，进入堵塞状态
1、首先判断 node 的前辈节点，是不是 head，如果是，说明它是下一个可以获得锁的线程，则调用一次tryAcquire，尝试获取锁，若获取到，则将链表关系重新维护下(node设置为 head，之前的 head从链表移出)，然后返回。
2、如果 node 的前辈节点不是 head，或获取锁失败再判断其前辈节点的 waitState，是不是SIGNAL，如果是，则当前线程调用 park，进入阻塞状态，如不是:
1）==0，则设置为 SIGNAL;
2）>0(==1)，则表示前辈节点已经被取消了，将取消的节点，从队列移出，重新维护下排队链表关系

然后再次进入 for 循环，上面的逻辑重新执行一遍,

$就先说到这$
$在下Apollo$
$一个爱分享Java、生活的小人物，$
$咱们来日方长，有缘江湖再见，告辞！$