AQS源码

true，执行上图步骤1

返回node

返回false

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

CAS获取锁

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

addWaiter

     final void lock() {                acquire(1);        }

lock

prev

abstract void lock()

sync继承了AbstractQueuedSynchronized

执行park逻辑

enq方法

acquire（1）

next

设置pred.waitState = -1

true

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

执行排队逻辑

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

Thread = ThreadBwaitState = 0

将当前对象封装为Node对象，并加到排队队列中根据排队队列是否执行过初始化，执行1，2不同处理逻辑1：表示排队队列不为空，也就是之前进行过初始化，此时只需将新的node加入到排队队列末尾即可2：表示排队队列为空，作为排队队列的head，然后将需要排队的线程，作为head的next节点插入

FairSync#lock（）

返回true

  public void lock() { sync.lock(); }

Ⅰ

公平锁

ReentrantLock

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

NonFairSync#lock（）

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

非公平锁

false

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

Thread = nullwaitState = 0哨兵节点

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

整个aqs的核心难点之一：这里使用了for(;;)首先判断node的前辈节点，是不是head，如果是，说明他是下一个可以获得锁的线程，则调用一次tryAcquire，尝试获取锁，若未取到，则将链表关系重新维护下(node设置为head，之前的head从链表移除)，然后返回如果node的前辈节点不是head，或获取锁失败，再判断前辈节点的waitState，是不是SINGAL（-1），如果是，则当前线程调用park，进入阻塞状态。如不是：1、 ==0 设置为SIGNALfont color=\"#000000\

pred ！= null

注意，这里是设置pred节点，而不是node节点的waitState。-1表示节点处于阻塞状态为何每个线程进入该方法后，修改的是上一个节点的waitState，而不是修改自己的？因为线程调用park后，无法设置自己的这个状态，若在调用park之前设置，存在不一致的问题。所以，，每个node的waitState，在后继节点加入时设置

pred.waitState>0?

false，执行上图步骤2

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

Ⅱ

HeadTail

Thread = ThreadCwaitState = 0

sync.lock()

false (即 ==0)

aqs队列

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

tryAcquire

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

acquireQueued方法详解

acquireQueued