AQS 原理-尚硅谷周阳

FairSync#lock()

ReentrantLock

acquireQueued

这部分，是 node 加入队列后的处理逻辑，这里会有一次自旋，尝试获取锁，获取不到，才调用 park，阻塞自己。

shouldParkAfterFailedAcquire 方法详解

acquireQueued 返回，表示线程获取到锁，线程逐级返回，加锁过程结束。

pred.waitState >0?

sync.lock()

表示获取到锁：1.node设置为头结点2.释放之前的头结点，这个逻辑执行完之后，node节点就不用进行排队了，（获取到锁的线程就不会再队列中）

返回 true，表示获取到了锁，线程逐级返回。加锁过程结束

队列尚未初始化，调用 enq 方法该方法生成一个空的 Node 对象（new Node()，右图粉色部分），插入到 aqs 队列头部，然后将参数 node ，作为后继节点，插入队列，方法执行完毕，队列如右图。

abstract void lock()

NonFairSync#lock()

加入队列的逻辑

此图为《尚硅谷Java大厂面试题第3季 - 周阳》—— AQS 部分笔记CSDN 笔记：JUC-多线程（12. AQS-周阳）学习笔记 (https://blog.csdn.net/weixin_44449838/article/details/130262253)若对你有用麻烦点赞

这个队列表示，在线程 C 进入前，已经有一个线程在排队获取锁了。 

返回false

阻塞结束

lock

这个队列表示，在节点 n2 插入队列之前，没有其他节点在排队。注意，当前持有锁的线程，永远不会处于排队队列中。这是因为:当一个线程调用 lock 获取锁时，只有两种情况:1) 锁处于自由状态 (state==0) ，且它不需要排队，通过 cas 立刻获取到了锁，这种情况，显然它不会处于排队队列中;2)锁处于非自由状态，线程加入到了排队队列的队头 (不包括 head ) 等待锁。将来某一时刻，锁被其他线程释放，并唤醒这个排队的线程，线程唤醒后。执行 tryAcquire. 获取到了锁，然后重新维护排队队列，将自己从队列移出 (acquireQueued 方法)。所以，不管哪种情况，持有锁的线程，永远不会处于排队列表中。

没有其他线程在排队，调用 enq 构造队列，并将 node 加入队列。

false再次刷新

false，执行上图步骤2

acquireQueue 方法详解

设置 pred.waitState = -1

返回true

sync 继承了 AbstractQueuedSynchronizer

addWaiter

> 0 ，只能 == 1，即 CANCELLED。表示 node 的前辈节点，已经取消了，此时将链表关系重新维护下：即将其前辈节点从队列移出

这个方法，接收两个Node 对象参数:参数2 是准备执行 park 操作的节点 node，参数1是其前辈节点 pred.

pred ! = null

false，即==0

非公平锁

pred.waitState == Node.SIGNAL(-1)?

队列已经初始化，将 node 加入到队列末尾，加入后队列可能如下

false

尝试获取锁，如果获取不到，排队（阻塞当前线程）

true

tryAcquire

成功获取到锁，设置锁持有线程为当前线程。返回

acquire(1)

整个 aqs 的核心和难点之一。注意这里使用了 for(; ;) 自旋首先判断 node 的前辈节点，span style=\"font-size: inherit;\

执行pack逻辑

p == head ?表示查询 node 是不是第一个排队的

CAS获取锁

返回 false，表示线程没有获取到锁

公平锁

parkAndCheckInterrut 线程进入阻塞状态

返回node