写这篇文档的前提是什么呢，当然不是为了让大家变的优秀，而是让大家在面试的时候，去跟面试官"撕逼"，谈谈你对AQS的理解？
在很多时候呀，一家没任何"逼格"的小型企业，单日用户使用量也就可怜兮兮的几百人的时候，但是有一个做大做强的愿景的情况下，就不得不问你一些并发相关的问题,这个时候让我们这样的CRUD崽内心承受着一万点的暴击伤害，害~
因为首先， 很多同学可能对AQS是个啥都不太清楚，或者只是仅仅听过AQS这个名词，但是可能连全称怎么拼写都不知道。
AQS到底是个啥啊？他是不是一种思想？我们平时在实际项目中怎么用到这个AQS？真是让人头大头大
总结起来，AQS就是给人一种让人头皮发麻，一头雾水的感觉，百度搜索什么是AQS，好家伙，一大篇的理论扒古文的知识网上丢，看几篇之后就放弃了，或者说看几篇之后还是不太理解，学个屁。
所以基于上述痛点，这篇文章就用最简单的大白话配合N多张亲自手绘图，给大家讲清楚AQS到底是个什么东西？
让各位同学面试被问到这个问题时，不至于不知所措，好歹也可以跟半吊子面试官打的有来有回。~
言归正传，在说AQS之前，些来聊聊，ReentrantLock跟AQS之间的联系
你说你不知道什么是ReentrantLock，那行，出门左拐，远走不送。
问：如果我们用Java并发包下的ReentrantLock来进行加锁跟释放锁，是怎么个实现法？ 答：那还不简单，直接就lock()方法加锁，unlock()方法释放锁,看一段代码。
上面这段代码很简单吧，无非就是用个lock对象，给它加锁跟释放锁。这个时候你可能会有点迷惑，这玩意跟AQS有啥关系啊。
别急！别急！别急！关系大了去了，因为Java并发包下的加锁跟释放锁大部分都是基于AQS去实现的，不信你打开ReentrantLock或者ReentrantReadWriteLock源码来看看，看它们的Sync内部类是否都继承了一个叫 AbstractQueuedSynchronizer的东西，这个东西我们就叫它AQS。 说白了，ReentrantLock内部包含了一个AQS对象，也就是AbstractQueuedSynchronizer类型的对象。 这个AQS对象就是ReentrantLock可以实现加锁和释放锁的关键性的核心组件。
问：那你可以给我讲一下ReentrantLock加锁跟释放锁的底层实现原理吗？重头戏来了
如果哦，我们用ReentrantLock的lock()方法进行加锁，那么会发生什么样的事情呢？很简单，AQS对象内部有一个核心的变量叫做state，是int类型的，代表了加锁的状态。初始状态下，这个state的值是0。 另外，这个AQS内部还有一个关键变量，用来记录当前加锁的是哪个线程，初始化状态下，这个变量是null，它也有一个响亮的名字叫exclusiveOwnerThread。
紧接着线程跑过来调用ReentrantLock的lock()方法尝试进行加锁，这个加锁的过程，直接就是用CAS操作将state值从0变为1。如果之前没人加过锁，那么state的值肯定是0，此时线程1就可以加锁成功。一旦线程1加锁成功了之后，就可以设置当前加锁线程是自己。所以大家看下面的图，就是线程1跑过来加锁的一个过程。
其实看到这里的时候，大家对AQS有没有一点儿感觉，就好比情窦初开的样子。其实啊，说白了，就是并发包里面的一个核心组件，它里面有一个叫state跟加锁线程变量等核心玩意，维护了加锁的一些状态。
这个ReentrantLock是个啥，Reentrant嘛，不就是可重入嘛，呐ReentrantLock不就是可重入锁嘛，那么啥是可重入锁呢，就是你可以对一个ReentrantLock对象多次执行lock()加锁和unlock()释放锁，也就是可以对一个锁加多次，叫做可重入加锁。接下来手撸段代码给大家演示一下。
其实每次线程1可重入加锁一次，会判断一下当前加锁线程就是自己，那么他自己就可以可重入多次加锁，每次加锁就是把state的值给累加1，别的没啥变化。
问：如果线程1加锁了之后，线程2跑过来加锁会怎么样呢？
线程2跑过来一下看到，哎呀！state的值不是0啊？被人捷足先登了？所以CAS操作将state从0变为1的过程会失败，因为state的值当前为1，说明已经有人加锁了！
我堂堂的线程2怎么会被别人抢先一步呢？接着线程2会看一下，是不是自己之前加的锁啊？然后就跑去找 “加锁线程”， “加锁线程” 这个变量明确记录了是线程1占用了这个锁，所以线程2此时就是加锁失败。
给大家来一张图，一起来感受一下这个过程：
接着，线程2会将自己放入AQS中的一个等待队列，因为自己尝试加锁失败了，此时就要将自己放入队列中来等待，等待线程1释放锁之后，自己就可以重新尝试加锁了，这就好比喜欢的女神被人抢了，只能些进入备胎行列，等着女神跟人别分手，自己就能跟心爱的女神在一起了。
所以大家可以看到，AQS是如此的核心！AQS内部还有一个等待队列，专门放那些加锁失败的线程！俗称备胎！
同样，给大家来一张图，一起感受一下：
接着，线程1在执行完自己的业务逻辑代码之后，就会释放锁！他释放锁的过程非常的简单，就是将AQS内的state变量的值递减1，如果state值为0，则彻底释放锁，会将“加锁线程”变量也设置为null！废话不多说，上图！！！
接下来，线程2终于有机会上位了，会从等待队列的队头唤醒线程2重新尝试加锁。
好！线程2现在就重新尝试加锁，这时还是用CAS操作将state从0变为1，此时就会成功，成功之后代表加锁成功，就会将state设置为1。
此外，还要把 “加锁线程” 设置为线程2自己，同时线程2自己就从等待队列中出队了。
最后再来一张图，大家来看看这个过程。
总结
OK，本文到这里为止，借着ReentrantLock的加锁和释放锁的过程，给大家初步的讲了一些其底层依赖的AQS的核心原理。
基本上大家把这篇文章看懂，以后再也不会担心面试的时候被问到：谈谈你对AQS的理解这种问题⭐️⭐️了。
其实一句话总结：AQS就是一个并发包的基础组件，用来实现各种锁，各种同步组件的。
它包含了state变量、加锁线程、等待队列等并发中的核心组件。