AQS 简介

java的内置锁一直都是备受争议的，在JDK 1.6之前，synchronized这个重量级锁其性能一直都是较为低下，虽然在1.6后，进行大量的锁优化策略,但是与Lock相比synchronized还是存在一些缺陷的：虽然synchronized提供了便捷性的隐式获取锁释放锁机制（基于JVM机制），但是它却缺少了获取锁与释放锁的可操作性，可中断、超时获取锁，且它为独占式在高并发场景下性能大打折扣。

在介绍Lock之前，我们需要先熟悉一个非常重要的组件，掌握了该组件JUC包下面很多问题都不在是问题了。该组件就是AQS。

AQS：AbstractQueuedSynchronizer，即队列同步器。它是构建锁或者其他同步组件的基础框架（如ReentrantLock、ReentrantReadWriteLock、Semaphore等），JUC并发包的作者（Doug Lea）期望它能够成为实现大部分同步需求的基础。它是JUC并发包中的核心基础组件。

AQS解决了实现同步器时涉及当的大量细节问题，例如获取同步状态、FIFO同步队列。基于AQS来构建同步器可以带来很多好处。它不仅能够极大地减少实现工作，而且也不必处理在多个位置上发生的竞争问题。

在基于AQS构建的同步器中，只能在一个时刻发生阻塞，从而降低上下文切换的开销，提高了吞吐量。同时在设计AQS时充分考虑了可伸缩行，因此J.U.C中所有基于AQS构建的同步器均可以获得这个优势。

AQS 原理简介

AQS 内部简单来说其实主要是由三部分组成的

state 这个状态用来声明对象是否已经被线程占有，状态为 0 表示没有，state > 0则表示已经被其他线程占有
当前线程声明当前占有的线程
排队队列等待占有该对象的线程

AQS 在 Java 中的应用

ReentrantLock、ReentrantReadWriteLock、Semaphore等很多 JUC的加锁方式都是继承自 AQS，比如：

    /**

     * Base of synchronization control for this lock. Subclassed

     * into fair and nonfair versions below. Uses AQS state to

     * represent the number of holds on the lock.

     */

    abstract static class Sync extends AbstractQueuedSynchronizer {

        private static final long serialVersionUID = -5179523762034025860L;

        /**

         * Performs {@link Lock#lock}. The main reason for subclassing

         * is to allow fast path for nonfair version.

         */

        abstract void lock();

        /**

         * Performs non-fair tryLock.  tryAcquire is implemented in

         * subclasses, but both need nonfair try for trylock method.

         */

        final boolean nonfairTryAcquire(int acquires) {

            final Thread current = Thread.currentThread();

            int c = getState();

            if (c == 0) {

                if (compareAndSetState(0, acquires)) {

                    setExclusiveOwnerThread(current);

                    return true;

                }

            }

            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;

        }

        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;

        }

        protected final boolean isHeldExclusively() {

            // While we must in general read state before owner,

            // we don't need to do so to check if current thread is owner

            return getExclusiveOwnerThread() == Thread.currentThread();

        }

        final ConditionObject newCondition() {

            return new ConditionObject();

        }

        // Methods relayed from outer class

        final Thread getOwner() {

            return getState() == 0 ? null : getExclusiveOwnerThread();

        }

        final int getHoldCount() {

            return isHeldExclusively() ? getState() : 0;

        }

        final boolean isLocked() {

            return getState() != 0;

        }

        /**

         * Reconstitutes the instance from a stream (that is, deserializes it).

         */

        private void readObject(java.io.ObjectInputStream s)

            throws java.io.IOException, ClassNotFoundException {

            s.defaultReadObject();

            setState(0); // reset to unlocked state

        }

    }

结合 ReentrantLock 解释 AQS

这里我们说简单说一个业务场景，代码如下：

				ReentrantLock reentrantLock = new ReentrantLock();

        reentrantLock.lock();

        // 一大堆代码

        reentrantLock.unlock();

        // 一大堆代码

现在有多个线程调用这个方法，但是这个里面有一个 map 是会被多个线程占用的。那么这个时候会发生什么呢？

线程 1 和线程 2 尝试获取加锁

1、当线程1处理的时候，对个线程尝试加锁，然后通过 CAS 加锁成功，将 AQS 的 state 修改为 1（默认值为 0），当前线程设置为线程 1

2、这个时候线程 2 开始处理，尝试加锁。CAS 的时候发现这个state 状态已经不是 0 了，说明某个线程正在占用。加锁失败。

3、线程 2 进入 AQS 的排队队列，然后线程 2 挂起。

线程 1 逻辑执行完毕，释放锁。线程 2 尝试获取锁

1、当线程 1 完成业务逻辑后，执行 unlock 操作的时候，会将 state 修改为 0，然后将当前线程变量修改为 null

2、唤醒排队队列中的第一个线程，让其重新出尝试加锁

非公平锁

1、Reentrantlock默认是非公平锁。

2、为什么说他是非公平锁呢，还是刚才线程 1 结束，唤醒线程 2 的场景。

3、如果在唤醒线程 2 之后，线程 2 加锁成功之前，出现了线程 3，线程 3 直接进行CAS 加锁，而且还成功了

4、这时候线程 2 就尴尬了，他发现自己被唤醒之后还是 CAS 加锁失败，他就会又回到队列里面去重新等待被唤醒。

为什么说是非公平的，明明大家都在排队，这个时候突然插队进来一个哥们，这对排队的人来说是不公平的

公平锁

1、在初始化 Reentrantlock 的时候默认值给一个 true ，这个时候他就是公平锁了。

2、还是刚才的场景，如果线程 2 被唤醒之后有一个新的线程，如线程 3 尝试加锁，那他会判断队列中是否有值。

3、如果没有值，则进行CAS 加锁尝试

4、如果有值则插入队列等待排队唤醒

巴特西

什么是 AQS？简单说一下 ReentrantLock 的原理？