大家可能都听说说 Java 中的并发包，如果想要读懂 Java 中的并发包，其核心就是要先读懂 CAS 机制，因为 CAS 可以说是并发包的底层实现原理。

　　今天就带大家读懂 CAS 是如何保证操作的原子性的，以及 Java8 对 CAS 进行了哪些优化。

　　synchronized：大材小用

　　我们先来看几行代码：

　　public class CASTest {

　　static int i=0;

　　public static void increment() {

　　i++;

　　}

　　}

　　假如有100个线程同时调用 increment() 方法对 i 进行自增操作，i 的结果会是 100 吗？

　　学会多线程的同学应该都知道，这个方法是线程不安全的，由于 i++ 不是一个原子操作，所以是很难得到 100 的。

　　这里稍微解释下为啥会得不到 100(知道的可直接跳过)， i++ 这个操作，计算机需要分成三步来执行。1、读取 i 的值。2、把 i 加 1.3、把 最终 i 的结果写入内存之中。所以，假如线程 A 读取了 i 的值为 i=0，这个时候线程 B 也读取了 i 的值 i=0。接着 A把 i 加 1，然后写入内存，此时 i=1。紧接着，B也把 i 加 1，此时线程B中的 i=1，然后线程 B 把 i 写入内存，此时内存中的 i=1。也就是说，线程 A, B 都对 i 进行了自增，但最终的结果却是 1，不是 2.

　　那该怎么办呢？解决的策略一般都是给这个方法加个锁，如下

　　public class CASTest {

　　static int i=0;

　　public synchronized static void increment() {

　　i++;

　　}

　　}

　　加了 synchronized 之后，就最多只能有一个线程能够进入这个 increment() 方法了。这样，就不会出现线程不安全了。不懂 synchronized 的可以看我这篇文章：彻底搞懂synchronized(从偏向锁到重量级锁)

　　然而，一个简简单单的自增操作，就加了 synchronized 进行同步，好像有点大材小用的感觉，加了 synchronized 关键词之后，当有很多线程去竞争 increment 这个方法的时候，拿不到锁的方法是会被阻塞在方法外面的，最后再来唤醒他们，而阻塞/唤醒这些操作，是非常消耗时间的。

　　这里可能有人会说，synchronized 到了JDK1.6之后不是做了很多优化吗？是的，确实做了很多优化，增加了偏向锁、轻量级锁等， 但是，就算增加了这些，当很多线程来竞争的时候，开销依然很多，不信你看我另外一篇文章的介绍：彻底搞懂synchronized(从偏向锁到重量级锁)

　　CAS ：这种小事交给我

　　那有没有其他方法来代替 synchronized 对方法的加锁，并且保证 increment() 方法是线程安全呢？

　　大家看一下，如果我采用下面这种方式，能否保证 increment 是线程安全的呢？步骤如下：

　　1、线程从内存中读取 i 的值，假如此时 i 的值为 0，我们把这个值称为 k 吧，即此时 k=0。

　　2、令 j=k + 1。

　　3、用 k 的值与内存中i的值相比，如果相等，这意味着没有其他线程修改过 i 的值，我们就把 j（此时为1） 的值写入内存；如果不相等（意味着i的值被其他线程修改过），我们就不把j的值写入内存，而是重新跳回步骤 1，继续这三个操作。

　　翻译成代码的话就是这样：

　　public static void increment() {

　　do{

　　int k=i;

　　int j=k + 1;

　　}while (compareAndSet(i, k, j))

　　}

　　如果你去模拟一下，就会发现，这样写是线程安全的。

　　这里可能有人会说，第三步的 compareAndSet 这个操作不仅要读取内存，还干了比较、写入内存等操作，，，这一步本身就是线程不安全的啊？

　　如果你能想到这个，说明你是真的有去思考、模拟这个过程，不过我想要告诉你的是，这个 compareAndSet 操作，他其实只对应操作系统的一条硬件操作指令，尽管看似有很多操作在里面，但操作系统能够保证他是原子执行的。

　　对于一条英文单词很长的指令，我们都喜欢用它的简称来称呼他，所以，我们就把 compareAndSet 称为 CAS 吧。

　　所以，采用 CAS 这种机制的写法也是线程安全的，通过这种方式，可以说是不存在锁的竞争，也不存在阻塞等事情的发生，可以让程序执行的更好。

　　在 Java 中，也是提供了这种 CAS 的原子类，例如：

　　AtomicBooleanAtomicIntegerAtomicLongAtomicReference

　　具体如何使用呢？我就以上面那个例子进行改版吧，代码如下：

　　public class CASTest {

　　static AtomicInteger i=new AtomicInteger(0);

　　public static void increment() {

　　// 自增 1并返回之后的结果

　　i.incrementAndGet();

　　}

　　}

　　CAS：谁偷偷更改了我的值

　　虽然这种 CAS 的机制能够保证increment() 方法，但依然有一些问题，例如，当线程A即将要执行第三步的时候，线程 B 把 i 的值加1，之后又马上把 i 的值减 1，然后，线程 A 执行第三步，这个时候线程 A 是认为并没有人修改过 i 的值，因为 i 的值并没有发生改变。而这，就是我们平常说的ABA问题。

　　对于基本类型的值来说，这种把数字改变了在改回原来的值是没有太大影响的，但如果是对于引用类型的话，就会产生很大的影响了。

　　来个版本控制吧

　　为了解决这个 ABA 的问题，我们可以引入版本控制，例如，每次有线程修改了引用的值，就会进行版本的更新，虽然两个线程持有相同的引用，但他们的版本不同，这样，我们就可以预防 ABA 问题了。Java 中提供了 AtomicStampedReference 这个类，就可以进行版本控制了。

　　Java8 对 CAS 的优化。

　　由于采用这种 CAS 机制是没有对方法进行加锁的，所以，所有的线程都可以进入 increment() 这个方法，假如进入这个方法的线程太多，就会出现一个问题：每次有线程要执行第三个步骤的时候，i 的值老是被修改了，所以线程又到回到第一步继续重头再来。

　　而这就会导致一个问题：由于线程太密集了，太多人想要修改 i 的值了，进而大部分人都会修改不成功，白白着在那里循环消耗资源。

　　为了解决这个问题，Java8 引入了一个 cell[] 数组，它的工作机制是这样的：假如有 5 个线程要对 i 进行自增操作，由于 5 个线程的话，不是很多，起冲突的几率较小，那就让他们按照以往正常的那样，采用 CAS 来自增吧。

　　但是，如果有 100 个线程要对 i 进行自增操作的话，这个时候，冲突就会大大增加，系统就会把这些线程分配到不同的 cell 数组元素去，假如 cell[10] 有 10 个元素吧，且元素的初始化值为 0，那么系统就会把 100 个线程分成 10 组，每一组对 cell 数组其中的一个元素做自增操作，这样到最后，cell 数组 10 个元素的值都为 10，系统在把这 10 个元素的值进行汇总，进而得到 100，二这，就等价于 100 个线程对 i 进行了 100 次自增操作。

　　当然，我这里只是举个例子来说明 Java8 对 CAS 优化的大致原理，具体的大家有兴趣可以去看源码，或者去搜索对应的文章哦。

　　总结

　　理解 CAS 的原理还是非常重要的，它是 AQS 的基石，而 AQS 又是并发框架的基石，