cas机制

cas是一种乐观策略，他基于比较-替换的思路。现在的cpu大多数支持cas操作。
java并发包中有些类直接用到了cas机制

比如AtomicInteger类

    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;

unsafe类支持直接对硬件进行操作。也就是直接访问内存地址。java本身是不能直接访问硬件的。所有的对硬件的访问都封装成了native方法。但是这里的valueOffset变量确实获得了value值的内存地址，说明java这里在应用层面访问了硬件。这中操作在java应用中是不多见的。所以这个类名为Unsafe。这个类只有bootstrap加载的类可以用。

   public final int addAndGet ( int delta){
            for (; ; ) {
                int current = get();
                int next = current + delta;
                if (compareAndSet(current, next))
                    return next;
            }
        }

以上是jdk1.7的代码，jdk1.8的实现变了不少，将大部分工作交给Unsafe类干了。从代码可以看出，current为预期值，只有current与真实值一样时，才会返回true。

cas的不足之处：
假设有这样一种情况，A线程预期值是a，此时线程切换为B，B线程将其改为了b，并执行完毕，此时线程又切换为C，C线程线程又把其改为a，并执行完毕。此时线程切换会A，A执行cas操作，发现满足cas条件，于是修改了变量的值。
以上情况就是所谓的cas中的ABA问题。从A变为B，又从B变为A。不能简单的认为这个值没有发生变化。但是对于AtomicInteger类来说，认为没有发生变化，对结果其实是没有影响的。

java中为了避免ABA问题产生的干扰，有了AtomicStampedReference。即带有时间戳的对象引用。cas的缺点是丢失了变化过程，只看结果。AtomicStampedReference内部维护了一个时间戳（实际上他可以用任意一个整数来表示）。当value被更改时，还必须把时间戳给改了。当value值跟时间戳都满足预期值时，才被看作满足cas条件。