AQS的几个灵魂拷问

java并发包下很多API都是基于AQS来实现的加锁和释放锁等功能的，比如ReentrantLock、ReentrantReadWriteLock底层都是基于AQS来实现的。AQS是java并发包的基础类，今天这一节主要是梳理AQS的重要概念和原理细节。

ReentrantLock核心组件

ReentrantLock核心有3个组件：state、owner、AQS（抽象队列同步器，简单的说就是一个等待队列Queue）。如下图所示：

ReentrantLock内部包含了一个三个静态内部类，Sync，FairSync和NonfairSync，其中FairSync和NonfairSync都是继承自AQS。

AQS中的维护了一个state变量，通过volatile修饰的int类型的，代表了加锁的状态。初始状态下，这个state的值是0。

private volatile int state;

AQS中维护了head、tail以及Node内部类等，这里构成了一个FIFO（先进先出）的线程等待队列。

private transient volatile Node head;
private transient volatile Node tail;

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;
        static final int CONDITION = -2;
        static final int PROPAGATE = -3;

        volatile Node prev;
        volatile Node next;
        //节点持有的线程
        volatile Thread thread;
        //....省略其他...
    }

同时AQS又继承了AbstractOwnableSynchronizer类，因此又维护了一个owner变量，用来记录当前加锁的是哪个线程，初始化状态下，这个变量是null。

private transient Thread exclusiveOwnerThread

AQS加锁和释放原理

1、加锁流程

假设有两个线程同时过来申请锁资源，线程1先获得锁，线程2需要等待的话，主要的流程如下：

• 两个线程同时调用 lock 方法，线程1通过CAS(0,1)操作将state值从0变为1，成功加锁。
• 线程1通过CAS(0,1)成功后，设置当前加锁线程为自己
• 线程2此时也进行CAS(0,1)，此时state已经为1调用肯定会失败
• 于是再查看加锁线程是否为自己，如果不是则放入等待队列
• 线程2此时调用LockSupport.park()挂起当前线程。

2.释放流程

• 线程1执行任务成功调用 unlock 方法，state变量的值递减1，如果state值为0，加锁线程设置为null，彻底释放锁。
• 此时进入等待队列的队头，调用LockSupport.unpark()唤醒线程2重新尝试加锁
• 线程2CAS操作将state从0变为1成功之后代表加锁成功，将state设置为1。
• 把“加锁线程”设置为线程2自己，同时线程2自己就从等待队列中出队了。

公平与非公平，可重入与独占

1.ReentrantLock是如何实现非公平和公平的？

ReentrantLock通过两个Sync的子类——FairSync和NonfairSync，默认是非公平锁的实现，先来看非公平的源码：

static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;
    final void lock() {
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
}

再看公平锁的源码，和上面相比仅仅是一个if逻辑的区别。非公平的锁NonfairSync会多了一个判断，先尝试来加个锁。

static final class FairSync extends Sync {
    final void lock() {
        acquire(1);
    }
}

非公平的这个if操作可以理解为如果线程1释放了，别人过来加锁，直接先尝试插个队的意思，有可能AQS队列中的线程2还没被唤醒了，被别人抢走了锁，让别的线程加锁成功了。可以概况为一句话讲，由于非公平锁，加锁前多了一个尝试获取锁的操作,导致了可能会有线程插队。

另外在公平锁的尝试加锁过程中，还多了一个 hasQueuedPredecessors()的判断，这里限制了如果有人排队，其他线程就不能插队加锁。所以就算线程1释放锁，线程3过来加锁，由于lock方法没有了非公平锁的if（上来尝试CAS修改state，加锁的代码），线程3就只能入队。

这里可以看到公平锁比非公平锁的代码多了一个判断，判断队列中是否有等待线程。有的话也只能乖乖排队。

总结来看，公平锁主要体现在两点上：

• 第一处是在lock方法加锁时，没有尝试CAS加锁修改state的if判断，保证释放锁的时候不会有线程插队加锁。（非公平锁中，入队过程可能还会尝试加锁，也有可能造成插队加锁，大家可以自己屡一下代码看看）
• 第二处是如果已经有人加锁，在入队过程中，也通过一个hasQueuedPredecessors判断保证了按顺序入队，在入队的过程中不会再次尝试加锁。

2.可重入锁和不可重入锁

ReentrantLock通过AQS的state变量巧妙的实现了可重入加锁。如果是同一个线程调用了lock方法，加锁，state会在现有值上加+1，每再次加一次锁，就是一次可重入，所以就加锁可重入锁。也就是说：同一个线程可以使用同一个ReentrantLock进行反复加锁。（sychronized的重量级Monitor锁也是可重入锁。）

另外，释放锁的话，肯定需要释放所多次，同一个线程加锁了几次，就需要释放几次，需要将state值恢复为0才算真正的释放锁，别的线程才能获取到。

3. 独占锁 VS 共享锁

所谓独占锁，就是只要有一个线程加锁，其他人都得靠边站，这把锁属于某个线程独占，这就是独占锁。默认reentrantLock.lock创建的是非公平的可重入独占锁！

共享锁是什么意思呢？意思就是可以和别的线程同时持有一把锁，比如之后要讲的读写锁。线程1加了读锁，线程2还是可以加读锁的，它们共享一把锁。这样的锁就是一把共享锁。

参考引用：

1、初识ReenranctLock加锁的AQS底层原理
2、你知道ReentrantLock 公平、非公平、可重入、独占、共享锁都是什么意思吗？
3、我画了35张图，就是为了让你深入理解 AQS
4、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？【石杉的架构笔记】