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

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 内部简单来说其实主要是由三部分组成的

1. state 这个状态用来声明对象是否已经被线程占有，状态为 0 表示没有，state > 0则表示已经被其他线程占有

2. 当前线程 声明当前占有的线程

3. 排队队列 等待占有该对象的线程

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、如果有值则插入队列等待排队唤醒