CAS与Java中的乐观锁的应用方法

什么是CAS

CAS是CompareAndSwap，即比较和交换。为什么CAS没有用到锁还能保证并发情况下安全的操作数据呢，名字其实非常直观的表明了CAS的原理，具体修改数据过程如下：

1. 用CAS操作数据时，将数据原始值和要修改的值一并传递给方法

2. 比较当前目标变量值与传进去的原始值是否相同

3. 如果相同，表示目标变量没有被其他线程修改，直接修改目标变量值即可

4. 如果目标变量值与原始值不同，那么证明目标变量已经被其他线程修改过，本次CAS修改失败

从上述过程可以看到CAS其实保证的是安全的修改数据，但是修改存在失败的可能性，即目标变量数据修改不成功，这个时候我们要循环判断CAS修改数据结果，如果失败进行重试。

思维比较缜密的同学可能担心CAS本身这个比较与替换的操作产生并发安全问题，实际应用中这种情况不会发生，比较与替换由JDK借助硬件级别的CAS原语来保证比较替换是一个原子性动作。

CAS实现无锁编程

无锁编程指的是在不使用锁的情况下保证安全的操作共享变量在并发编程中，我们用各种锁来保证共享变量的安全性。即在保证一个线程未操作完共享变量的时候其他线程不能操作同一共享变量。
正确的使用锁可以保证并发情况下数据安全，但是在并发程度不高，竞争不激烈的时候，获取锁和释放锁就成了没必要的性能浪费。这种情况下可以可考虑利用CAS保证数据安全，实现无锁编程 

头疼的ABA问题

上面我们已经了解了CAS保证安全操作共享变量的原理，但是上述CAS操作还存在缺陷。假设当前线程访问的共享变量值为A，在线程1访问共享变量过程中，线程2操作共享变量将其赋值为B，线程2处理完自己的逻辑后又将共享变量赋值为A。这时线程1比较共享变量值A与原始值A相同，误以为没有其他线程操作共享变量，直接返回操作成功。这就是ABA问题。虽然大部分业务不需要关心共享变量是否有过其他更改，只要原始值与当前值一致就能得到正确的结果，但是有一些敏感场景不光要考虑共享变量结果上等同于没有被修改过，同时也不能接受共享变量过程上被其他线程修改过。幸运的是ABA问题也有成熟的解决方案，我们为共享变量添加一个版本号，每当共享变量被修改这个版本号值就会自增。在CAS操作中我们比较的不是原始变量值，而是共享变量的版本号。每次操作共享变量更新的版本号都是唯一的，所以能够避免ABA问题。 

具体应用场景 

JDK中的CAS应用

首先多个线程对普通变量进行并发操作是不安全的，一个线程的操作结果可能被其他线程覆盖掉，比如现在我们用两个线程，每个线程将初始值为1的共享变量增加一，如果没有同步机制的话共享变量结果很可能小于3。即可能线程1和线程2都读到了初始值1，线程1将其赋值为2，线程2所在内存读取到的值还是1不会变，线程2也将变量增加1然后赋值成2，这样最终结果是2小于预期结果3。自增操作不是原子性操作导致了这个共享变量操作不安全问题。为了解决这个问题，JDK提供了一系列原子类提供相应的原子操作。下面是AtomicInteger中的getAndIncrement方法源码，让我们从源码来看是怎么利用CAS实现线程安全的原子性的整形变量相加操作。

/**
 * 原子性的将当前值增加1
 *
 * @return 返回自增前的值
 */
public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

可以看到getAndIncrement实际调用了UnSafe类的getAndAddInt方法实现原子操作，下面是getAndAddInt源代码

/**
 * 原子的将给定值与目标字变量相加并重新赋值给目标变量
 *
 * @param o 要更新的变量所在的对象
 * @param offset 变量字段的内存偏移值
 * @param delta 要增加的数字值
 * @return 更改前的原始值
 * @since 1.8
 */
public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
    	// 获取当前目标目标变量值
        v = getIntVolatile(o, offset);
    // 这句代码是关键, 自旋保证相加操作一定成功
    // 如果不成功继续运行上一句代码, 获取被其他
    // 线程抢先修改的变量值, 在新值基础上尝试相加
    // 操作, 保证了相加操作的原子性
    } while (!compareAndSwapInt(o, offset, v, v + delta));
    return v;
}

我们都对锁很熟悉, 比如可重入锁ReentrantLock, JDK提供的各种锁基本都依赖AbstractQueuedSynchronizer这个类, 当多个线程尝试获取锁时会进入一个队列等待, 其中多线程入队操作的原子性就是用CAS来保证的. 源代码如下:

/**
 * 锁底层等待获取锁的线程入队操作
 * @param node 要入队的线程节点
 * @return 入队节点的前驱节点
 */
private Node enq(final Node node) {
// 自旋等待节点入队, 通过cas保证并发情况下node安全正确入队
    for (;;) {
        Node t = tail;
        // head为空时构造dummy node初始化head和tail
        if (t == null) {
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            // 如果cas设置tail失败了
            // 下个循环取到了最新的其他线程抢先设置的tail
            // 继续尝试设置.
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}
/**
 * 原子性的设置tail尾节点为新入队的节点
 */
private final boolean compareAndSetTail(Node expect, Node update) {
// 可以看到此处又是调用了Unsafe类下的原子操作方法
// 如果目标字段(tail尾节点字段)当前值是预期值
// 即没有被其他线程抢先修改成功, 那么就设置成功
// 返回true
    return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
}  
  

企业开发中的乐观锁应用

除了JDK中Uusafe类提供的各种原子性操作外，我们实际开发中可以用CAS思想保证并发情况下安全的操作数据库。假设有user表结构以及数据如下， version字段是实现乐观锁的关键

假设我们有一个用户领取优惠券的按钮，怎么防止用户快速点击按钮造成重复领取优惠券的情况呢。我们要安全的更改id为1的用户的coupon_num优惠券数量，将version字段作为CAS比较的版本号，即可避免重复增加优惠券数量，比较和替换这个逻辑通过WHERE条件来实现. 涉及sql如下：

UPDATE user 
SET coupon_num = coupon_num + 1, version = version + 1 
WHERE version = 0

可以看到，我们查询出id为1的数据， 版本号为0，修改数据的同时把当前版本号当做条件即可实现安全修改，如果修改失败，证明已经被其他线程修改过，然后看具体业务决定是否需要自旋尝试再次修改。这里要注意考虑竞争激烈的情况下多个线程自旋导致过度的性能消耗，根据并发量选择适合自己业务的方式