CAS无锁策略

　　并发编程时，对于共享资源的使用需要确保绝对的安全性。除了利用锁机制之外，还有一种无锁的概念。所谓无锁，就是假定在并发情况下，对于共享资源的访问没有冲突，线程可以一直不停的运行，无需阻塞，如果产生冲突，则使用CAS算法确保安全性。Java在很多并发代码中都使用了这种算法。

　　CAS算法的核心参数如下：

compareAndSet(V,E,A)

　　V代码需要进行更新的变量；E代表预期值；A代表所要更新的值。

　　CAS的核心思想就是：当要对一个变量进行更新时，先取出该变量此时在内存中的实际值，与预期值进行比较。如果相等，则代表没有其他线程对其进行过修改，直接更新。如果不同，表示有其他线程修改过，此时有两种策略。一种是让CAS自旋，直到更新成功；另外表示当前线程更新失败，继续后续逻辑。大概示意图如下：

　　对于CAS自旋，有可能会出现长时间更新失败，浪费CPU性能的情况。JDK1.6以后，加入了适应性自旋的概念。即如果某个锁自旋时很少获得成功，那么会减少自旋次数。自旋次数的默认值是10次，可以使用参数-XX:PreBlockSpin来更改。

　　再说一下为什么CAS在更新变量值的时候不会受到其他线程的影响呢？会不会我在判断更新值与预期值相等，进行更新的过程中，变量被其他线程更新了呢？其实不会，因为CAS具有排它性，一次CAS是一个原子操作，是CPU源语级别。确保隔离性。

　　Java对于CAS是使用Unsafe类进行支持的。顾名思义，不安全，可以让程序员像C语言那样直接操纵内存指针。java.util.concurrent.atomic包下的类，都是使用CAS实现的。

ABA缺陷

　　不知道大家通过上面对CAS的介绍说明，看到了CAS算法的缺陷没有！

　　CAS本身会有ABA问题。举个例子，变量m = 10，我要把m更新为30。在我判断之前，有其他线程先把m更新到50，在从50更新到10。那么我进行 10 == 10的判断时，这时候我怎么确定m的值有没有被改过呢？这就是ABA问题了。

　　要解决这个问题，我们就需要在进行 10 == 10判断的时候，还需要有其他参照。Java中有一个类AtomicStampedReference，这个类除了维护变量值之外，还会维护一个时间戳。用于确定数值版本。

private static class Pair<T> {
        final T reference;
        final int stamp;
        private Pair(T reference, int stamp) {
            this.reference = reference;
            this.stamp = stamp;
        }
        static <T> Pair<T> of(T reference, int stamp) {
            return new Pair<T>(reference, stamp);
        }
    }

    private volatile Pair<V> pair;

　　用volatile关键字修饰的内部类。

　　

　　看一下核心的compareAndSet()方法：

public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        Pair<V> current = pair;
        return
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }

　　可以看到除了比较数值之外，还会比较时间戳。