一.CAS

J.U.C 并发包中的很多类都涉及到了 CAS，可以说没有 CAS 和 volatile 就没有 J.U.C 并发包，可见CAS是多么的重要。

1、什么是CAS

CAS其实并不是一种工具或者被很多人认为的与”乐观锁”等价的东西，CAS是一种算法，它的基本思想就是拿着预期数A与内存数V比较，如果A和V相同，那么则证明V没有被修改，把它修改为想要写入的数B，如果不同则返回。

2、CAS解决的场景

我们都知道JMM是线程与主内存的一层抽象，也就是每个线程都有自己的本地内存，每个线程都会先更新自己的本地内存，然后再把新值刷新到主内存中，那么问题来了，所有的线程都想要同步更新到主内存中
CAS就是为了保证这种情况下线程安全的。所有线程当都想更新主内存中同一个变量时，会使用CAS算法，确保只有一个线程更新成功，其他线程会自旋重试。

3、CAS的问题

因为CAS是让失败的线程尝试自旋等待，所以带来的第一个问题就是自旋导致CPU性能下降，而第二个问题就是接下来要讲的ABA问题了

二.ABA

1、什么是ABA问题

CAS的第一步就是对预期值和内存数进行比较，但是并不清楚这个数有没有真正地被改过，也可能同一个线程从A改成了B又改成A，有的需求只在乎结果可能影响不大，但有的需求对中间过程也很在意，这样就会带来了问题

2、解决ABA问题

解决ABA问题也很简单，采取类似数据库乐观锁实现的方式，加一个时间戳，通过时间戳或者版本号来判断有没有改变过

三.AQS

AQS是一个抽象类，是构建锁和其他协作类的一个框架，它的核心主要是三个部分，一个是state，这个是int类型，在不同的协作类中有不同的含义，比如在Semaphore中就是许可证的含义，在ReentrantLock中就是锁的状态，第二个就是FIFO队列，这个就是线程阻塞时排队工作，第三个就是获取/释放方法，在不同实现中也是不尽相同的。
如果看源码的话，比如Semaphore或者countdownLatch或者其他工具类，它们的源码中都有一个实现AQS接口的sync的内部类，这个内部类就是实现各自工具类中的一些各自的特性，如果点进AQS源码看，有一些是被fianl修饰的，说明不能被修改，而有一些则是可以修改的，各自内部类可以重写这些方法，实现自己的逻辑。
AQS有两种模式，看源码就会发现，有的方法后面会跟着share的字眼，所以就分为了独占模式和共享模式。