Java中说的CAS(compare and swap)是个啥
CAS(compare and swap)字面意思是比较和交换，一般还会配合自旋和volatile一起使用，本文讨论CAS，后面文章详细讨论volatile。
为啥需要比较和交换
当我们要操作一个变量的时候，最经典的是自增操作，从1变成2，单线程去操作的时候肯定没问题，但是一旦出现两个线程同时去操作同一个变量的时候，问题就出现了，这与Java的内存模型JMM有关，我放在下一篇文章讨论volatile的时候去讨论，如果线程A已经把变量改为了2，线程B同时去自增操作，没有看到这个变化，还是把变量改为2，两个线程去自增结果应该是3，但结果却是2，这就引入了CAS的方式。也许你觉得加volatile就可以保证修改可见性，但volatile无法保证原子性，下篇文章讨论。
如果使用CAS先比较再交换，就可以解决上面的问题，当线程B去自增的时候，拿着旧的值1和新的值2，要求将变量替换为新值，因为线程A已经修改了变量为2，导致旧值比较的时候不匹配，无法设置，其实就是乐观锁，用经典的原子整型来举例。
乐观锁
顺便提一嘴乐观锁、悲观锁，这个不是具体的一种锁，而是一种思想不仅仅可以用于Java编程，SQL更新的时候也可以用。
乐观锁，比较乐观，认为不一定会发生冲突，所以不排他，允许其他人一起修改，只是在修改前判断一下是否已经被其他人修改过了。
悲观锁，比较悲观，认为一定会发生冲突，所以排他，先上一把锁禁止其他人修改，自己修改完才能释放锁。
原子操作
比较经典的案例是原子整型类AtomicInteger的自增操作getAndIncrement，先看代码：
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
就一行代码，调用了 Unsafe 类，先放一下接着往下看：
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;
}
忘了说valueOffset，这是咋来的呢？valueOffset = unsafe.objectFieldOffset 这样来的，native 方法，不是这篇文件的重点，这个获取对象的内存地址偏移量，不理解也没关系，你可以先理解为内存地址。
通过while进行自旋操作，getIntVolatile 也是 native 方法，就是获取最新的值，最关键的是 compareAndSwapInt，也是 native 方法，想看代码的话，得去看 C++ 的代码了，Hotspot JVM 的源码各位自行查找吧，我只贴出unsafe.cpp关键部分：
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
看不懂没关系，咱可以猜啊，调用了Atomic::cmpxchg方法，咱再去参观参观：
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;
}
还是看不懂，咱们可以查查大佬们的解释，LOCK_IF_MP是个宏定义，不去研究了，最终拼接出来是指令是 lock cmpxchgl，这又到汇编了，再往下挖就看CPU了，扯远了，先回来。
根据上面的探索，我们可知原子整型类AtomicInteger的操作依赖CAS，而CAS的实现是由Unsafe类实现，Unsafe类又依赖JVM的C++代码实现，C++代码使用汇编让CPU去操作，从而确保操作的原子性和安全性。
Unsafe类
很多大佬的代码跟着跟着就进了Unsafe类，这个类看名字的意思是不安全？
我们使用 Java 代码进行操作的时候，都隔着 JVM，由JVM去替我们操作真实的内存，并且有GC垃圾回收机制去回收内存，所以 Java 是安全的编程语言。
Unsafe类则是不安全的操作，它可以直接操作内存，开辟内存：allocateMemory、扩充内存：reallocateMemory、释放内存：freeMemory、在指定的内存块中设置值：setMemory、未经安全检查的加载Class：defineClass、原子性的更新实例对象指定偏移内存地址的值：compareAndSwapObject、获取系统的负载情况：getLoadAverage等等，所以很危险。
这么危险的操作，我们可以直接用吗？卖个关子，先看正常的使用姿势 Unsafe unsafe = Unsafe.getUnsafe()：
public static Unsafe getUnsafe() {
Class var0 = Reflection.getCallerClass();
if (!VM.isSystemDomainLoader(var0.getClassLoader())) {
throw new SecurityException("Unsafe");
} else {
return theUnsafe;
}
}
里面判断了VM.isSystemDomainLoader(var0.getClassLoader())，其实就是判断类加载器是不是为空，如果不为空就抛出异常，啥时候是null呢？只有由启动类加载器（BootstrapClassLoader）加载的class才是null，所以正常情况下是禁止我们直接使用Unsafe类进行不安全操作的，但是，不正常的情况呢？
反射大法好！我们可以通过反射机制，绕过getUnsafe方法拿到：
Class klass = Unsafe.class;
Field field = klass.getDeclaredField("theUnsafe");
field.setAccessible(true);
Unsafe unsafe = (Unsafe) field.get(null);
System.out.println(unsafe.toString());
Unsafe类的使用并不是本文的重点，我也简单带过，我个人的理解这个Unsafe类就是 SUN 公司留的一个“后门”，在Java中可以操作内存，进行不安全的内存使用。
自旋
前面还写到了自旋，自旋也非常的常用，当我们并发更新变量的时候，可能会竞争失败，就需要不断重试。
那为啥不用线程的休眠、唤醒等操作让出CPU呢，在这空转多浪费？
CPU的速度非常快，所以我们的代码执行速度也非常快，占用资源的线程可能一瞬间就执行完成释放资源了，如果再加上线程状态的转换就有点浪费，不如先等一等，自旋等待可能比线程状态切换更快，所以自旋还是有必要的。
那自旋就完美了吗？并不是，在下一篇文章讨论volatile的时候再说自旋的缺点。
ABA问题
CAS虽然看似完美，但还有ABA的问题，假如线程1把变量从A改为B，然后再改为A，线程2通过CAS去修改的时候，旧的变量和现在此时的变量都是A，认为没有人改过，但其实线程1已经改过，这就是ABA问题。
解决ABA问题，其实就是加个版本号，比如AtomicStampedReference，每修改一次就增加版本，这样ABA就被解决了。
