一、什么是CAS机制？

           Synchronized保证了【线程安全】，但是在某些情况下，却不是一个最优选择。关键在于【性能】问题。

               1. Synchronized关键字会让没有得到【锁资源】的线程进入Blocked状态，而后在争夺到【锁资源】后恢复为Runnable状态，这个过程中涉及到操作                       系统【用户模式】和【内核模式】的切换，代价比较高。

               2. 尽管java1.6为Synchronized做了优化，增加了从【偏向锁】到【轻量级锁】再到【重量级锁】的过度，但是在最终转变为重量级锁之后，性能任然                    较低。

二、Java中的【原子操作类】

         所谓的原子操作类，指的是java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。

         例如：

           AtomicBoolean，AtomicInteger，AtomicLong。
          它们分别用于Boolean，Integer，Long类型的原子性操作。

        现在我们尝试在代码中引入AtomicInteger类：

       在某些情况下，代码的性能会比Synchronized更好。

三、Atomic操作类的底层，正是利用了【CAS机制】

           那么问题来了，到底什么是CAS？

           CAS是英文单词Compare And Swap的缩写，就是【比较并替换】

           CAS机制当中使用了3个【基本操作数】：

               ①. 内存地址V

               ②. 旧的预期值A

               ③. 要修改的新值B

    CAS工作原理：

     【更新】一个【变量】时，只有当变量的【预期值A】和【内存地址V】当中的实际值【相同】时，才会将【内存地址V】对应的值修改为【要修改的新          值B】

   举个例子：

      1. 在内存地址V当中，存储着值为10的变量。

     2. 此时线程1想要把变量的值增加1。对线程1来说，旧的预期值A=10，要修改的新值B=11。

    3. 在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。

    4. 线程1开始提交更新，首先进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败。

     5. 线程1重新获取内存地址V的当前值，并重新计算想要修改的新值。
          此时对线程1来说，A=11，B=12。
          这个重新尝试的过程被称为自旋。

   6. 这一次比较幸运，没有其他线程改变地址V的值。
       线程1进行Compare，发现A和地址V的实际值是相等的。 

  7.  线程1进行Swap，把地址V的值替换为B，也就是12。

四、CAS与Sychronized比较

     从思想上来说：

       ①. Synchronized属于【悲观锁】

                悲观锁认为：程序中的【并发】情况严重，所以【严防死守】

       ②. CAS属于【乐观锁】

                乐观锁认为：程序中的【并发】情况不那么严重，所以让【线程不断去尝试更新】

      这2种机制没有绝对的好与坏，关键看使用场景。

      在【并发量】非常高的情况下，反而用【同步锁】更合适一些。

五、Java中都有哪些地方应用到了CAS机制呢?

       1、Atomic系列类

       2、Lock系列类底层实现

       3、Java1.6以上版本，Synchronized转变为【重量级锁】之前，也会采用CAS机制

六、 CAS机制存在缺点：

       1、CPU开销较大

              在【并发量】比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

       2、不能保证代码块的原子性

              CAS机制所保证的只是【一个变量】的【原子操作】，而不能保证整个代码块的原子性。

              比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

       3、ABA问题

             这是CAS机制最大的问题所在