ReentrantLock 中的加锁操作都是通过Syn这个抽象类来完成,具体解析在之前得博客已经分析过了,请参考:ReentrantLock AQS操作解析
得不到锁的线程,如何排队?
JUC中锁的排队策略,是基于CLH队列的变种实现的。因此,我们先看看啥是CLH队列
CLH队列

如上图所示,获取不到锁的线程,会进入队尾,然后自旋,直到其前驱线程释放锁。可能会有同学问为啥有2种指针在node上面,这个之后会在解释
这样做的好处:假设有1000个线程等待获取锁,锁释放后,只会通知队列中的第一个线程去竞争锁,减少了并发冲突。(ZK的分布式锁,为了避免惊群效应,也使用了类似的方式:获取不到锁的线程只监听前一个节点)
为什么说JUC中的实现是基于CLH的“变种”,因为原始CLH队列,一般用于实现自旋锁。而JUC中的实现,获取不到锁的线程,一般会时而阻塞,时而唤醒。
UC中的CLH队列实现
我们来看看AbstractQueuedSynchronizer类中的acquire方法实现
public final void acquire(int arg) {//尝试获取锁if (!tryAcquire(arg) &&//获取不到,则进入等待队列,返回是否中断acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//如果返回中断,则调用当前线程的interrupt()方法selfInterrupt();}
入队
如果线程调用tryAcquire(其最终实现是调用上面分析过的nonfairTryAcquire方法)获取锁失败。则首先调用addWaiter(Node.EXCLUSIVE)方法,将自己加入CLH队列的尾部。
private Node addWaiter(Node mode) {//线程对应的NodeNode node = new Node(Thread.currentThread(), mode);// Try the fast path of enq; backup to full enq on failureNode pred = tail;//尾节点不为空if (pred != null) {//当前node的前驱指向尾节点node.prev = pred;//将当前node设置为新的尾节点//如果cas操作失败,说明线程竞争if (compareAndSetTail(pred, node)) {pred.next = node;return node;}}//lockfree的方式插入队尾enq(node);return node;}private Node enq(final Node node) {//经典的lockfree算法:循环+CASfor (;;) {Node t = tail;//尾节点为空if (t == null) { // Must initialize//初始化头节点if (compareAndSetHead(new Node()))tail = head;} else {node.prev = t;if (compareAndSetTail(t, node)) {t.next = node;return t;}}}}
入队过程,入下图所示
1 T0持有锁时,其CLH队列的头尾指针为NULL (没有任何node来获取锁时,锁会给到默认得head-node持有,也就是T0)

2 线程T1,此时请求锁,由于锁被T0占有。因此加入队列尾部。具体过程如下所示:
(1) 初始化头节点
(2) 初始化T1节点,入队,尾指针指向T1

3 此时如果有一个T10线程先于T1入队,则T1执行compareAndSetTail(t, node)会失败,然后回到for循环开始处,重新入队。


由自旋到阻塞
入队后,调用acquireQueued方法,时而自旋,时而阻塞,直到获取锁(或被取消)。
final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();//其前驱是头结点,并且再次调用tryAcquire成功获取锁if (p == head && tryAcquire(arg)) {//将自己设为头结点setHead(node);p.next = null; // help GCfailed = false;//成功获取锁,返回return interrupted;}//没有得到锁时://shouldParkAfterFailedAcquire方法:返回是否需要阻塞当前线程//parkAndCheckInterrupt方法:阻塞当前线程,当线程再次唤醒时,返回是否被中断if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())//修改中断标志位interrupted = true;}} finally {if (failed)//获取锁失败,则将此线程对应的node的waitStatus改为CANCELcancelAcquire(node);}}private void setHead(Node node) {head = node;node.thread = null;node.prev = null;}/*** 获取锁失败时,检查并更新node的waitStatus。* 如果线程需要阻塞,返回true。*/private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {int ws = pred.waitStatus;//前驱节点的waitStatus是SIGNAL。if (ws == Node.SIGNAL)/* * SIGNAL状态的节点,释放锁后,会唤醒其后继节点。* 因此,此线程可以安全的阻塞(前驱节点释放锁时,会唤醒此线程)。*/return true;//前驱节点对应的线程被取消if (ws > 0) {do {//跳过此前驱节点node.prev = pred = pred.prev;} while (pred.waitStatus > 0);pred.next = node;} else {/*此时,需要将前驱节点的状态设置为SIGNAL。* waitStatus must be 0 or PROPAGATE. Indicate that we* need a signal, but don't park yet. Caller will need to* retry to make sure it cannot acquire before parking.*/compareAndSetWaitStatus(pred, ws, Node.SIGNAL);}return false;}//当shouldParkAfterFailedAcquire方法返回true,则调用parkAndCheckInterrupt方法阻塞当前线程private final boolean parkAndCheckInterrupt() {LockSupport.park(this);return Thread.interrupted();}
自旋过程,入下图所示





然后线程T2,加入了请求锁的队列,尾指针后移。



终上所述,每个得不到锁的线程,都会讲自己封装成Node,加入队尾,或自旋或阻塞,直到获取锁
锁的释放
前文提到,T1,T2在阻塞之前,都回去修改其前驱节点的waitStatus=-1。这是为什么?
我们看下锁释放的代码,便一目了然
public final boolean release(int arg) {//修改锁计数器,如果计数器为0,说明锁被释放if (tryRelease(arg)) {Node h = head;//head节点的waitStatus不等于0,说明head节点的后继节点对应的线程,正在阻塞,等待被唤醒if (h != null && h.waitStatus != 0)//唤醒后继节点unparkSuccessor(h);return true;}return false;}private void unparkSuccessor(Node node) {/** If status is negative (i.e., possibly needing signal) try* to clear in anticipation of signalling. It is OK if this* fails or if status is changed by waiting thread.*/int ws = node.waitStatus;if (ws < 0)compareAndSetWaitStatus(node, ws, 0);//后继节点Node s = node.next;//如果s被取消,跳过被取消节点if (s == null || s.waitStatus > 0) {s = null;for (Node t = tail; t != null && t != node; t = t.prev)if (t.waitStatus <= 0)s = t;}if (s != null)//唤醒后继节点LockSupport.unpark(s.thread);}
如代码所示,waitStatus=-1的作用,主要是告诉释放锁的线程:后面还有排队等待获取锁的线程,请唤醒他!
释放锁的过程,如图所示:


















