AQS详解

AQS的介绍
AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。

AQS原理
AQS：AbstractQuenedSynchronizer抽象的队列式同步器。是除了java自带的synchronized关键字之外的锁机制。
AQS的核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态（解释：就是通过volatile int state这个变量来判断该资源是否可以被当前发起资源请求的线程占用，如果state>0，那么就说明已经有线程在占用该资源了，其他线程就不能进行访问，除非state变成0，才可以申请访问该资源），如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例（解释：不是真的用队列Queue去存储这些节点，而是通过某种方式维持节点之间的关系，从而使得看起来像队列），仅存在节点之间的关联关系。

看个AQS(AbstractQueuedSynchronizer)原理图：




模板方法模式链接：
https://blog.csdn.net/qq_40241957/article/details/84898404


解释： ReentrantReadWriteLock是对“读操作”共享，“写操作”互斥的

自定义同步器
　　同步器代码实现

上面大概讲了一些关于AQS如何使用的理论性的东西，接下来，我们就来看下实际如何使用，直接采用JDK官方文档中的小例子来说明问题

解释：下面的Sync类对象是上面定义的静态内部类

同步器代码测试
测试下这个自定义的同步器，我们使用之前文章中做过的并发环境下a++的例子来说明问题（a++的原子性其实最好使用原子类AtomicInteger来解决，此处用Mutex有点大炮打蚊子的意味，好在能说明问题就好）

package juc;

import java.util.concurrent.CyclicBarrier;

/**
 * Created by chengxiao on 2017/7/16.
 */
public class TestMutex {
    private static CyclicBarrier barrier = new CyclicBarrier(31);
    private static int a = 0;
    private static  Mutex mutex = new Mutex();

    public static void main(String []args) throws Exception {
        //说明:我们启用30个线程，每个线程对i自加10000次，同步正常的话，最终结果应为300000；
        //未加锁前
        for(int i=0;i<30;i++){
            Thread t = new Thread(new Runnable() {
                @Override
                public void run() {
                    for(int i=0;i<10000;i++){
                        increment1();//没有同步措施的a++；
                    }
                    try {
                        barrier.await();//等30个线程累加完毕
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            });
            t.start();
        }
        barrier.await();
        System.out.println("加锁前，a="+a);
        //加锁后
        barrier.reset();//重置CyclicBarrier
        a=0;
        for(int i=0;i<30;i++){
            new Thread(new Runnable() {
                @Override
                public void run() {
                    for(int i=0;i<10000;i++){
                        increment2();//a++采用Mutex进行同步处理
                    }
                    try {
                        barrier.await();//等30个线程累加完毕
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
        barrier.await();
        System.out.println("加锁后，a="+a);
    }
    /**
     * 没有同步措施的a++
     * @return
     */
    public static void increment1(){
        a++;
    }
    /**
     * 使用自定义的Mutex进行同步处理的a++
     */
    public static void increment2(){
        mutex.lock();
        a++;
        mutex.unlock();
    }
}

TestMutex

这运行结果充分说明了i++不是原子操作，可能发生线程安全问题

源码详解

解释：为什么会存在争夺的情况，原因是因为不仅仅是有后继节点线程会去抢资源，还可能会有新产生的线程也会去抢资源，所以会产生争夺现象

提示：下面的源码可能看不懂，下图第2张图是源码的翻版

3.1 acquire(int)

小疑问：上述为什么会是被中断呢？

3.1.2 addWaiter(Node)

小疑问：下面addWaiter()方法里面还有enq（）是入列（enqueue）的意思



——————————————————————————————————

3.1.2.1 enq(Node)

提示： 要注意下面的enq()方法体里面有一个for死循环，这个就是自旋，一直做for循环，直到CAS,执行成功return t为止
①因为存在争用，可能多个线程入队，所以CAS操作来保证入队的原子性
②tai节点又是volatile的，保证可见性

3.1.3 acquireQueued(Node, int)

**解释：**上述说的“如果自己可以休息”就是说本线程是否被请求中断不是自身控制的，是由外在对象改变的

到这里了，我们先不急着总结acquireQueued()的函数流程，先看看shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()具体干些什么。

3.1.3.1 shouldParkAfterFailedAcquire(Node, Node)

整个流程中，如果前驱结点的状态不是SIGNAL，那么自己就不能安心去休息，需要去找个安心的休息点，同时可以再尝试下看有没有机会轮到自己拿号。

3.1.3.2 parkAndCheckInterrupt()

如果线程找好安全休息点后，那就可以安心去休息了。此方法就是让线程去休息，真正进入等待状态。

提示： 需要注意的是，Thread.interrupted()会清除当前线程的中断标记位。

对acquireQueue()大总结：

3.2 release(int)

上一小节已经把acquire()说完了，这一小节就来讲讲它的反操作release()吧。此方法是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。这也正是unlock()的语义，当然不仅仅只限于unlock()。下面是release()的源码：

　逻辑并不复杂。它调用tryRelease()来释放资源。有一点需要注意的是，它是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自定义同步器在设计tryRelease()的时候要明确这一点！！

3.2.1 tryRelease(int)

下面是AQS的方法源码，需要我们去重写之

　跟tryAcquire()一样，这个方法是需要独占模式的自定义同步器去实现的。正常来说，tryRelease()都会成功的，因为这是独占模式，该线程来释放资源，那么它肯定已经拿到独占资源了，直接减掉相应量的资源即可(state-=arg)，也不需要考虑线程安全的问题。但要注意它的返回值，上面已经提到了，release()是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自义定同步器在实现时，如果已经彻底释放资源(state=0)，要返回true，否则返回false。

3.2.2 unparkSuccessor(Node)

此方法用于唤醒等待队列中下一个线程。下面是源码：
小疑问：可以看到下面的for循环是从同步队列的尾部往前逐个遍历的，然后逐个往前遍历，直到找出最前的那个未放弃的线程（有效的）

这个函数并不复杂。一句话概括：用unpark()唤醒等待队列中最前边的那个未放弃线程，这里我们也用s来表示吧。此时，再和acquireQueued()联系起来，s被唤醒后，进入if (p == head && tryAcquire(arg))的判断（即使p!=head也没关系，它会再进入shouldParkAfterFailedAcquire()寻找一个安全点。这里既然s已经是等待队列中最前边的那个未放弃线程了，那么通过shouldParkAfterFailedAcquire()的调整，s也必然会跑到head的next结点，下一次自旋p==head就成立啦），然后s把自己设置成head标杆结点，表示自己已经获取到资源了，acquire()也返回了！！And then, DO what you WANT!

3.2.3 小结
　　release()是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。

共享模式下的方法

3.3 acquireShared(int)

此方法是共享模式下线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。下面是acquireShared()的源码：

3.3.1 doAcquireShared(int)

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


解释： 从上面的这段话就可以看出，并发就比较低效，是要在代码中处理这个死局问题的

3.3.1.1 setHeadAndPropagate(Node, int)

小疑问： 可能这里不是很明白为什么要加上 h ==null和h.waitStatus<0?从上图可以看出p.next=null（解释： p是原头节点，p.next=null目的是为了回收原头节点）是在setHeadAndPropagate()函数之后执行的，说明在setHeadAndPropagate()函数体里面原头节点肯定不为null,那么为什么要在if()里面加上h ==null和h.waitStatus<0呢？

此方法在setHead()的基础上多了一步，就是自己苏醒的同时，如果条件符合（比如还有剩余资源），还会去唤醒后继结点，毕竟是共享
doReleaseShared()我们留着下一小节的releaseShared()里来讲。
　　

3.4 releaseShared()

上一小节已经把acquireShared()说完了，这一小节就来讲讲它的反操作releaseShared()吧。此方法是共享模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared()的源码：
　
　
　小疑问： 我感觉这样做的思路岂不是互斥了吗

3.4.1 doReleaseShared()

此方法主要用于唤醒后继。下面是它的源码：