CAS(Compare and Swap) 是利用底层硬件平台特性，实现原子性操作的算法，Java 1.5 以后 JUC(java.util.concurrent) 实现主要以此为基础；找了不少资料以下记录一下个人对于 CAS 的理解(部分资料 copy 的)

一、CAS 简述

从最基础的 Java 中的 i++ 操作来说，i++ 并非原子操作，实质上相当于先读取 i 值，然后在内存中创建缓存变量保存 ++ 后结果，最后写会变量 i；而在这期间 i 变量都可能被其他线程读或写，从而造成线程安全性问题

CAS 算法大致原理是：在对变量进行计算之前(如 ++ 操作)，首先读取原变量值，称为 旧的预期值 A，然后在更新之前再获取当前内存中的值，称为 当前内存值 V，如果 A==V 则说明变量从未被其他线程修改过，此时将会写入新值 B，如果 A!=V 则说明变量已经被其他线程修改过，当前线程应当什么也不做；

二、 CAS 原理

2.1、openjdk 中 CAS 实现

翻了一下 AtomicInteger 的源码，发现其实质上都会调用到 Unsafe 类中的方法，而 Unsafe 中大部分方法是 native 的，也就是说实质使用 JNI 上调用了 C 来沟通底层硬件完成 CAS；具体调用源码(openjdk)为 unsafe.cpp、atomic.cpp、atomicwindowsx86.inline.hpp；以下是一部分代码片段(不懂 C…)

 1// Adding a lock prefix to an instruction on MP machine
 2// VC++ doesn't like the lock prefix to be on a single line
 3// so we can't insert a label after the lock prefix.
 4// By emitting a lock prefix, we can define a label after it.
 5#define LOCK_IF_MP(mp) __asm cmp mp, 0  \
 6                       __asm je L0      \
 7                       __asm _emit 0xF0 \
 8                       __asm L0:
 9
10inline jlong    Atomic::cmpxchg    (jlong    exchange_value, volatile jlong*    dest, jlong    compare_value) {
11  return (*os::atomic_cmpxchg_long_func)(exchange_value, dest, compare_value);
12}

下面开始抄的 （：…. 看 C 完全懵逼

如上面源代码所示，程序会根据当前处理器的类型来决定是否为 cmpxchg 指令添加lock前缀；如果程序跑在多核处理器上，就为 cmpxchg 指令加上 lock 前缀 (lock cmpxchg)；反之，如果程序跑在单核处理器上，就省略 lock 前缀 (单处理器自身会维护单处理器内的顺序一致性，不需要 lock 前缀提供的内存屏障效果)

2.2、intel lock 前缀说明

intel 的手册对lock前缀的说明如下:

  • 确保对内存的读-改-写操作原子执行。在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
  • 禁止该指令与之前和之后的读和写指令重排序。
  • 把写缓冲区中的所有数据刷新到内存中

2.3、cpu 锁

关于CPU的锁有如下3种:

  • 处理器自动保证基本内存操作的原子性

首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的，但是复杂的内存操作处理器不能自动保证其原子性，比如跨总线宽度，跨多个缓存行，跨页表的访问。但是处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。

  • 使用总线锁保证原子性

第一个机制是通过总线锁保证原子性。如果多个处理器同时对共享变量进行读改写（i++就是经典的读改写操作）操作，那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致，举个例子：如果i=1,我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2；

原因是有可能多个处理器同时从各自的缓存中读取变量i，分别进行加一操作，然后分别写入系统内存当中。那么想要保证读改写共享变量的操作是原子的，就必须保证CPU1读改写共享变量的时候，CPU2不能操作缓存了该共享变量内存地址的缓存。

处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住,那么该处理器可以独占使用共享内存。

  • 使用缓存锁保证原子性

第二个机制是通过缓存锁定保证原子性。在同一时刻我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把CPU和内存之间通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。

频繁使用的内存会缓存在处理器的L1，L2和L3高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，在奔腾6和最近的处理器中可以使用“缓存锁定”的方式来实现复杂的原子性。所谓“缓存锁定”就是如果缓存在处理器缓存行中内存区域在LOCK操作期间被锁定，当它执行锁操作回写内存时，处理器不在总线上声言LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时会起缓存行无效，在例1中，当CPU1修改缓存行中的i时使用缓存锁定，那么CPU2就不能同时缓存了i的缓存行。

但是有两种情况下处理器不会使用缓存锁定。第一种情况是：当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line），则处理器会调用总线锁定。第二种情况是：有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。

以上两个机制我们可以通过Inter处理器提供了很多LOCK前缀的指令来实现。比如位测试和修改指令BTS，BTR，BTC，交换指令XADD，CMPXCHG和其他一些操作数和逻辑指令，比如ADD（加），OR（或）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。

三、CAS 缺点

3.1、ABA 问题

由于 CAS 设计机制就是获取某两个时刻(初始预期值和当前内存值)变量值，并进行比较更新，所以说如果在获取初始预期值和当前内存值这段时间间隔内，变量值由 A 变为 B 再变为 A，那么对于 CAS 来说是不可感知的，但实际上变量已经发生了变化；解决办法是在每次获取时加版本号，并且每次更新对版本号 +1，这样当发生 ABA 问题时通过版本号可以得知变量被改动过

JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是 首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

3.2、循环时间长开销大

所谓循环时间长开销大问题就是当 CAS 判定变量被修改了以后则放弃本次修改，但往往为了保证数据正确性该计算会以循环的方式再次发起 CAS，如果多次 CAS 判定失败，则会产生大量的时间消耗和性能浪费；如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

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

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效；从 JDK 1.5开始提供了 AtomicReference 类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作

四、JUC 实现

由于 Java 的 CAS 同时具有 volatile 读和volatile写的内存语义，因此 Java 线程之间的通信现在有了下面四种方式：

  • A线程写 volatile 变量，随后B线程读这个 volatile 变量
  • A线程写 volatile 变量，随后B线程用 CAS 更新这个 volatile 变量
  • A线程用 CAS 更新一个 volatile 变量，随后B线程用 CAS 更新这个 volatile 变量
  • A线程用 CAS 更新一个 volatile 变量，随后B线程读这个 volatile 变量

Java 的 CAS 会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile 变量的读/写和 CAS 可以实现线程之间的通信。把这些特性整合在一起，就形成了整个 concurrent 包得以实现的基石。如果我们仔细分析 concurrent 包的源代码实现，会发现一个通用化的实现模式：

  • 首先，声明共享变量为 volatile；
  • 然后，使用 CAS 的原子条件更新来实现线程之间的同步；
  • 同时，配合以 volatile 的读/写和 CAS 所具有的 volatile 读和写的内存语义来实现线程之间的通信。

AQS，非阻塞数据结构和原子变量类 ( java.util.concurrent.atomic 包中的类)，这些 concurrent 包中的基础类都是使用这种模式来实现的，而 concurrent 包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent 包的实现示意图如下：

concurrent

五、JDK9 改变

随着 JDK9 即将发布，CAS 相关主要类 Unsafe 有些变动，以下变动主要由 Mikael Vidstedt 提交，更新内容如下

  • 避免代码重复，sun.misc.Unsafe 将全部实现委托给 jdk.internal.misc.Unsafe，这意味着java虚拟机(特别是 unsafe.cpp ）不再需要关心s.m.Unsafe的实现。
  • s.m.Unsafe 的委托方法通常会被内联，但是为了避免性能下降的风险，仍然添加了 @ForceInline 注解
  • 更新文档，指明用户应该确保Unsafe类的参数正确
  • 参数检查从Unsage.cpp移入java，简化本地代码以及允许JIT进一步优化
  • 放松了特定参数的检查，比方说最近引入的 U.copySwapMemory 没有检查空指针。具体原因可以参考 j.i.m.U.checkPointer 的文档。除了 U.copySwapMemory，现在Unsafe类方法也都没有对参数执行NULL检查
  • 在 U.copySwapMemory 类的基础上，对 j.i.m.U.copyMemory 增加了一个测试案例。请随时提醒我合并过来（本该如此）

在 Mikael Vidstedt 看来，Usage 类的清理算是 “相当激进” 了，值得注意的地方有：

  • Unsafe_方法以及 unsafe.cpp 中的其他本地方法被申明为静态方法
  • 新增 unsafe.hpp 代码文件，文件中移入VM其他组件的一些方法。移除部分 extern 函数声明（不要过度使用extern）
  • 对于不怎么用到的UNSAFE_LEAF，移除警告性质的注释（没有必要，只是个VM_LEAF）
  • 一些简单的leaf方法使用UNSAFE_LEAF
  • UNSAFE_ENTRY/UNSAFE_END代码块新增大括号，帮助自动缩进
  • 移除未使用的Unsafe_<…>##140形式的函数和宏
  • 更新宏参数，与unsafe.cpp的宏定义保持一致
  • 更换带断言的参数检查，正如前面提及，这些检查移入了 j.i.m.Unsafe，移除所有 s.m.Unsafe 相关的代码

本文参考自 JAVA CAS原理深度分析、Java 9发布在即，Oracle OpenJDK着手优化Unsafe类

转载请注明出处，本文采用 CC4.0 协议授权