Java中的CAS

在JDK 1.5之前Java语言是靠synchronized关键字保证同步，这会导致有锁

锁机制存在以下问题：

• 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。

• 一个线程持有锁会导致其它所有需要此锁的线程挂起。

• 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

synchronized就是一种独占锁，独占锁是一种悲观锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。 而另一个更加有效的锁就是乐观锁，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。 乐观锁用到的机制就是CAS

CAS概念与原理

全称Compare And Swap（比较与交换），解决多线程并行情况下使用锁造成性能损耗的一种机制，借助CPU的cmpxchg指令， 通过JNI调用实现，是Java并发包的基础

实现思想 CAS（V, A, B），V为内存地址、A为预期原值，B为新值。如果内存地址的值与预期原值相匹配，那么将该位置值更新为新值。 否则，说明已经被其他线程更新，处理器不做任何操作；无论哪种情况，它都会在 CAS 指令之前返回该位置的值。而我们可以使用自旋锁， 循环CAS，重新读取该变量再尝试再次修改该变量，也可以放弃操作

CAS的缺点

• ABA问题：因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B， 又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了，解决思路就是使用版本号，在变量前面追加上版本号， 每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A

• 循环时间长开销大：自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销，如果JVM能支持处理器提供的pause指令那么效率会有一定的提升， pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本， 在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush）， 从而提高CPU的执行效率

• 只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时， 循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者把多个共享变量合并成一个共享变量来操作，比如有两个共享变量i ＝ 2,j = a， 合并一下ij = 2a，然后用CAS来操作ij。从JDK1.5开始提供了AtomicReference类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作。

Concurrent包的实现

java.util.concurrent包里面的工具类基本全部都是使用了CAS+volatile的乐观锁机制，常用的ReentrantReadWriteLock类，实际上内部也是使用了CAS+volatile的机制， 并且ReentrantReadWriteLock类能支持在获取锁的时候响应线程的中断，能够设置等待锁的超时时间，还有tryLock等方法， 所以在要使用需要耗费长时间同步锁的情况下，使用ReentrantReadWriteLock类会比synchronized更具有可操作性和更好的性能

ReentrantReadWriteLock会先去获取锁的count，然后在小于MAX_COUNT锁数目的时候，再去用cas设置锁的状态，然后再去获取锁。