面试官：CAS和AQS底层原理了解？我：一篇文章堵住你的嘴

写在前面

用XMind画了一张导图记录Java并发编程的学习笔记和一些面试解析（源文件对部分节点有详细备注和参考资料，欢迎关注个人公众号：阿风的架构笔记后台发送【并发】拿下载连接，已经完善更新）：

CAS（Compare And Swap）原理分析

字面意思是比较和交换，先看看下面场景（A 和 B 线程同时执行下面的代码）：

int i = 10;  //代码 1
i = 20;      //代码 2
复制代码

场景 1：A 线程执行代码 1 和代码 2，而后 B 线程执行代码 1 和代码 2，CAS 成功。

场景 2：A 线程执行代码 1，此时 B 线程执行代码 1 和代码 2，A 线程执行代码 2，CAS 不成功，为何呢？

由于 A 线程执行代码 1 时候会旧值（i 的内存地址的值 10）保存起来，执行代码 2 的时候先判断 i 的最新值（可能被其余线程修改了）跟旧值比较，若是相等则把 i 赋值为 20，若是不是则 CAS 不成功。CAS 是一个原子性操做，要么成功要么失败，CAS 操做用得比较多的是 sun.misc 包的 Unsafe 类，而 Java 并发包大量使用 Unsafe 类的 CAS 操做，好比：AtomicInteger 整数原子类（本质是自旋锁 + CAS），CAS 不需加锁，提升代码运行效率。也是一种乐观锁方式，咱们一般认为在大多数场景下不会出现竞争资源的状况，若是 CAS 操做失败，会不断重试直到成功。

CAS 优势：资源竞争不大的场景系统开销小。

CAS 缺点：

• 若是 CAS 长时间操做失败，即长时间自旋，会致使 CPU 开销大，可是可使用 CPU 提供的 pause 指令，这个 pause 指令可让自旋重试失败时 CPU 先睡眠一小段时间后再继续自旋重试 CAS 操做，jvm 支持 pause 指令，可让性能提高一些。
• 存在 ABA 问题，即原来内存地址的值是 A，而后被改成了 B，再被改成 A 值，此时 CAS 操做时认为该值未被改动过，ABA 问题能够引入版本号来解决，每次改动都让版本号 +1。Java 中处理 ABA 的一个方案是 AtomicStampedReference 类，它是使用一个 int 类型的字段做为版本号，每次修改以前都先获取版本号和当前线程持有的版本号比对，若是一致才进行修改操做，并把版本号 +1。
• 没法保证代码块的原子性，CAS 只能保证单个变量的原子性操做，若是要保证多个变量的原子性操做就要使用悲观锁了。

AQS（AbstractQueuedSynchronizer）原理分析

字面意思是抽象的队列同步器，AQS 是一个同步器框架，它制定了一套多线程场景下访问共享资源的方案，Java 中不少同步类底层都是使用 AQS 实现，好比：ReentrantLock、CountDownLatch、ReentrantReadWriteLock，这些 java 同步类的内部会使用一个 Sync 内部类，而这个 Sync 继承了 AbstractQueuedSynchronizer 类，这是一种模板方法模式，因此说这些同步类的底层是使用 AQS 实现。

AQS 内部维护了一个 volatile 修饰的 int state 属性（共享资源）和一个先进先出的线程等待队列（即多线程竞争共享资源时被阻塞的线程会进入这个队列）。由于 state 是使用 volatile 修饰，因此在多线程以前可见，访问 state 的方式有 3 种，getState()、setState()和 compareAndSetState()。

AQS 定义了 3 种资源共享方式：

• 独占锁（exclusive），保证只有一条线程执行，好比 ReentrantLock、AtomicInteger。
• 共享锁（shared），容许多个线程同时执行，好比 CountDownLatch、Semaphore。
• 同时实现独占和共享，好比 ReentrantReadWriteLock，容许多个线程同时执行读操做，只容许一条线程执行写操做。

ReentrantLock 和 CountDownLatch 都是自定义同步器，它们的内部类 Sync 都是继承了 AbstractQueuedSynchronizer，独占锁和共享锁的区别在于各自重写的获取和释放共享资源的方式不同，至于线程获取资源失败、唤醒出队、中断等操做 AQS 已经实现好了。

ReentrantLock

state 的初始值是 0，即没有被锁定，当 A 线程 tryAcquire() 时会独占锁住 state，而且把 state+1，而后 B 线程（即其余线程）tryAcquire() 时就会失败进入等待队列，直到 A 线程 tryRelease() 释放锁把 state-1，此时也有可能出现重入锁的状况，state-1 后的值不是 0 而是一个正整数，由于重入锁也会 state+1，只有当 state=0 时，才表明其余线程能够 tryAcquire() 获取锁。

CountDownLatch

8 人赛跑场景，即开启 8 个线程进行赛跑，state 的初始值设置为 8（必须与线程数一致），每一个参赛者跑到终点（即线程执行完毕）则调用 countDown()，使用 CAS 操做把 state-1，直到 8 个参赛者都跑到终点了（即 state=0），此时调用 await() 判断 state 是否为 0，若是是 0 则不阻塞继续执行后面的代码。

tryAcquire()、tryRelease()、tryAcquireShared()、tryReleaseShared() 的详细流程分析

tryAcquire() 详细流程以下：

1. 调用 tryAcquire() 尝试获取共享资源，若是成功则返回 true;
2. 若是不成功，则调用 addWaiter() 把此线程构造一个 Node 节点（标记为独占模式），并使用 CAS 操做把节点追加到等待队列的尾部，而后该 Node 节点的线程进入自旋状态;
3. 线程自旋时，判断自旋节点的前驱节点是否是头结点，而且已经释放共享资源（即 state=0），自旋节点是否成功获取共享资源（即 state=1），若是三个条件都成立则自旋节点设置为头节点，若是不成立则把自旋节点的线程挂起，等待前驱节点唤醒。

tryRelease() 详细流程以下：

1. 调用 tryRelease() 释放共享资源，即 state=0，而后唤醒没有被中断的后驱节点的线程;
2. 被唤醒的线程自旋，判断自旋节点的前驱节点是否是头结点，是否已经释放共享资源（即 state=0），自旋节点是否成功获取共享资源（即 state=1），若是三个条件都成立则自旋节点设置为头节点，若是不成立则把自旋节点的线程挂起，等待被前驱节点唤醒。

tryAcquireShared() 详细流程以下：

1. 调用 tryAcquireShared() 尝试获取共享资源，若是 state>=0，则表示同步状态（state）有剩余还可让其余线程获取共享资源，此时获取成功返回;
2. 若是 state<0，则表示获取共享资源失败，把此线程构造一个 Node 节点（标记为共享模式），并使用 CAS 操做把节点追加到等待队列的尾部，而后该 Node 节点的线程进入自旋状态;
3. 线程自旋时，判断自旋节点的前驱节点是否是头结点，是否已经释放共享资源（即 state=0），再调用 tryAcquireShared() 尝试获取共享资源，若是三个条件都成立，则表示自旋节点可执行，同时把自旋节点设置为头节点，而且唤醒全部后继节点的线程。
4. 若是不成立，挂起自旋的线程，等待被前驱节点唤醒。

tryReleaseShared() 详细流程以下：

1. 调用 tryReleaseShared() 释放共享资源，即 state-1，而后遍历整个队列，唤醒全部没有被中断的后驱节点的线程;
2. 被唤醒的线程自旋，判断自旋节点的前驱节点是否是头结点，是否已经释放共享资源（即 state=0），再调用 tryAcquireShared() 尝试获取共享资源，若是三个条件都成立，则表示自旋节点可执行，同时把自旋节点设置为头节点，而且唤醒全部后继节点的线程。
3. 若是不成立，挂起自旋的线程，等待被前驱节点唤醒。

看完三件事❤️

若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

1. 点赞，转发，有大家的 『点赞和评论』，才是我创造的动力。
2. 关注公众号 『 阿风的架构笔记 』，不按期分享原创知识。
3. 同时能够期待后续文章ing🚀
4. 关注后回复【666】扫码便可获取架构进阶学习资料包