java的CAS

    cas是compare and swap的缩写，是由操作系统提供的并发操作的原子指令；cas操作包含3个基本值，内存地址，预期值，要更新的值。在更新变量值时，cas会首先将变量内存地址上的原值和预期值相比较，如果相当就将其设置为要更新的值。cas就是乐观锁的一种形式。

    Volatile能保证共享变量的可见性，即线程将共享变量从主内存读取到线程自己的工作内存中修改后，立即同步到主内存中，v并使其他线程工作内存中的该变量失效，在使用的时候在从主内存中从新读取。但是volatile不能保证原子性，因此可以利用cas的特性-可见性可原子性，搭配volatile实现并发环境下对共享变量的乐观锁。Synchronized是一种独占锁，即悲观锁，且Synchronized还涉及到线程的切换等开销，相比cas性能更差些。

    Java的整个J.UC都是建立在cas的基础上的，J.U.C的无阻塞队列都是通过cas实现的。如java.util.concurrent.ConcurrentLinkedQueue。该队列的各共享变量都是volatile的，每一个对共享变量的设置操作都是通过UNSALF.UNSAFE.compareAndSwapObject实现的，并且由于volatile读操作快于cas写，因此该队列允许head和tail节点延后更新。

    但cas也存在一些问题，主要如下三个：

1. ABA问题，即线程T1和T2都读到A值做cas操作，T2将A改为B在改为C，T1cas的时候发现自己读到的值与变量位置上的值一样，将A改为B，实际上A位置的值已发生变化。解决这个问题就是加给变量加版本号，1A1B经过T2cas后变为2A1B，T1去比较时发现版本对不上就不会修改A了。AtomicStampedReference实现了这个机制，exepetcStamp即预期值版本号，newStamp为要更新的值的版本号：                                                                                                                
   
2. 自旋问题，使用cas一般都是在自旋以修改某值，如ConcurrentLinkedQueue的offer()方法中当在尾节点后添加新节点p.casNext(null, newNode)操作时，如果由于并发大，入队操作会一直自旋，会给CPU带来非常大的执行开销。
3. 只能保证一个共享变量的原子操作。AtomicReference实现了对多个变量的cas修改，将变量放入一个对象中，然后调用AtomicReference的API，cas操作多个共享变量的修改。