关于后端:Java-CAS-原理剖析

4次阅读

共计 4451 个字符，预计需要花费 12 分钟才能阅读完成。

在 Java 并发中，咱们最后接触的应该就是 synchronized 关键字了，然而 synchronized 属于重量级锁，很多时候会引起性能问题，volatile 也是个不错的抉择，然而 volatile 不能保障原子性，只能在某些场合下应用。
像 synchronized 这种独占锁属于乐观锁，它是在假如肯定会发生冲突的，那么加锁恰好有用，除此之外，还有乐观锁，乐观锁的含意就是假如没有发生冲突，那么我正好能够进行某项操作，如果要是发生冲突呢，那我就重试直到胜利，乐观锁最常见的就是 CAS。
咱们在读 Concurrent 包下的类的源码时，发现无论是 ReenterLock 外部的 AQS，还是各种 Atomic 结尾的原子类，外部都利用到了 CAS，最常见的就是咱们在并发编程时遇到的 i ++ 这种状况。传统的办法必定是在办法上加上 synchronized 关键字:
public class Test {

public volatile int i;

public synchronized void add() {i++;}

}
复制代码然而这种办法在性能上可能会差一点，咱们还能够应用 AtomicInteger，就能够保障 i 原子的 ++ 了。
public class Test {

public AtomicInteger i;

public void add() {i.getAndIncrement();
}

}
复制代码咱们来看 getAndIncrement 的外部：
public final int getAndIncrement() {

return unsafe.getAndAddInt(this, valueOffset, 1);

}
复制代码再深刻到 getAndAddInt():
public final int getAndAddInt(Object var1, long var2, int var4) {

int var5;
do {var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

return var5;

}
复制代码这里咱们见到 compareAndSwapInt 这个函数，它也是 CAS 缩写的由来。那么仔细分析下这个函数做了什么呢？
首先咱们发现 compareAndSwapInt 后面的 this，那么它属于哪个类呢，咱们看上一步 getAndAddInt，后面是 unsafe。这里咱们进入的 Unsafe 类。这里要对 Unsafe 类做个阐明。联合 AtomicInteger 的定义来说：
public class AtomicInteger extends Number implements java.io.Serializable {

private static final long serialVersionUID = 6214790243416807050L;

// setup to use Unsafe.compareAndSwapInt for updates
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;
...

复制代码在 AtomicInteger 数据定义的局部，咱们能够看到，其实理论存储的值是放在 value 中的，除此之外咱们还获取了 unsafe 实例，并且定义了 valueOffset。再看到 static 块，懂类加载过程的都晓得，static 块的加载产生于类加载的时候，是最先初始化的，这时候咱们调用 unsafe 的 objectFieldOffset 从 Atomic 类文件中获取 value 的偏移量，那么 valueOffset 其实就是记录 value 的偏移量的。
再回到下面一个函数 getAndAddInt，咱们看 var5 获取的是什么，通过调用 unsafe 的 getIntVolatile(var1, var2)，这是个 native 办法，具体实现到 JDK 源码里去看了，其实就是获取 var1 中，var2 偏移量处的值。var1 就是 AtomicInteger，var2 就是咱们后面提到的 valueOffset, 这样咱们就从内存里获取到当初 valueOffset 处的值了。
当初重点来了，compareAndSwapInt（var1, var2, var5, var5 + var4）其实换成 compareAndSwapInt（obj, offset, expect, update）比较清楚，意思就是如果 obj 内的 value 和 expect 相等，就证实没有其余线程扭转过这个变量，那么就更新它为 update，如果这一步的 CAS 没有胜利，那就采纳自旋的形式持续进行 CAS 操作，取出乍一看这也是两个步骤了啊，其实在 JNI 里是借助于一个 CPU 指令实现的。所以还是原子操作。
CAS 底层原理
CAS 底层应用 JNI 调用 C 代码实现的，如果你有 Hotspot 源码，那么在 Unsafe.cpp 里能够找到它的实现：
static JNINativeMethod methods_15[] = {

// 省略一堆代码...
{CC"compareAndSwapInt",  CC"("OBJ"J""I""I"")Z",      FN_PTR(Unsafe_CompareAndSwapInt)},
{CC"compareAndSwapLong", CC"("OBJ"J""J""J"")Z",      FN_PTR(Unsafe_CompareAndSwapLong)},
// 省略一堆代码...

};
复制代码咱们能够看到 compareAndSwapInt 实现是在 Unsafe_CompareAndSwapInt 外面，再深刻到 Unsafe_CompareAndSwapInt:
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
UnsafeWrapper(“Unsafe_CompareAndSwapInt”);
oop p = JNIHandles::resolve(obj);
jint addr = (jint ) index_oop_from_field_offset_long(p, offset);
return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END
复制代码 p 是取出的对象，addr 是 p 中 offset 处的地址，最初调用了 Atomic::cmpxchg(x, addr, e), 其中参数 x 是行将更新的值，参数 e 是原内存的值。代码中能看到 cmpxchg 有基于各个平台的实现，这里我抉择 Linux X86 平台下的源码剖析：
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
int mp = os::is_MP();
asm volatile (LOCK_IF_MP(%4) “cmpxchgl %1,(%3)”

                : "=a" (exchange_value)
                : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                : "cc", "memory");

return exchange_value;
}
复制代码这是一段小汇编，__asm__阐明是 ASM 汇编，__volatile__禁止编译器优化
// Adding a lock prefix to an instruction on MP machine

复制代码 os::is_MP 判断以后零碎是否为多核零碎，如果是就给总线加锁，所以同一芯片上的其余处理器就临时不能通过总线拜访内存，保障了该指令在多处理器环境下的原子性。
在正式解读这段汇编前，咱们来理解下嵌入汇编的根本格局：
asm (assembler template

: output operands                  /* optional */
: input operands                   /* optional */
: list of clobbered registers      /* optional */
);

复制代码

template 就是 cmpxchgl %1,(%3) 示意汇编模板

output operands 示意输入操作数,= a 对应 eax 寄存器

input operand 示意输出参数，%1 就是 exchange_value, %3 是 dest, %4 就是 mp，r 示意任意寄存器，a 还是 eax 寄存器

list of clobbered registers 就是些额定参数，cc 示意编译器 cmpxchgl 的执行将影响到标记寄存器, memory 通知编译器要从新从内存中读取变量的最新值，这点实现了 volatile 的感觉。

那么表达式其实就是 cmpxchgl exchange_value ,dest，咱们会发现 %2 也就是 compare_value 没有用上，这里就要剖析 cmpxchgl 的语义了。cmpxchgl 开端 l 示意操作数长度为 4，下面曾经晓得了。cmpxchgl 会默认比拟 eax 寄存器的值即 compare_value 和 exchange_value 的值，如果相等，就把 dest 的值赋值给 exchange_value, 否则，将 exchange_value 赋值给 eax。具体汇编指令能够查看 Intel 手册 CMPXCHG
最终，JDK 通过 CPU 的 cmpxchgl 指令的反对，实现 AtomicInteger 的 CAS 操作的原子性。
CAS 的问题

ABA 问题

CAS 须要在操作值的时候查看下值有没有发生变化，如果没有发生变化则更新，然而如果一个值原来是 A，变成了 B，又变成了 A，那么应用 CAS 进行查看时会发现它的值没有发生变化，然而实际上却变动了。这就是 CAS 的 ABA 问题。
常见的解决思路是应用版本号。在变量后面追加上版本号，每次变量更新的时候把版本号加一，那么 A -B-A 就会变成 1A-2B-3A。
目前在 JDK 的 atomic 包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。这个类的 compareAndSet 办法作用是首先查看以后援用是否等于预期援用，并且以后标记是否等于预期标记，如果全副相等，则以原子形式将该援用和该标记的值设置为给定的更新值。

循环工夫长开销大

下面咱们说过如果 CAS 不胜利，则会原地自旋，如果长时间自旋会给 CPU 带来十分大的执行开销。

正文完