多线程编程(10)之深入理解AQS 队列同步器

深碍√TFBOYSˉ_ 2022-09-04 10:53 164阅读 0赞

# 一、前言 #

AbstractQueuedSynchronizer 简称 AQS，是一个抽象类的队列式同步器，它的内部通过维护一个状态volatile int state(共享资源)，一个FIFO线程等待队列来实现同步功能。可能我们几乎不会直接去使用它，但它却是 JUC 的核心基础组件，支撑着 java 锁和同步器的实现，例如 `ReentrantLock`、`ReentrantReadWriteLock`、`CountDownLatch`，以及 `Semaphore` 等。大神 Doug Lea 在设计 JUC 包时希望能够抽象一个基础且通用的组件以支撑上层模块的实现，AQS 应运而生。这些同步器以及锁都是内部定义sync集成aqs然后定义自己的api。

state用关键字volatile修饰，代表着该共享资源的状态一更改就能被所有线程可见，而AQS的加锁方式本质上就是多个线程在竞争state，当state为0时代表线程可以竞争锁，不为0时代表当前对象锁已经被占有，其他线程来加锁时则会失败，加锁失败的线程会被放入一个FIFO的等待队列中，这些线程会被`UNSAFE.park()`操作挂起，等待其他获取锁的线程释放锁才能够被唤醒。

而这个等待队列其实就相当于一个CLH队列，用一张原理图来表示大致如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70][]

##          1.1基础定义 ##

AQS支持两种资源分享的方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。

自定义的同步器继承AQS后，只需要实现共享资源state的获取和释放方式即可，其他如线程队列的维护（如获取资源失败入队/唤醒出队等）等操作，AQS在顶层已经实现了，AQS代码内部提供了一系列操作锁和线程队列的方法，主要操作锁的方法包含以下几个：

*  compareAndSetState()：利用CAS的操作来设置state的值
 *  tryAcquire(int)：独占方式获取锁。成功则返回true，失败则返回false。
 *  tryRelease(int)：独占方式释放锁。成功则返回true，失败则返回false。
 *  tryAcquireShared(int)：共享方式释放锁。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
 *  tryReleaseShared(int)：共享方式释放锁。如果释放后允许唤醒后续等待结点返回true，否则返回false。

像ReentrantLock就是实现了自定义的tryAcquire-tryRelease，从而操作state的值来实现同步效果，除此之外，AQS内部还定义了一个静态类Node，表示CLH队列的每一个结点，该结点的作用是对每一个等待获取资源做了封装，包含了需要同步的线程本身、线程等待状态等。

我们可以看下该类的一些重点变量：

static final class Node {
            /**
             * 标记节点未共享模式
             * */
            static final Node SHARED = new Node();
            /**
             *  标记节点为独占模式
             */
            static final Node EXCLUSIVE = null;
    
            /**
             * 在同步队列中等待的线程等待超时或者被中断，需要从同步队列中取消等待
             * */
            static final int CANCELLED =  1;
            /**
             *  后继节点的线程处于等待状态，而当前的节点如果释放了同步状态或者被取消，
             *  将会通知后继节点，使后继节点的线程得以运行。
             */
            static final int SIGNAL    = -1;
            /**
             *  节点在等待队列中，节点的线程等待在Condition上，当其他线程对Condition调用了signal()方法后，
             *  该节点会从等待队列中转移到同步队列中，加入到同步状态的获取中
             */
            static final int CONDITION = -2;
            /**
             * 表示下一次共享式同步状态获取将会被无条件地传播下去
             */
            static final int PROPAGATE = -3;
    
            /**
             * 标记当前节点的信号量状态 (1,0,-1,-2,-3)5种状态
             * 使用CAS更改状态，volatile保证线程可见性，高并发场景下，
             * 即被一个线程修改后，状态会立马让其他线程可见。
             */
            volatile int waitStatus;
    
            /**
             * 前驱节点，当前节点加入到同步队列中被设置
             */
            volatile Node prev;
    
            /**
             * 后继节点
             */
            volatile Node next;
    
            /**
             * 节点同步状态的线程
             */
            volatile Thread thread;
    
            /**
             * 等待队列中的后继节点，如果当前节点是共享的，那么这个字段是一个SHARED常量，
             * 也就是说节点类型(独占和共享)和等待队列中的后继节点共用同一个字段。
             */
            Node nextWaiter;
    }

代码里面定义了一个表示当前Node结点等待状态的字段`waitStatus`，该字段的取值包含了CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)、0，这五个值代表了不同的特定场景：

*  **CANCELLED**：表示当前结点已取消调度。当timeout或被中断（响应中断的情况下），会触发变更为此状态，进入该状态后的结点将不会再变化。
 *  **SIGNAL**：表示后继结点在等待当前结点唤醒。后继结点入队时，会将前继结点的状态更新为SIGNAL（记住这个-1的值，因为后面我们讲的时候经常会提到）
 *  **CONDITION**：表示结点等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将**从等待队列转移到同步队列中**，等待获取同步锁。(注：**Condition**是AQS的一个组件，后面会细说)
 *  **PROPAGATE**：共享模式下，前继结点不仅会唤醒其后继结点，同时也可能会唤醒后继的后继结点。
 *  **0**：新结点入队时的默认状态。

也就是说，当waitStatus为**负值表示结点处于有效等待状态，为正值的时候表示结点已被取消。**

在AQS内部中还维护了两个Node对象`head`和`tail`，一开始默认都为null。

/**
         * 指向同步等待队列的头节点
         */
        private transient volatile Node head;
    
        /**
         * 指向同步等待队列的尾节点
         */
        private transient volatile Node tail;

讲完了AQS的一些基础定义，我们就可以开始学习同步的具体运行机制了，为了更好的演示，我们用ReentrantLock作为使用入口，一步步跟进源码探究AQS底层是如何运作的，**这里说明一下，因为ReentrantLock底层调用的AQS是独占模式，所以下文讲解的AQS源码也是针对独占模式的操作。在文章的末尾我也会附上aqs跟ReentrantLock源码的中文注释，大家有需要可以拷贝下来细读。**

# 二、独占模式 #

##         2.1加锁 ##

我们都知道，ReentrantLock的加锁和解锁方法分别为lock()和unLock()，我们先来看获取锁的方法。

/**
             * 加锁行为
             */
            final void lock() {
                /**
                 * 第一步：直接尝试加锁
                 * 与公平锁实现的加锁行为一个最大的区别在于，此处不会去判断同步队列(CLH队列)中
                 * 是否有排队等待加锁的节点，上来直接加锁（判断state是否为0,CAS修改state为1）
                 * ，并将独占锁持有者 exclusiveOwnerThread 属性指向当前线程
                 * 如果当前有人占用锁，再尝试去加一次锁
                 */
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    //AQS定义的方法,加锁
                    acquire(1);
            }

逻辑很简单，线程进来后直接利用`CAS`尝试抢占锁，如果抢占成功`state`值回被改为1，且设置对象独占锁线程为当前线程，否则就调用`acquire(1)`再次尝试获取锁。

我们假定有两个线程A和B同时竞争锁，A进来先抢占到锁，此时的AQS模型图就类似这样：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 1][]

继续走下面的方法，acquire。

public final void acquire(int arg) {
            if (!tryAcquire(arg) &&
                    acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
                selfInterrupt();
        }

*           tryAcquire：尝试直接获取锁，如果成功就直接返回；
 *  addWaiter：将该线程加入等待队列FIFO的尾部，并标记为独占模式；
 *  acquireQueued：线程阻塞在等待队列中获取锁，一直获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
 *  selfInterrupt：自我中断，就是既拿不到锁，又在等待时被中断了，线程就会进行自我中断selfInterrupt()，将中断补上。

我们一个个来看源码，并结合上面的两个线程来做场景分析。

### 2.1.1**tryAcquire** ###

**        **不用多说，就是为了再次尝试获取锁，或者判断当前持有锁的线程是不是自己本身。

protected final boolean tryAcquire(int acquires) {
 return nonfairTryAcquire(acquires);
 }
 
 
 
 /**
 * 尝试获取非公平锁
 */
 final boolean nonfairTryAcquire(int acquires) {
 //acquires = 1
 final Thread current = Thread.currentThread();
 int c = getState();
 /**
 * 不需要判断同步队列（CLH）中是否有排队等待线程
 * 判断state状态是否为0，不为0可以加锁
 */
 if (c == 0) {
 //unsafe操作，cas修改state状态
 if (compareAndSetState(0, acquires)) {
 //独占状态锁持有者指向当前线程
 setExclusiveOwnerThread(current);
 return true;
 }
 }
 /**
 * state状态不为0，判断锁持有者是否是当前线程，
 * 如果是当前线程持有 则state+1
 */
 else if (current == getExclusiveOwnerThread()) {
 int nextc = c + acquires;
 if (nextc < 0) // overflow
 throw new Error("Maximum lock count exceeded");
 setState(nextc);
 return true;
 }
 //加锁失败
 return false;
 }

当线程B进来后，**nonfairTryAcquire**方法首先会获取state的值，如果为0，则正常获取该锁，不为0的话判断是否是当前线程占用了，是的话就累加state的值，这里的累加也是为了配合释放锁时候的次数，从而实现可重入锁的效果。当然，因为之前锁已经被线程A占领了，所以这时候`tryAcquire`会返回false，继续下面的流程。

###         2.1.2 addWaiter ###

private Node addWaiter(Node mode) {
            // 1. 将当前线程构建成Node类型
            Node node = new Node(Thread.currentThread(), mode);
            // Try the fast path of enq; backup to full enq on failure
            Node pred = tail;
            // 2. 1当前尾节点是否为null？
            if (pred != null) {
                // 2.2 将当前节点尾插入的方式
                node.prev = pred;
                // 2.3 CAS将节点插入同步队列的尾部
                if (compareAndSetTail(pred, node)) {
                    pred.next = node;
                    return node;
                }
            }
            enq(node);
            return node;
        }

这段代码首先会创建一个和当前线程绑定的`Node`节点，`Node`为双向链表。此时等待队列中的`tail`指针为空，直接调用`enq(node)`方法将当前线程加入等待队列尾部，然后返回当前结点的前驱结点。

/**
         * 节点加入CLH同步队列
         */
        private Node enq(final Node node) {
            for (;;) {
                Node t = tail;
                if (t == null) { // Must initialize
                    //队列为空需要初始化，创建空的头节点,队列为空，初始化一个Node结点作为Head结点，并将tail结点也指向它
                    if (compareAndSetHead(new Node()))
                        tail = head;
                } else {
                    node.prev = t;
                    //set尾部节点
                    if (compareAndSetTail(t, node)) {//当前节点置为尾部
                        t.next = node; //前驱节点的next指针指向当前节点
                        return t;
                    }
                }
            }
        }

第一遍循环时，tail指针为空，初始化一个Node结点，并把head和tail结点都指向它，然后第二次循环进来之后，tail结点不为空了，就将当前的结点加入到tail结点后面，也就是这样。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 2][]

如果此时有另一个线程C进来的话，发现锁已经被A拿走了，然后队列里已经有了线程B，那么线程C就只能乖乖排到线程B的后面去，大家在跟着阅读源码或者自己阅读源码的时候，也可以跟着思路在纸上画出此时的队列情况这样子更能够理解。

### ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 3][]         2.1.3acquireQueued ###

/**
         * 已经在队列当中的Thread节点，准备阻塞等待获取锁
         */
        final boolean acquireQueued(final Node node, int arg) {
            boolean failed = true;
            try {
                boolean interrupted = false;
                for (;;) {//死循环
                    final Node p = node.predecessor();//找到当前结点的前驱结点
                    if (p == head && tryAcquire(arg)) {//如果前驱结点是头结点，才tryAcquire，其他结点是没有机会tryAcquire的。
                        setHead(node);//获取同步状态成功，将当前结点设置为头结点。
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    /**
                     * 如果前驱节点不是Head，通过shouldParkAfterFailedAcquire判断是否应该阻塞
                     * 前驱节点信号量为-1，当前线程可以安全被parkAndCheckInterrupt用来阻塞线程
                     */
                    if (shouldParkAfterFailedAcquire(p, node) &&
                            parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally {
                if (failed)
                    cancelAcquire(node);
            }
        }
    
        private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
            int ws = pred.waitStatus;
            if (ws == Node.SIGNAL)
                /*
                 * 若前驱结点的状态是SIGNAL，意味着当前结点可以被安全地park
                 */
                return true;
            if (ws > 0) {
                /*
                 * waitStatus>0代表这个节点无效需要进行剔除,前驱节点状态如果被取消状态，将被移除出队列
                 */
                do {
                    node.prev = pred = pred.prev;
                } while (pred.waitStatus > 0);
                pred.next = node;
            } else {
                /*
                 * 当前驱节点waitStatus为 0 or PROPAGATE状态时
                 * 将其设置为SIGNAL状态，然后当前结点才可以可以被安全地park
                 */
                compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
            }
            return false;
        }

`acquireQueued`方法的流程是这样的：

1.  CAS自旋，先判断当前传入的Node的前结点是否为head结点，是的话就尝试获取锁，获取锁成功的话就把当前结点置为head，之前的head置为null(方便GC)，然后返回。
2.  如果前驱结点不是head或者加锁失败的话，就调用`shouldParkAfterFailedAcquire`，将前驱节点的**waitStatus**变为了**SIGNAL=-1**，最后执行`parkAndChecknIterrupt`方法，调用`LockSupport.park()`挂起当前线程，`parkAndCheckInterrupt`在挂起线程后会判断线程是否被中断，如果被中断的话，就会重新跑`acquireQueued`方法的CAS自旋操作，直到获取资源。

ps：LockSupport.park方法会让当前线程进入waitting状态，在这种状态下，线程被唤醒的情况有两种，一是被unpark()，二是被interrupt()，所以，如果是第二种情况的话，需要返回被中断的标志，然后在`acquire`顶层方法的窗口那里自我中断补上。

此时，因为线程A还未释放锁，所以线程B状态都是被挂起的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 4][]

到这里，加锁的流程就分析完了，其实整体来说也并不复杂，而且当你理解了独占模式加锁的过程，后面释放锁和共享模式的运行机制也没什么难懂的了，所以整个加锁的过程还是有必要多消化下的，也是AQS的重中之重。这里我附上一张流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 5][]

##  2.2释放锁 ##

说完了加锁，我们来看看释放锁是怎么做的，AQS中释放锁的方法是`release()`，当调用该方法时会释放指定量的资源 (也就是锁) ，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。

/**
         * 释放独占模式持有的锁
         */
        public final boolean release(int arg) {
            if (tryRelease(arg)) {//释放一次锁
                Node h = head;
                if (h != null && h.waitStatus != 0)
                    unparkSuccessor(h);//唤醒后继结点
                return true;
            }
            return false;
        }

###         2.2.1tryRelease ###

代码上可以看出，核心的逻辑都在`tryRelease`方法中，该方法的作用是释放资源，AQS里该方法没有具体的实现，需要由自定义的同步器去实现，我们看下**ReentrantLock**代码中对应方法的源码：

/**
             * 释放锁
             */
            protected final boolean tryRelease(int releases) {
                int c = getState() - releases;
                if (Thread.currentThread() != getExclusiveOwnerThread())
                    throw new IllegalMonitorStateException();
                boolean free = false;
                if (c == 0) {
                    free = true;
                    setExclusiveOwnerThread(null);
                }
                setState(c);
                return free;
            }

`tryRelease`方法会减去state对应的值，如果state为0，也就是已经彻底释放资源，就返回true，并且把独占的线程置为null，否则返回false。

此时AQS中的数据就会变成这样：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 6][]

完全释放资源后，当前线程要做的就是唤醒CLH队列中第一个在等待资源的线程，也就是head结点后面的线程，此时调用的方法是`unparkSuccessor().`

private void unparkSuccessor(Node node) {
 //获取wait状态
 int ws = node.waitStatus;
 if (ws < 0)
 compareAndSetWaitStatus(node, ws, 0);// 将等待状态waitStatus设置为初始值0
 
 /**
 * 若后继结点为空，或状态为CANCEL（已失效），则从后尾部往前遍历找到最前的一个处于正常阻塞状态的结点
 * 进行唤醒
 */
 Node s = node.next;
 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);//唤醒线程
 }

方法的逻辑很简单，就是先将head的结点状态置为0，避免下面找结点的时候再找到head，然后找到队列中最前面的有效结点，然后唤醒，我们假设这个时候线程A已经释放锁，那么此时队列中排最前边竞争锁的线程B就会被唤醒。然后被唤醒的线程B就会尝试用CAS获取锁，回到`acquireQueued`方法的逻辑.

for (;;) {//死循环
                    final Node p = node.predecessor();//找到当前结点的前驱结点
                    if (p == head && tryAcquire(arg)) {//如果前驱结点是头结点，才tryAcquire，其他结点是没有机会tryAcquire的。
                        setHead(node);//获取同步状态成功，将当前结点设置为头结点。
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    /**
                     * 如果前驱节点不是Head，通过shouldParkAfterFailedAcquire判断是否应该阻塞
                     * 前驱节点信号量为-1，当前线程可以安全被parkAndCheckInterrupt用来阻塞线程
                     */
                    if (shouldParkAfterFailedAcquire(p, node) &&
                            parkAndCheckInterrupt())
                        interrupted = true;
                }

当线程B获取锁之后，会把当前结点赋值给head，然后原先的前驱结点 (也就是原来的head结点) 去掉引用链，方便回收，这样一来，线程B获取锁的整个过程就完成了，此时AQS的数据就会变成这样。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 7][]

到这里，我们已经分析完了AQS独占模式下加锁和释放锁的过程，也就是**tryAccquire->tryRelease**这一链条的逻辑，除此之外，AQS中还支持共享模式的同步，这种模式下关于锁的操作核心其实就是**tryAcquireShared->tryReleaseShared**这两个方法，我们可以简单看下 。

--------------------

# 三、共享模式      #

## 3.1获取锁 ##

AQS中，共享模式获取锁的顶层入口方法是`acquireShared`，该方法会获取指定数量的资源，成功的话就直接返回，失败的话就进入等待队列，直到获取资源。

/**
 * 请求获取共享锁
 */
 public final void acquireShared(int arg) {
 if (tryAcquireShared(arg) < 0)//返回值小于0，获取同步状态失败，排队去；获取同步状态成功，直接返回去干自己的事儿。
 doAcquireShared(arg);
 }

该方法里包含了两个方法的调用：

1.  tryAcquireShared：尝试获取一定资源的锁，返回的值代表获取锁的状态。
2.  doAcquireShared：进入等待队列，并循环尝试获取锁，直到成功。

### 3.1.1tryAcquireShared ###

`tryAcquireShared`在AQS里没有实现，同样由自定义的同步器去完成具体的逻辑，像一些较为常见的并发工具Semaphore、CountDownLatch里就有对该方法的自定义实现，虽然实现的逻辑不同，但方法的作用是一样的，就是获取一定资源的资源，然后根据返回值判断是否还有剩余资源，从而决定下一步的操作。

返回值有三种定义：

*          负值代表获取失败；
 *  0代表获取成功，但没有剩余的资源，也就是state已经为0；
 *  正值代表获取成功，而且state还有剩余，其他线程可以继续领取

当返回值小于0时，证明此次获取一定数量的锁失败了，然后就会走`doAcquireShared`方法。

### 3.1.2doAcquireShared ###

此方法的作用是将当前线程加入等待队列尾部休息，直到其他线程释放资源唤醒自己，自己成功拿到相应量的资源后才返回，这是它的源码：

private void doAcquireShared(int arg) {
 // 加入队列尾部
 final Node node = addWaiter(Node.SHARED);
 boolean failed = true;
 try {
 boolean interrupted = false;
 // CAS自旋
 for (;;) {
 final Node p = node.predecessor();
 // 判断前驱结点是否是head
 if (p == head) {
 // 尝试获取一定数量的锁
 int r = tryAcquireShared(arg);
 if (r >= 0) {
 // 获取锁成功，而且还有剩余资源，就设置当前结点为head，并继续唤醒下一个线程
 setHeadAndPropagate(node, r);
 // 让前驱结点去掉引用链，方便被GC
 p.next = null; // help GC
 if (interrupted)
 selfInterrupt();
 failed = false;
 return;
 }
 }
 // 跟独占模式一样，改前驱结点waitStatus为-1，并且当前线程挂起，等待被唤醒
 if (shouldParkAfterFailedAcquire(p, node) &&
 parkAndCheckInterrupt())
 interrupted = true;
 }
 } finally {
 if (failed)
 cancelAcquire(node);
 }
 }
 
 private void setHeadAndPropagate(Node node, int propagate) {
 Node h = head;
 // head指向自己
 setHead(node);
 // 如果还有剩余量，继续唤醒下一个邻居线程
 if (propagate > 0 || h == null || h.waitStatus < 0) {
 Node s = node.next;
 if (s == null || s.isShared())
 doReleaseShared();
 }
 }

看到这里，你会不会一点熟悉的感觉，这个方法的逻辑怎么跟上面那个`acquireQueued()` 那么类似啊？对的，其实两个流程并没有太大的差别。只是`doAcquireShared()`比起独占模式下的获取锁上多了一步唤醒后继线程的操作，当获取完一定的资源后，发现还有剩余的资源，就继续唤醒下一个邻居线程。

## 3.2 释放锁 ##

共享模式释放锁的顶层方法是`releaseShared`，它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared()的源码：

public final boolean releaseShared(int arg) {
            if (tryReleaseShared(arg)) {
                doReleaseShared();
                return true;
            }
            return false;
        }

该方法同样包含两部分的逻辑：

*          tryReleaseShared：释放资源。
 *  doAcquireShared：唤醒后继结点。

跟`tryAcquireShared`方法一样，`tryReleaseShared`在AQS中没有具体的实现，由子同步器自己去定义，但功能都一样，就是释放一定数量的资源。

### 3.2.1doAcquireShared ###

唤醒后继结点的工作在`doReleaseShared()`方法中完成，我们可以看下它的源码：

private void doReleaseShared() {
     for (;;) {
      // 获取等待队列中的head结点
      Node h = head;
      if (h != null && h != tail) {
       int ws = h.waitStatus;
       // head结点waitStatus = -1,唤醒下一个结点对应的线程
       if (ws == Node.SIGNAL) {
        if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
         continue;            // loop to recheck cases
        // 唤醒后继结点
        unparkSuccessor(h);
       }
       else if (ws == 0 &&
          !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
        continue;                // loop on failed CAS
      }
      if (h == head)                   // loop if head changed
       break;
     }
    }

码没什么特别的，就是如果等待队列head结点的waitStatus为-1的话，就直接唤醒后继结点，唤醒的方法`unparkSuccessor()`在上面已经讲过了，这里也没必要再复述。

总的来看，AQS共享模式的运作流程和独占模式很相似，只要掌握了独占模式的流程运转，共享模式什么的不就那样吗，没难度。这也是我为什么共享模式讲解中不画流程图的原因，没必要嘛。

# 4.AbstractQueuedSynchronizer源码中文注释 #

package com.it.edu.aqs;
 
 import sun.misc.Unsafe;
 
 import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Date;
 import java.util.concurrent.TimeUnit;
 import java.util.concurrent.locks.Condition;
 import java.util.concurrent.locks.Lock;
 import java.util.concurrent.locks.LockSupport;
 
 /**
 * @author ：图灵-杨过
 * @date：2019/7/3
 * @version: V1.0
 * @slogan:天下风云出我辈，一入代码岁月催
 * description：AQS同步器框架源码
 */
 public abstract class AbstractQueuedSynchronizer
 extends AbstractOwnableSynchronizer
 implements java.io.Serializable {
 private static final long serialVersionUID = 7373984972572414691L;
 
 /**
 * Creates a new {@code AbstractQueuedSynchronizer} instance
 * with initial synchronization state of zero.
 */
 protected AbstractQueuedSynchronizer() { }
 
 /**
 * Wait queue node class.
 *
 * The wait queue is a variant of a "CLH" (Craig, Landin, and
 * Hagersten) lock queue. CLH locks are normally used for
 * spinlocks. We instead use them for blocking synchronizers, but
 * use the same basic tactic of holding some of the control
 * information about a thread in the predecessor of its node. A
 * "status" field in each node keeps track of whether a thread
 * should block. A node is signalled when its predecessor
 * releases. Each node of the queue otherwise serves as a
 * specific-notification-style monitor holding a single waiting
 * thread. The status field does NOT control whether threads are
 * granted locks etc though. A thread may try to acquire if it is
 * first in the queue. But being first does not guarantee success;
 * it only gives the right to contend. So the currently released
 * contender thread may need to rewait.
 *
 * To enqueue into a CLH lock, you atomically splice it in as new
 * tail. To dequeue, you just set the head field.
 * <pre>
 * +------+ prev +-----

# 5.ReentrantLock源码中文注释 #

package com.it.edu.aqs;
 /*
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */
 
 /*
 *
 *
 *
 *
 *
 * Written by Doug Lea with assistance from members of JCP JSR-166
 * Expert Group and released to the public domain, as explained at
 * http://creativecommons.org/publicdomain/zero/1.0/
 */
 
 import java.util.Collection;
 import java.util.concurrent.TimeUnit;
 import java.util.concurrent.locks.Condition;
 import java.util.concurrent.locks.Lock;
 
 /**
 * A reentrant mutual exclusion {@link Lock} with the same basic
 * behavior and semantics as the implicit monitor lock accessed using
 * {@code synchronized} methods and statements, but with extended
 * capabilities.
 *
 * A {@code ReentrantLock} is owned by the thread last
 * successfully locking, but not yet unlocking it. A thread invoking
 * {@code lock} will return, successfully acquiring the lock, when
 * the lock is not owned by another thread. The method will return
 * immediately if the current thread already owns the lock. This can
 * be checked using methods {@link #isHeldByCurrentThread}, and {@link
 * #getHoldCount}.
 *
 * The constructor for this class accepts an optional
 * fairness parameter. When set {@code true}, under
 * contention, locks favor granting access to the longest-waiting
 * thread. Otherwise this lock does not guarantee any particular
 * access order. Programs using fair locks accessed by many threads
 * may display lower overall throughput (i.e., are slower; often much
 * slower) than those using the default setting, but have smaller
 * variances in times to obtain locks and guarantee lack of
 * starvation. Note however, that fairness of locks does not guarantee
 * fairness of thread scheduling. Thus, one of many threads using a
 * fair lock may obtain it multiple times in succession while other
 * active threads are not progressing and not currently holding the
 * lock.
 * Also note that the untimed {

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70]: /images/20220829/85c3010511284027a084949147c751b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 1]: /images/20220829/76d5d7bddc7848a6a8c49ec96e15f5da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 2]: /images/20220829/6101e28c2c5443379b41f49bd0ec4225.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 3]: /images/20220829/8c65dbef1f944b47b7d3380cc828c29c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 4]: /images/20220829/ca4e109710454833929787e7b66b6480.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 5]: /images/20220829/d643e0391fbd4440a3b38e3a1546fdef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 6]: /images/20220829/9ba49b15e0614b8ba2e2b0a03382261c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2pva2VNcWM_size_16_color_FFFFFF_t_70 7]: /images/20220829/9f60273163d74847a153d120e7370a21.png