【Java笔记】CAS比较的是什么+交换的是什么+自旋到啥时候

之前看CAS一致迷迷糊糊的，知道它通过自旋来避免多线程冲突，然后通过不断比较交换来不停自旋。
但一直有个疑问，一开始比较时Value跟Expect不一样，自旋几次就一样了吗？难道是Value刚开始不一样，后来又变得跟原来一样？这不就变成ABA问题了。
五一没啥事，稍微来理一下。

什么是CAS

CAS（Compare And Swap ）是乐观锁的一种实现方式，是一种轻量级锁，其实就是无锁实现，在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。

CAS原理

CAS工作时涉及三个值：

• 需要读写的内存值 V (Value)
• 进行比较的值 E (Expect)
• 要写入的新值 N (New)

假设一个线程要操作一个变量，而这个变量在主内存（JMM中的抽象说法，大概就是线程间共享的区域，用jvm运行时数据区来说就是堆区、方法区一类的）中的位置为V，一般需要：

1. 先将V的值读进该线程的本地内存中（JMM中线程私有的内存区域，比如栈），记为 E
2. 该线程在本地内存中对 E 的值进行运算，并将运算结果存在本地内存N中
3. 将N的值写回原来主内存V中【此时如果有另一个线程在操作V就会出现线程竞争】

然后我们梳理下CAS避免线程竞争的流程：

• 1，2两步都没什么问题，正常读进本地内存然后运算
• 重点在第3步中，将N写回V前，会对比V的值（主内存中的当前值）与E 的值（本线程进程操作时V的值），即CAS的C，Compare
  • 如果一致，则说明之前没有其他线程更改过V，成功写回；
  • 如果不一致，说明有其他线程在使用V，在把现在V的值读到线程本地内存中作为E，重新运算得到N，然后写回前比较V跟E的值…

就这样，E与V的值不同–重新读E的新值到V–重新运算得到N–重新比较-E与V的值不同–…这样一致循环“比较+交换”的过程，就是自旋。也就回答了刚开始的问题，咱一开始没搞清楚的时候觉得E是固定的，那不是一直死循环？脑子确实不灵光，现在明白了。
Java中实现CAS主要是通过Unsafe类（Atomic系类的类底层调用的是Unsafe类的API），其中包含了很多public natice的方法，有关CAS的主要就是：

boolean compareAndSwapObject(Object o, long offset,Object expected, Object x);
boolean compareAndSwapInt(Object o, long offset,int expected,int x);
boolean compareAndSwapLong(Object o, long offset,long expected,long x);

其中，offset就是目标变量在类对象中的内存偏移值

CAS的原子性

CAS本身就是一个原子操作，也就是说，比较（Compare）跟交换（Swap）是不能被打断的。
当多个线程同时使用CAS操作一个变量时，只有一个会胜出，并成功更新，其他的线程不会被挂起阻塞，而是一直自旋，直到成功。
Java中的原子操作主要就是通过AtomicInteger类实现的，

CAS的三个问题

老生常谈了，稍微过一下

问题一：ABA

简单来说就是主内存V的值原来是A，读进【线程1】的本地内存的E的值也是A，但是另一个【线程2】先把A更新成B，再把B更新成A，这时候在【线程1】CAS比较时会觉得V没被更改过就擅自更新了，实际上【线程2】更改过了。

解决方法

在变量前面追加上版本号或者时间戳。
从JDK 1.5开始，JDK的atomic包里提供了AtomicStampedReference类来解决ABA问题，其中compareAndSet会检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果二者都相等，才使用CAS设置为新的值和标志。

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)));
}

问题二：CPU开销过大

CAS虽然不像悲观锁一样会有加锁、释放、挂起、阻塞等上下文切换开销，但代价就是会一直占用CPU资源的。
在很多线程都并发竞争的场景下，大量线程都在长时间自旋，那CPU就寄了。

因此可以看出，如果线程之间竞争程度小，使用CAS是一个很好的选择；但是如果竞争很大，使用锁可能是个更好的选择。

解决方法

主要思想就是控制自旋频率或者次数，比如：

• 自旋到一定次数不能成功，就停止
• 让JVM支持处理器提供的pause指令，也就是让自旋失败时cpu睡眠一小段时间再继续自旋
• 自适应自旋锁：自旋次数不固定。简单来说，对于一个锁资源，如果大部分情况下都不能被成功获得，说明竞争比较激烈，就会减少下一次的自旋次数；如果大部分情况下都能成功获得，就增加自旋次数。

问题三：不能保证代码块的原子性

CAS只能保证一个共享变量的原子操作

解决方法

• 使用其他锁，比如Lock，synchronized。锁内的临界区代码可以保证只有当前线程能操作。
• 把多个变量放到一个对象里面进行CAS操作，JDK 1.5开始提供了AtomicReference类保证对象之间的原子性

Reference

并发编程的基石——CAS机制
第十章 CAS与原子操作