AQS浅析及其实现类

        AQS（AbstractQueuedSynchronizer），抽象队列同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它。

        AQS的核心思想是如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态；如果被请求的共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配，这个机制AQS是用CLH队列的变体实现的，即将暂时获取不到锁的线程加入到队列中。

AQS整体框架：

        上图中有颜色的为Method，无颜色的为Attribution。

        AQS中包含了三个属性值，head、tail、state。head为CLH队列（等待队列）的头节点，tail为CLH队列（等待队列）的尾节点。state表示同步状态，是由Volatile修饰的，用于展示当前临界资源的获锁情况。

        CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例，仅存在节点之间的关联关系。AQS是将每一条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node），来实现锁的分配。

        核心在于volatile int state（代表共享资源,用于标识是否持有锁）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。如果获取同步资源失败时，会将当前线程及等待信息等构建成一个Node，将Node放到FIFO队列里，同时阻塞当前线程，当线程将同步状态state释放时，会把FIFO队列中的首节点唤醒，使其获取同步状态state。

Node节点：

        上面这个图中node节点的属性值及方法：
        

  几个方法和属性值的含义：

 waitStatus有下面几个枚举值：

 

同步状态State：

        ​​​​​​​AQS的同步状态——State。AQS中维护了一个名为state的字段，意为同步状态，是由Volatile修饰的，用于展示当前临界资源的获锁情况。

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

        不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：

        isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
        tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
        tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
        tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
        tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

        ReentrantLock是独占锁，所以实现了tryAcquire-tryRelease

        以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

　　再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

        一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

 ReentrantReadWriteLock：

        为什么会出现ReentrantReadWriteLock类呢？因为ReentrantLock其实和synchronized关键字一样，一次只能有一个线程访问被锁住的代码，虽然安全，但是效率有点感人。如果一些共享变量，访问的次数远远大于修改的次数，那么是不是可以只让修改的操作互斥呢？所以ReentrantReadWriteLock类就应运而生

构成
        ReentrantReadWriteLock有两个锁，读锁（lock.readLock.lock()/lock.readLock.unlock()）和写锁(lock.writeLock.lock()/lock.writeLock.unlock())
        其中，读锁是共享锁，写锁是排他锁。怎么理解呢？只要此时没有线程Thread进行写入操作，此时进行读取操作的多个Thread都可以获取读锁，而进行写入操作的Thread只有在获取写锁后才能进行写入操作。即多个Thread可以同时进行读取操作，但是同一时刻只允许一个Thread进行写入操作

特征
        读写、写读、写写都是互斥的；读读是异步的，非互斥

 CountDownLatch

        官方介绍：它是一个同步工具类，允许一个或多个线程一直等待，直到其他线程运行完成后再执行。

        如何做到的上诉让线程等待呢？

        1.CountDownLatch的构造函数中的count就是闭锁需要等待的线程数量。这个值只能被设置一次，而且不能重新设置；

        2.需要等待的线程就可以调用它的await()方法。调用该方法的线程会被阻塞，直到构造方法传入的 count 减到 0 的时候，才能继续往下执行；        

        3.构造函数中的count如何减为0呢？在运行的线程中调用countDown()方法，使 count 计数值 减 1；当count个线程都执该方法时，步骤2中就可以继续执行了。

CountDownLatch 工作原理：

        CountDownLatch是通过一个计数器来实现的，计数器的初始值为线程的数量；调用await()方法的线程会被阻塞，直到计数器 减到 0 的时候，才能继续往下执行。

        调用了await()进行阻塞等待的线程，它们阻塞在Latch门闩/栅栏上；只有当条件满足的时候（countDown() N次，将计数减为0），它们才能同时通过这个栅栏；以此能够实现让所有的线程站在一个起跑线上。

        底层基于 AbstractQueuedSynchronizer（AQS） 实现，CountDownLatch 构造函数中指定的count直接赋给AQS的state；每次countDown()则都是release(1)减1，最后减到0时unpark阻塞线程；这一步是由最后一个执行countdown方法的线程执行的。
        而调用await()方法时，当前线程就会判断state属性是否为0，如果为0，则继续往下执行，如果不为0，则使当前线程进入等待状态，直到某个线程将state属性置为0，其就会唤醒在await()方法中等待的线程。

        本质上也是一个共享锁。