CAS也是锁

CAS（CompareAndSwap）顾名思义比较再交换。先比较，发现与预期一致，说明没有其他线程改动过，于是就交换；如果不一致说明改动过，就再来一次，如此往复。

int prev, next;
do {
    prev = get();
    next = accumulatorFunction.applyAsInt(prev, x);
} while (!compareAndSet(prev, next));
return next;

这是一种自旋的方式保证线程安全，可是compareAndSet这个比较再交换是原子的吗？先比较发现与预期一致了，准备交换的时候另一个线程来改了怎么办？
点进去看源码：

public final boolean compareAndSet(int expect, int update) {
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

这个unsafe的方法都是native方法，

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

只能打开openJDK看源码了

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

核心方法是cmpxchg方法

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  // alternative for InterlockedCompareExchange
  int mp = os::is_MP();
  __asm {
    mov edx, dest
    mov ecx, exchange_value
    mov eax, compare_value
    LOCK_IF_MP(mp)
    cmpxchg dword ptr [edx], ecx
  }
}

原来LOCK_IF_MP这里加了锁，才保证了原子性。所谓“无锁”是在Java层面上没有锁，但其实在操作系统的CPU指令层面是加了锁的。这个锁比java上的锁性能好很多。