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